Node-RED CVE-2026-58115: Open Editors Exploited for RCE

What to do

1. Find every Node-RED instance and test whether GET /flows on the editor port (default 1880) returns 200 without credentials.
2. Take any unauthenticated, internet-reachable editor off the network or firewall it to trusted addresses immediately.
3. Enable adminAuth in settings.js with a bcrypt hash from node-red admin hash-pw, and set httpNodeAuth for HTTP endpoints.
4. Update Siemens SIMATIC IoT2050 Advanced devices to V4.3.4.1 or later, or uninstall Node-RED on them.
5. If an editor was exposed, audit flows for unexpected exec and http in nodes, then rebuild the host and rotate any credentials stored in flows.

How to check if you are affected or compromised

• Search the flows file (by default ~/.node-red/flows.json) and the editor for exec nodes and http in endpoints such as /cmd that you did not create.
• Check for the dropped files /dev/shm/.b, /tmp/.s and /tmp/.kworker and for processes running from those paths.
• Search proxy, firewall and Node-RED logs for POST /flows from unknown addresses, User-Agent curl/8.5.0, and traffic to or from 4.201.105.116, 85.215.73.250 and 45.194.90.57.
• Look for outbound wget or curl downloads started by the Node-RED process user.

What happened#

VulnCheck reported on November 2 that attackers are exploiting CVE-2026-58115 in Node-RED, the flow-based automation tool built on Node.js. One of its canary systems caught the first attempt on October 30. The same source address sent 16 attempts between October 30 and November 1. According to Help Net Security, that address also sent 125 requests against eight CVEs in Apache Solr, Camunda, Gitea, MLflow, Traefik and Joomla. That spread points to opportunistic mass scanning, not a targeted campaign.

The CVE comes from Siemens. Its advisory SSA-834709 of August 11, 2026 says SIMATIC IoT2050 Advanced devices running Industrial OS with Node-RED installed "do not enforce authentication on the Node-RED HTTP interface." An unauthenticated attacker can create flows containing nodes that run system commands "with maximum privileges." Siemens and the CVE record score it 10.0 under both CVSS 3.1 and 4.0 (CWE-306).

The exploit is one HTTP request. The attacker sends POST /flows to the Node-RED Admin API with a flow of three nodes: a tab, an inject node set to fire once after one second, and an exec node wired to it. The exec node runs echo <base64> | base64 -d | sh. The decoded script downloads bot-linux-amd64 from 85.215.73[.]250:8080, saves it as /dev/shm/.b and starts it in the background. VulnCheck's November 1 update adds a staged script (/tmp/.s) and a second payload saved as /tmp/.kworker. It also describes requests that dropped no payload and instead added an http in endpoint, such as /cmd, wired to an exec node. That is a webshell that survives restarts. VulnCheck did not recover the binaries, so their capabilities are not disclosed as of November 3, 2026.

Who is affected#

The formal scope of the CVE is narrow: the SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2) before V4.3.4.1. The practical scope is much wider. Node-RED's own security guide says that by default "the Node-RED editor is not secured" and that "anyone who can access its IP address can access the editor and deploy changes." The request VulnCheck captured uses only the standard Admin API, so it works on any Node-RED instance that has no adminAuth. VulnCheck says plainly that "Node-RED instances without adminAuth are being found and exploited automatically."

In practice that means home-automation boxes, Raspberry Pi and industrial gateways, Docker containers started with -p 1880:1880 on a cloud VM, and quick internal tools that ended up with a public IP.

Do you really need to act?#

Only if an unauthenticated Node-RED editor is reachable by someone you do not trust. If it is, act today. No memory-corruption bug or version check stands in the attacker's way. An open editor is a remote shell by design, and scanners are now sending payloads automatically. If such an instance has been on the internet in the last few days, assume it has been hit. Rebuild it rather than clean it.

If your editors need a login, either through adminAuth or an authenticating reverse proxy, this campaign does not affect you. A Node-RED instance that is reachable only on a trusted LAN or VPN is at lower risk. On OT networks, though, "trusted" often means "flat," so check that it really is isolated. CISA has not added the CVE to KEV as of November 3, 2026. VulnCheck lists it in its own KEV catalog.

What to do now#

1. Inventory Node-RED. Ask your exposure scanner, or run docker ps | grep -i node-red and ss -ltnp | grep 1880 on hosts.
2. Test each one from outside: curl -s -o /dev/null -w '%{http_code}\n' http://HOST:1880/flows. A 200 means anyone can read and replace your flows. A 401 means the Admin API requires authentication.
3. Firewall or stop any exposed, unauthenticated instance right away.
4. Enable authentication. Generate a hash with node-red admin hash-pw and add an adminAuth block of type: "credentials" to settings.js. Set httpNodeAuth as well if your flows expose HTTP endpoints. Put the editor behind a VPN or an authenticating proxy instead of publishing port 1880.
5. On a Siemens SIMATIC IoT2050 Advanced, update to V4.3.4.1 or later through Siemens support. If that isn't possible, uninstall Node-RED or harden it as Siemens advises.
6. Rebuild any instance that was exposed, then rotate credentials stored in flows: MQTT, database, cloud API keys and so on.

How to tell if you were hit#

Open the editor, or the flows file (by default ~/.node-red/flows.json), and look for exec nodes, inject nodes set to fire once, and http in routes you did not create: grep -o '"type":"exec"' ~/.node-red/flows*.json. On the host, check ls -la /dev/shm/.b /tmp/.s /tmp/.kworker and ps aux | grep -E '/dev/shm|/tmp/\.'. In logs, look for POST /flows from addresses you don't know, the User-Agent curl/8.5.0, and the VulnCheck indicators: source 4.201.105.116 and payload servers 85.215.73.250 (port 8080) and 45.194.90.57 (port 38472). No file hashes have been published. Payloads in /dev/shm disappear on reboot, but webshell flows do not.

Timeline#

• Aug 11, 2026 — Siemens publishes SSA-834709 and CVE-2026-58115 (CVSS 10.0). The fix is in V4.3.4.1.
• Oct 27, 2026 — VulnCheck ships detection artifacts to its customers.
• Oct 30, 2026 — A VulnCheck canary catches the first POST /flows exploit, which drops bot-linux-amd64.
• Nov 1, 2026 — VulnCheck has now seen 16 attempts from the source, plus new payloads and webshell flows.
• Nov 2, 2026 — VulnCheck publishes its analysis and IOCs.
• Nov 3, 2026 — Press coverage begins. The CVE is still not in CISA KEV.

Vulnerability records

• CVE-2026-58115 · A vulnerability has been identified in SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2) (All versions < V4.3.4.1 running Industrial OS with Node-RED installed).

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. Siemens ProductCERT — SSA-834709: Missing Authentication in Node-RED on SIMATIC IoT2050 Advanced cert-portal.siemens.com
2. CVE.org — CVE-2026-58115 cve.org
3. VulnCheck — Exploitation targeting Node-RED (CVE-2026-58115) vulncheck.com
4. Siemens Industry Support — SIMATIC IoT2050 firmware and Industrial OS downloads support.industry.siemens.com
5. Node-RED — Securing Node-RED nodered.org
6. Node-RED — Admin API: POST /flows nodered.org

Coverage and analysis

1. Help Net Security — Attackers exploit critical Node-RED flaw to deploy Linux bot and backdoors helpnetsecurity.com