Vulnerabilities

Node-RED CVSS 10 flaw exploited in attempts to plant Linux bots

Attackers are exploiting CVE-2026-58115 in unauthenticated Node-RED to drop Linux bots and webshells. What UK OT and IT teams should do now.

Illustration of an industrial server with a warning, headed Node-RED flaw exploited to deploy Linux bots

Attackers are using a maximum-severity Node-RED flaw in attempts to install Linux bots and webshells on exposed automation servers, including the kind of gateways that sit inside industrial networks. Siemens has a fix for its affected gateway, but every Node-RED instance running without admin authentication should be treated as at risk today.

What happened

On 2 November 2026 the vulnerability intelligence firm VulnCheck reported that CVE-2026-58115, a missing-authentication flaw rated 10.0 on both CVSS 3.1 and CVSS 4.0, is being exploited in the wild. One of the company’s canary systems, which pose as vulnerable servers to catch real attacks, recorded a complete exploitation attempt on 30 October. VulnCheck saw the same source address target the bug 16 times between 30 October and 1 November, as part of 125 hits across eight different CVEs in its wider canary network.

Siemens ProductCERT assigned the CVE in August under advisory SSA-834709. The official record covers the SIMATIC IoT2050 Advanced gateway (6ES7647-0BA00-1YA2) running Industrial OS with Node-RED installed, in all versions before V4.3.4.1. Siemens recommends updating to V4.3.4.1. According to the Siemens advisory, a remote attacker needs no credentials to gain full-privilege code execution on the device.

VulnCheck’s framing is broader, and it is what UK defenders need to hear: the attacks are aimed at Node-RED instances whose admin interface has no authentication configured, whatever hardware they run on. The Register, which reported the activity late on 2 November, noted the flaw had been added to VulnCheck’s known exploited catalogue but was not yet in CISA’s KEV list at the time of publication.

The technical picture

Node-RED is a visual automation tool built on Node.js. Engineers connect “nodes” in a browser editor to poll sensors, shift data and trigger actions. It is popular in manufacturing, building management and utilities because it is quick, visual and free, and vendors bundle it into commercial kit. Siemens ships it on the IoT2050 range, and VulnCheck notes that Emerson documents its use of Node-RED too, although it has not confirmed whether any Emerson products are affected.

The problem is simple. Node-RED’s editor is driven by an HTTP admin API, and that same API can deploy new flows. Some of the built-in nodes are designed to run operating system commands. If nobody has switched on the adminAuth setting, anyone who can reach the API can push a flow that runs commands on the host. Siemens classes this as CWE-306, missing authentication for a critical function.

What VulnCheck observed was automated and fast. A single web request deployed a flow that ran a command as soon as it was saved, fetched a Linux bot binary from a separate server, saved it to memory-backed storage and launched it in a detached session so it would outlive the Node-RED process. A 1 November update added variants, including a binary disguised as a kernel worker thread and persistent webshells built from Node-RED’s own HTTP input nodes. Those webshells live in the saved flow configuration, so a reboot does not remove them.

Two caveats matter. VulnCheck did not retrieve the bot binary or the staged scripts, so nobody can yet say what the malware does once it is running. And the company’s researcher Patrick Garrity described the campaign as “opportunistic mass scanning rather than a targeted attack”. That is little comfort if your plant gateway is an easy win.

Timeline of CVE-2026-58115 from Siemens advisory in August 2026 to exploitation seen from 30 October and VulnCheck's warning on 2 November

Why it matters for UK organisations

Node-RED tends to turn up in places that never went through a formal change board: a proof of concept on a Raspberry Pi in a factory, a monitoring dashboard set up by a contractor, an IoT gateway feeding a building management system. According to SecurityOnline, which cites internet scan data, over 20,000 Node-RED admin interfaces can be reached online. That figure is from one secondary source, but the pattern will be familiar to anyone who has scanned a UK manufacturer’s external range.

For operators in scope of the NIS Regulations, and for the wider group that the Cyber Security and Resilience Bill will bring in, an internet-facing engineering tool that hands out command execution is exactly the sort of weakness that turns into a reportable incident. Even where the immediate payload is a commodity bot, the attacker now has a foothold on a host that may bridge the corporate network and the control network. Its flows may also hold credentials for brokers, databases or PLC interfaces.

Smaller firms using Node-RED for quick integrations are not off the hook either.

Expert view

This is less a software bug than a configuration that has been allowed to drift onto the internet, and that is what makes it dangerous. When we test OT and IoT estates, the interfaces that cause the most trouble are rarely the PLCs themselves; they are the engineering and integration tools that sit around them, set up quickly and never revisited. A visual programming tool that can run shell commands is, by design, a remote administration console. Leaving it unauthenticated is the equivalent of publishing an SSH root login with no password.

In my experience, asset owners often do not know Node-RED is present at all, because it arrived inside a vendor appliance or a contractor’s project. That is why the Siemens CVE scoping should not lull anyone into thinking only IoT2050 owners need to act. The attackers are not checking model numbers; they are checking whether the API answers.

Do not declare victory after patching. A fixed gateway that was already compromised still carries any malicious flows saved to it, and the webshell variant is designed precisely to survive a restart. Patch, then inspect.

What to do now

  1. Find every instance. Search external and internal address ranges for Node-RED editors, typically on TCP port 1880, and ask OT vendors and integrators whether their products embed it. Cyber Essentials expects you to know what you own; this is that control in practice.
  2. Take it off the internet. No Node-RED editor should be publicly reachable. Put it behind a firewall, VPN or authenticating proxy with multi-factor authentication (Cyber Essentials: firewalls and secure configuration).
  3. Patch Siemens kit. Update SIMATIC IoT2050 Advanced gateways to Industrial OS V4.3.4.1 or later, as set out in SSA-834709 (Cyber Essentials: security update management).
  4. Turn on authentication. For standalone Node-RED, enable adminAuth with strong, unique credentials and remove or disable the instance entirely if it is not needed (Cyber Essentials: user access control and secure configuration).
  5. Hunt for compromise. Review deployed flows for exec or function nodes and HTTP input endpoints nobody recognises, check for unexpected binaries in temporary and memory-backed directories, and compare against the indicators VulnCheck has published.
  6. Rebuild if in doubt. If you find a malicious flow, treat the host as compromised: isolate it, rotate any credentials stored in its flows and rebuild from a known good image.
  7. Segment. Make sure integration gateways cannot reach control systems they have no business talking to, so a commodity bot cannot become an OT incident.

Bottom line

CVE-2026-58115 carries a Siemens product name, but the exposure is any Node-RED editor left open without a password. Exploitation is automated, opportunistic and already happening. Find your instances, lock them down, patch the Siemens gateways and check the flows for anything you did not put there.

Sources

Related Posts