Siemens IoT2050 flaw CVE-2026-58115 lets strangers run code through Node-RED; here's how to check and lock down your clients' gateways.
A grey box bolted inside a factory cabinet can run a stranger's code without asking for a password if it's a Siemens SIMATIC IoT2050 Advanced with Node-RED installed and unpatched. VulnCheck's decoy devices caught attackers using it to plant a Linux bot and hidden command backdoors from 30 October 2026. Check every client's Node-RED install today, starting with whether its editor opens without a login.
/cmd endpoint, which VulnCheck found; Siemens' advisory doesn't say the update removes them.CVE-2026-58115 is a missing-authentication flaw (CWE-306) in Siemens SIMATIC IoT2050 Advanced industrial gateways: the Node-RED HTTP interface doesn't require a login, so anyone who can reach it can deploy flows (Node-RED's drag-and-drop automation programs) that run code with maximum privileges, per Siemens' advisory SSA-834709. It is being exploited: VulnCheck logged 16 attempts against its decoys between 30 October and 1 November 2026 from one IP it ties to opportunistic mass scanning; they dropped a Linux bot or planted Node-RED backdoor flows, hidden web endpoints such as /cmd.
The flaw is rated 10.0 (CVSS), the maximum. VulnCheck added it to its own exploited-vulnerabilities catalog; CISA has not listed it as of this writing, so recheck the catalog.
CISA republished the advisory as ICSA-26-237-03 on 25 August 2026. Siemens lists only the Advanced model.
All six checks only observe. Check 2 runs from your workstation; the rest need a root shell on the gateway (Industrial OS is Linux). VulnCheck published no file hashes. A real gateway could have been reached before VulnCheck's decoys were first hit on 30 October 2026, so search the oldest retained logs.
Preserve evidence. Copy the Node-RED folders, system logs and any dropped files into one folder, hash them, and pack the archive to copy off the gateway. Pass: the .sha256 file lists every copied file.
# paths assume Node-RED's default ~/.node-red user folder
D=/root/ir-$(hostname)-$(date +%F); sudo mkdir -p "$D"
sudo cp -a /root/.node-red /home/*/.node-red /var/log "$D"/ 2>/dev/null
sudo cp -a /dev/shm/.b /tmp/.s /tmp/.kworker "$D"/ 2>/dev/null # absent files are skipped
sudo find "$D" -type f -exec sha256sum {} + | sudo tee "$D.sha256"
sudo tar czf "$D.tgz" "$D" "$D.sha256" # then scp the .tgz off the gateway
Does the Node-RED admin API answer without a login? Node-RED's API docs say /flows returns 401 when a login is required; 200 means the API is open. This covers the default port 1880 only, so start from the client's asset inventory. Pass: every address prints 401 or 000.
for H in <gateway-ip-1> <gateway-ip-2>; do
for U in https://$H:1880/flows http://$H:1880/flows; do
echo "$U $(curl -sk -m 5 -o /dev/null -w '%{http_code}' "$U")"
done
done
Node-RED backdoor flows. Lists exec nodes (which run shell commands), HTTP-in nodes (which open web endpoints) and their paths in the flow files. Pass: every listed path belongs to a flow the client's engineers built.
sudo find / -xdev -path '*/.node-red/*' -name '*.json' -not -path '*/node_modules/*' \
-exec grep -HoE '"type": ?"(exec|http in)"|"url": ?"[^"]*"' {} +
Dropped files. Looks for the three file paths VulnCheck published; /dev/shm and /tmp clear on reboot, so a clean result after a restart proves little. Pass: ls reports all three missing.
sudo ls -la /dev/shm/.b /tmp/.s /tmp/.kworker
Running processes. Shows Node-RED's process tree and anything named after the payloads; it shows only processes still running. Pass: no .b, .kworker, wget or curl sits under node-red.
ps -eo pid,ppid,user,comm,args --forest | grep -B2 -A5 -E '[n]ode-red|\.kworker|/dev/shm/\.b'
Firewall and proxy logs. Search (a) is VulnCheck's three IPs: any hit means contact with known attacker infrastructure, so treat it as a likely compromise and escalate. Search (b) is outside traffic to port 1880: review each hit. Pass: search (a) prints nothing.
# run against the client's exported firewall, proxy or SIEM logs
zgrep -hE '4\.201\.105\.116|85\.215\.73\.250|45\.194\.90\.57' <log-dir>/*
# netfilter-style fields shown; add the client's own ranges to the exclude
zgrep -hE 'DPT=1880\b' <log-dir>/* | grep -Ev 'SRC=(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.)'
Close the door first, then remove footholds, then rotate secrets.
Close the door. Update to V4.3.4.1 or later, per Siemens SSA-834709; if that can't happen today, block inbound TCP 1880 at the client's firewall as a temporary measure, or uninstall Node-RED. Pass: check 2 prints 401 or 000 from outside.
Hardening (agree with the client first): turn on Node-RED logins. Generate a hash with node-red admin hash-pw, set adminAuth and httpNodeAuth per Node-RED's security guide, then sudo reboot; engineers must then sign in to the editor. Pass: check 2 prints 401.
// ~/.node-red/settings.js
adminAuth: {
type: "credentials",
users: [ { username: "admin", password: "<bcrypt hash>", permissions: "*" } ]
},
httpNodeAuth: { user: "<user>", pass: "<bcrypt hash>" },
Remove footholds. If checks 3 to 6 found anything, reinstall the gateway with a fresh V4.3.4.1 or later image instead of cleaning it, because the code ran with maximum privileges and VulnCheck did not retrieve the bot to see what it does. Reimport flows only from the client's own copy. Pass: check 3 lists only client-built paths.
Rotate secrets. Change every password or key the gateway's flows used (MQTT broker, database, cloud service) at the service that issued it. Pass: a login with the old secret fails.
Rerun the checks. Pass: checks 2 to 5 all pass.
KinoSec's autonomous external network pentest checks whether each client's Node-RED editor or admin API answers from the internet without a login, and writes the finding up with the fix. That is the gap that sat open between Siemens' August patch and the first attacks VulnCheck logged. The test also shows whether any unexpected web endpoint on the gateway answers from outside; it doesn't read the flow files on the device, which check 3 covers. The scanner that hit VulnCheck's decoys was running an attack. The same reconnaissance, run with your client's permission, scope limits and a report they can act on, is a pentest, and its report tells your client which boxes a stranger could reach.
Possibly. CVE-2026-58115 is Siemens' ID for the IoT2050, but VulnCheck says Node-RED instances without adminAuth are being found and exploited automatically. Node-RED's own guide says the editor is unsecured by default. VulnCheck notes that Emerson documentation mentions Node-RED but has not validated whether Emerson products are affected.
First, from your workstation, run curl -s -o /dev/null -w '%{http_code}' <ip>:1880/flows; 401 means a login is required. Next, on the gateway, run sudo grep -rE '"type": ?"(exec|http in)"' /root/.node-red and confirm each node belongs to a client-built flow. Then run sudo ls -la /dev/shm/.b /tmp/.s /tmp/.kworker, the three file paths VulnCheck published; any file found means treat the gateway as compromised.
Siemens' SSA-834709 lists two mitigations: uninstall Node-RED, or harden it. Hardening means setting adminAuth and httpNodeAuth per Node-RED's security guide and blocking inbound TCP 1880 at the client's firewall until the update lands. Turning on a login doesn't delete a flow that's already planted, so run the backdoor checks as well.
CISA's republished advisory carries Siemens' general recommendation to protect network access to devices with appropriate mechanisms. For an MSP, that means putting OT (operational technology, the machines on the factory floor) gateways behind the client's firewall or VPN. Then add them to the client's asset inventory so the next external test includes them.