Vulnerabilities

Attackers are taking over Node-RED instances that have no login on the editor. VulnCheck's honeypots (decoy systems it calls canaries) caught the first full exploit on October 30, 2026: one unauthenticated HTTP request deployed a Node-RED flow that downloaded and started a Linux bot. The flaw being exploited is CVE-2026-58115, which Siemens disclosed on August 11 for the SIMATIC IoT2050 Advanced gateway running Industrial OS with Node-RED installed, rated CVSS 10.0 and fixed in V4.3.4.1.

The same request works well beyond Siemens hardware. Node-RED's own documentation says the editor is not secured by default, so any Node-RED install without adminAuth configured accepts it. VulnCheck's summary: "Node-RED instances without adminAuth are being found and exploited automatically." Node-RED runs on factory gateways, Raspberry Pi boxes and home automation servers, and it is embedded in commercial industrial control products, so an editor open on port 1880 can sit on a plant network for years without anyone looking at it. VulnCheck added the CVE to its own Known Exploited Vulnerabilities (KEV) list; CISA's KEV catalog did not include it as of its November 3 update.

How it works

Node-RED is a Node.js tool for wiring together "flows" of nodes in a browser editor. The editor talks to the runtime through an Admin API, and POST /flows replaces the running flows with whatever JSON the caller sends. By default the runtime listens on port 1880 on all IPv4 interfaces (0.0.0.0), and until adminAuth is set in settings.js the Admin API asks for no credentials at all.

That matters because two core nodes turn a flow into a remote shell. An inject node fires on a timer or once at startup. An exec node runs a system command on the host. Wire one to the other and deploy it, and the command runs with the rights of the Node-RED process. Siemens classes its bug as CWE-306, missing authentication for a critical function, and says on the IoT2050 Advanced the code runs "with maximum privileges".

Siemens tracks only its own product under this CVE. No release of the upstream node-red npm package fixes it, because upstream Node-RED behaves as documented: securing the editor is the operator's job.

What attackers are doing

VulnCheck's write-up, published November 2, describes the first request on October 30 in detail. It came from curl/8.5.0 and posted a flow with three nodes: an empty tab, an inject node set to fire once after one second ("onceDelay":"1"), and an exec node running echo <base64> | base64 -d | sh. Encoding the command keeps strings such as wget and curl out of the request body. The server answered HTTP 200 with a new flow revision hash, which is the sign the deploy succeeded.

The decoded dropper fetched bot-linux-amd64 from 85.215.73[.]250 on port 8080 with wget, falling back to curl, saved it as /dev/shm/.b, made it executable and started it detached with setsid or nohup. /dev/shm is memory-backed, so the file disappears at reboot unless the attacker adds persistence. VulnCheck never retrieved the binary and does not know what it does.

Between October 30 and November 1, VulnCheck logged 16 Node-RED exploitation events from the same source, 4.201.105[.]116, an address in Microsoft's network (AS8075) that geolocates to Brazil. Across its wider canary data that address made 125 hits against eight CVEs in products including Apache Solr, Camunda, Gitea, MLflow, Traefik and Joomla. VulnCheck reads it as opportunistic mass scanning from a rented or compromised cloud VM, not a targeted campaign.

By November 1 the payloads had changed. One request ran wget.sh from the same server as /tmp/.s. Another fetched /.sys_update from 45.194.90[.]57 on port 38472 and saved it as /tmp/.kworker, a name chosen to look like a kernel worker thread. Some requests deployed no downloader at all. They added an http in endpoint such as /cmd, wired through a function node to an exec node with its append-payload option (addpay) enabled, so any later request can pass a command in a query parameter. That webshell lives in the flow file and survives a reboot.

What to do

1. Patch the Siemens gateways

Update every SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2) running Industrial OS with Node-RED to V4.3.4.1 or later, from Siemens support entry 109741799. If you cannot update yet, Siemens lists two mitigations in advisory SSA-834709: uninstall Node-RED, or harden it by following the Node-RED security guide.

2. Lock down every other Node-RED

Find each Node-RED install, including ones bundled in other vendors' OT products. On each host, grep -n "adminAuth" ~/.node-red/settings.js shows whether authentication is set. If the block is missing or commented out:

• Generate a bcrypt password hash with node-red admin hash-pw (Node-RED 1.1.0 and later). Do not reuse the example hash from the docs.
• Uncomment adminAuth in settings.js, set type: "credentials", add a user with that hash and permissions: "*", and restart Node-RED. Use "read" for anyone who only needs to look.
• On a host that runs flows but should never be edited, set httpAdminRoot: false, which disables all admin endpoints.
• Turn on the https option, and protect http in routes with httpNodeAuth.

Then keep TCP 1880 off the internet and off flat plant networks. ss -tlnp | grep ':1880 ' shows what the process is bound to. Set uiHost to a management interface, or allow 1880 only from engineering workstations at the firewall.

3. Check whether you were hit

• Search ~/.node-red/flows*.json for "type":"exec" and "type":"http in", and account for every exec node and endpoint (for example /cmd) that nobody on your team built.
• Look on the host for /dev/shm/.b, /tmp/.s and /tmp/.kworker, and for processes started from those paths.
• In proxy or reverse proxy logs, look for POST /flows from addresses outside your admin range that returned HTTP 200.
• Search firewall and DNS logs for 4.201.105[.]116, 85.215.73[.]250 (port 8080) and 45.194.90[.]57 (port 38472).

VulnCheck has reported no confirmed victims, so a hit is a lead, not proof.

4. If you find a malicious flow

Removing the flow is not enough, because the attacker had a shell on the host. Rebuild the device or host from a known-good image, restore flows from a copy you can vouch for, and set adminAuth before it goes back on the network. Rotate everything the flows held: MQTT and database passwords, API tokens, and the credentials for any PLC or historian the gateway talks to. Node-RED keeps these in flows_cred.json, encrypted with credentialSecret, which an attacker with a shell can read.

Inventory management ports as well as CVEs

This CVE names one Siemens gateway, yet the same request works against any Node-RED without adminAuth, and those have no CVE to show up in a vulnerability scan. Engineering tools such as Node-RED often arrive on the network with a project rather than through IT, so asset inventories need to record the management ports they open and whether those ports require a login.

Our network penetration tests look for unauthenticated management interfaces like the Node-RED editor across office and plant networks, and our safeguarding and hardening work sets authentication and access rules on them. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: VulnCheck, Siemens ProductCERT SSA-834709, CVE-2026-58115 record, Help Net Security, SecurityWeek, Ostorlab, Node-RED: Securing Node-RED, Node-RED: Configuration, CISA KEV catalog.