Node-RED: a CVSS 10 flaw exploited in the wild is targeting industrial gateways
VulnCheck has observed real-world exploitation of CVE-2026-58115, a CVSS 10 authentication flaw in Node-RED that hands code execution on embedded industrial gateways to a remote attacker. Teams running Node-RED should check today that the editor is not exposed and audit their flows for exec nodes.
August 11, 2026. Siemens discloses CVE-2026-58115, a missing authentication on the Node-RED HTTP interface, rated CVSS 10.0. October 30. VulnCheck observes real in-the-wild exploitation from a Microsoft IP address. November 1. Fifteen more attacks, including persistent webshells. Why it matters: a tool embedded in thousands of industrial gateways is being exploited with a single HTTP request, and the attackers are leaving backdoors, not just bots.
What Node-RED is, and why it is everywhere without anyone knowing
Node-RED is a flow-based, low-code programming tool: you wire nodes together in a web UI to build event-driven applications. Its simplicity made it ubiquitous in IIoT and OT — it ships inside commercial products, from home-automation hubs to industrial gateways.
Siemens found it in its SIMATIC IoT2050 Advanced devices running Industrial OS with Node-RED installed. That finding triggered the August 11 disclosure: version 4.3.4.1 and later carry the fix.
The underlying problem fits in one line: Node-RED listens on HTTP by default, and without a configured adminAuth, anyone can reach the flow editor. The flow editor is an interpreter: its exec nodes run system commands. An unprotected interface is therefore a remote shell for whoever finds it.
CVSS 10: a flaw that only asks for one request
CVE-2026-58115 is described as a missing authentication on the HTTP interface. Siemens’ wording is unambiguous: an unauthenticated remote attacker can create malicious flows and execute arbitrary code with maximum privileges on the underlying server.
The CVSS 10.0 reads straight from the vector: no interaction required, no authentication, full impact on confidentiality, integrity and availability. It is the class of flaw a Shodan scanner can exploit in a loop, with no complex chain.
The real exploitation, as VulnCheck describes it
On October 30, VulnCheck observed a successful exploit from an address in AS8075 — Microsoft’s network. The attacker deployed a Node-RED flow, triggered it automatically, then pulled a binary from an attacker-controlled server, all behind three layers of encoding. The binary was a Linux bot, and the filename suggests the attacker had built payloads for multiple architectures.
By November 1, VulnCheck counted fifteen additional attacks from the same address, delivering extra payloads — including persistent webshells that leave the attacker a lasting command channel on the compromised server.
VulnCheck’s conclusion is the lesson to keep: attackers are actively scanning for Node-RED instances without adminAuth and exploiting them automatically with a single HTTP request. The target is not curiosity; it is industrialized compromise.
How to check your exposure in a minute
Triage is simple, and it needs no dedicated command: Node-RED is a web server. Three questions settle it:
- Is your instance reachable from outside? If the editor (
:1880) answers on a routable address, you are already in the target scope. - Is
adminAuthenabled? Thesettings.jsfile must defineadminAuth; without it the editor is open. - Do your flows contain unexpected
execnodes or HTTP endpoints? A webshell left by an attacker shows up as a node nobody added.
The quick port check, on the host running Node-RED:
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:1880/A 200 with no authentication prompt is the symptom to fix immediately: enable adminAuth, then stay behind network segmentation — an industrial gateway has no business being routable from the internet.
Why this is a signal for OT, not just for the lab
This exploitation overturns a comfortable assumption. Node-RED was seen as a prototyping tool; it is now used as a foothold into industrial environments. The logic is that of the modern attacker: target the internet-connected devices nobody patches, then leave a webshell to come back.
The flaw itself is not sophisticated — a missing authentication is trivial — but the surface it covers is. Every IIoT gateway, home-automation box and hub that embeds Node-RED without adminAuth is an open door exploitable in a single request.
Why OT is the link that patches least
CVE-2026-58115 was fixed by Siemens back on August 11 — three months before the observed exploitation. That gap is the real statistic of the incident: the fix existed, the exploitation happened anyway, because industrial gateways rarely get patched.
The reasons are structural. An OT gateway controls a physical process; taking it down to apply a patch can cost a production line. Its lifecycle is measured in years, not weeks, and it is often run by a team separate from IT. The result: the security patch collides with service continuity, and security is the one that yields.
Attackers know this. The campaign VulnCheck observed does not target recent installs: it scans the internet for exposed Node-RED instances without adminAuth, then drops a bot or a webshell. This is the industrialization of compromising devices nobody watches.
What segmentation actually changes
The defense does not rest on the patch alone. Even patched, an industrial gateway has no business being reachable from the internet. Network segmentation — putting Node-RED behind a VPN or firewall, off any routable address — reduces the attack to nothing before a CVE is even discovered. The patch closes the flaw; segmentation puts it out of reach. The two are not interchangeable: an unknown flaw remains exploitable on an exposed gateway, however up to date it is otherwise.
That is the difference between a security policy that reacts to CVEs and an architecture that does not depend on them. In OT, the first is necessary, the second is what actually protects you — because the next flaw does not have a number yet.
Why a single HTTP request is enough
The exploit needs no exploit chain because Node-RED’s design does the heavy lifting. The flow editor is a full programming environment: an exec node is a built-in command-execution primitive, and the HTTP endpoint that deploys flows is the same one that edits them. Miss adminAuth, and you have wired a shell to the public internet.
That is why the observed attacks look the way they do: one request deploys the flow, the flow pulls a binary, the binary installs persistence. No memory corruption, no shellcode, no interaction. It is the difference between breaking a lock and finding a door that was never fitted with one — and it is the reason the fix is not a patch to wait for, but a configuration to enforce right now.
Verdict
If you run Node-RED, enable adminAuth today, confirm the editor is not reachable from outside, then audit your flows for exec nodes or HTTP endpoints nobody added — in that order, authentication first, audit second, never the reverse. The flaw is exploited in the wild, which changes the stakes: you are not closing a theoretical threat, you are shutting a door an actor is already opening in a loop. In an OT environment, keep gateways under strict network segmentation and behind the 4.3.4.1-or-later fix on the SIMATIC IoT2050 side: a webshell left on an industrial gateway costs more to detect than to prevent.