Node-RED was not exploited: they sent it three nodes

What hit the canary was three nodes: an empty tab, an inject and an exec. The inject set to once: true so it would fire by itself on deploy, and behind it the exec, the node whose documented job is to run system commands. It is what anyone builds who uses the tool for what it is for.

On 30 October 2026, one of VulnCheck's canaries caught that delivery: a POST to /flows. That route does not add a flow. The API documentation says it in five words — "Set the active flow configuration" — and with the deployment type applied by default, full, "all existing nodes are stopped before the new configuration is started". The attacker's payload began with an empty tab, so the same POST that opens the door takes out whatever automations were running. Nobody has reported it that way, and it is the part that costs most.

The command inside the exec node was echo <base64> | base64 -d | sh, with three layers of encoding nested inside one another, and at the end a binary called bot-linux-amd64 downloaded to /dev/shm/.b and launched with setsid, with nohup as a fallback. Other attempts used an intermediate script and a file at /tmp/.kworker; some dropped webshells built from an http in node routed through a function node before reaching another exec. A brand new HTTP entry point, assembled from pieces on the palette.

A ten that scores a setting

The identifier is CVE-2026-58115 and it carries a 10.0 under CVSS 3.1 and another 10.0 under CVSS 4.0. Siemens assigned it in advisory SSA-834709 of 11 August 2026, for SIMATIC IoT2050 Advanced units running Industrial OS with Node-RED installed. The advisory's summary is a sentence with no decoration: "could allow an unauthenticated remote attacker to create malicious flows and execute arbitrary code on the underlying server with maximum privileges". The word that matters there is create.

Node-RED's own documentation said it long before the advisory did, on its security page: "By default, the Node-RED editor is not secured - anyone who can access its IP address can access the editor and deploy changes". And right after, the condition: "This is only suitable if you are running on a trusted network". The setting that changes it is called adminAuth and ships commented out in settings.js.

Siemens shipped Industrial OS V4.3.4.1, and it is worth being precise about what the advisory says and does not say: it states "update to V4.3.4.1 or later version" without detailing what changed inside. What it does detail is what it offers you in the meantime, and that is the revealing part: harden the Node-RED installation following the project's own guide, or uninstall Node-RED from the device. Neither of those is a patch.

And this is not the first time somebody has put a ten on this same setting. In July 2025, CERT@VDE assigned CVE-2025-41656 to Pilz's IndustrialPI 4, also at 10.0, and the wording is practically the same sentence: "An unauthenticated remote attacker can run arbitrary commands on the affected devices with high privileges because the authentication for the Node_RED server is not configured by default". Another vendor, another year, the same commented-out setting. Thirteen months separate the two advisories and on neither occasion was there anything to patch in Node-RED.

That moves where the control sits. Against a memory corruption bug, the control is the patch. Here Siemens' patch only exists if you own the Siemens device. If your Node-RED runs on a virtual machine of your own — which is how it is usually set up — there is no version to upgrade to for this CVE, because the CVE is not against Node-RED but against a product that carries it inside. In your case the control is two things that cannot be downloaded: adminAuth set, and the editor with no route in from the internet.

A CVE carrying the vendor's name while the flaw sits in a component it packages is not new, and we wrote about it this morning with GitLab and Ruby, so we will not labour it here. What is different about this case is that the component inside behaves exactly as documented.

Seven of the eight it attacked are not infrastructure

The press has told this as an industrial story, and you can see why: Siemens signs it, the product is a plant-floor gateway and CISA published it as a control-systems advisory (ICSA-26-237-03). The canary telemetry adds another layer. The same IP that fired the flows — 4.201.105.116, on a Microsoft network, geolocated in Brazil — hit CVE-2026-58115 sixteen times between 30 October and 1 November, and over recent days had racked up 125 hits against eight different CVEs across VulnCheck's wider canary network.

The products VulnCheck names in that count are Apache Solr, Camunda, Gitea, MLflow, Traefik and Joomla, plus Node-RED itself. That is seven names for eight CVEs: it does not say which product the eighth belongs to, so what follows holds for seven of the eight and should be read with that caveat in place. Of those seven, none is an operating system or a VPN concentrator.

They all listen on HTTP and almost all were stood up by somebody inside to glue one thing to another. Two do not quite fit and it is worth saying so: Traefik is designed precisely to face the internet, and a Joomla is usually a public website somebody commissioned. The other five were designed on the assumption that they would live on a trusted network, and none of the seven is part of the estate the IT department maintains. They are what grew up beside it.

VulnCheck reads the breadth of that list as the signature of opportunistic mass scanning rather than a targeted attack, and it is right about the how. We would add the what, and we flag it as our own reading: opportunistic scanning explains the speed, not the selection. Somebody decided these things were worth looking for, and what the scanner found worth looking for are internal tools nobody signed for. That one of them ended up living inside a Siemens product is the anecdote; the subject is that most of them live inside no product at all, just on somebody's machine.

The calendar should not be read backwards either. Siemens' advisory is dated 11 August; the first attack the canary caught, 30 October. Eighty days. Nobody has published what happened in between, so all that can be stated is that this is the first publicly observed exploitation, and that when it arrived it came automated and against eight things at once. If anyone assumed their thirty-person company is of no interest to anybody, interest is not required here. Answering a scan is enough.

When this 10.0 is a zero for you

It is worth saying even though it does not help us sell anything: if your Node-RED has adminAuth configured and its port does not leave the internal network, this 10.0 does not apply to you. Not remotely, not with caveats. A CVSS ten measures the worst case, and the worst case here requires the editor to be both reachable and open; remove either condition and the attack stops existing. Worth checking before anybody opens an emergency ticket, because haste on an industrial production system carries a cost of its own.

The question that is hardest to answer from memory is how many Node-RED instances are running in your estate right now, and who put them there. The flow somebody built three years ago so the ERP would notify the warehouse is still working, and precisely because it is still working nobody has been back in to look at it.

The census almost nobody has written down

A normal inventory has one row per server and one per licence. The glue does not show up there: no invoice, no support contract and often not even a DNS name. These are the three columns we add when we go in to look at this. We run a self-hosted n8n for internal tasks and we treat it this way — inventoried, with an owner and an update window — not out of discipline, but from having seen what happens when you do not.

That third column is what orders the work, and it explains why this kind of software never shows up in scans: nobody bought it, so it is on no asset list. It is the same mechanism we wrote about in the software only your sector uses, and the same one behind the agent turned off the alert, not the watchman when something gets automated without first deciding who answers for it.

Automating well means each flow having an owner, bounded permissions and somewhere you can see what it does, which is what our automation and AI work is about. Pulling the list of what is already running, with its dependencies and without selling licences for anything, is consultancy work. If you want us to look at it with you, there is the contact form.

The attack reads like a tutorial, and that is the part that is hard to sit with: it took no better understanding of Node-RED than the person who built the warehouse alerting flow has. What decided the outcome was a commented-out line in a configuration file nobody had reopened, inside a machine that appeared on no inventory.

Sources. Consulted on 3 November 2026. The attack caught by the canary on 30 October 2026, the three-node flow structure, the exec node command, the /dev/shm/.b and /tmp/.kworker destinations, the webshells built from http in and function nodes, the IP 4.201.105.116, the sixteen hits between 30 October and 1 November, the 125 hits against eight CVEs across its wider canary network and the list of six products (Apache Solr, Camunda, Gitea, MLflow, Traefik and Joomla) come from "Exploitation Targeting Node-RED, a Tool Embedded in ICS Products", by VulnCheck, which is also the source that reads that breadth as opportunistic mass scanning rather than a targeted attack. The identifier CVE-2026-58115, the 10.0 under CVSS 3.1 and 4.0, the sentence quoted from the summary, the affected product — SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2), all Industrial OS versions prior to V4.3.4.1 with Node-RED installed — the instruction to update to V4.3.4.1 and the interim mitigations come from Siemens ProductCERT advisory SSA-834709 of 11 August 2026, carried by CISA as ICSA-26-237-03. The two sentences about the editor's default and the trusted network, and the adminAuth setting, come from the official Node-RED documentation; what POST /flows does and the behaviour of the full deployment type come from its admin API reference. The Pilz precedent is CVE-2025-41656, assigned by CERT@VDE on 1 July 2025 at CVSS 10.0. The exploitation timeline is reported by Help Net Security on 3 November 2026. Quotes are left in their original English so they can be searched verbatim. The eighty days between the advisory and the first attack caught are our own subtraction over those two dates, and do not imply there was no activity earlier: they imply that is the first publicly observed. The social image photograph is "Control panel displays settings and data for industrial equipment", by Shixart1985, CC BY 2.0 via Wikimedia Commons.