CRITICAL: Siemens IoT2050 Node-RED Flaw Exploited to Plant Backdoors

There is an old joke in industrial security that the "S" in IoT stands for security. Siemens customers running SIMATIC IoT2050 Advanced gateways are living that joke this week, because attackers have started exploiting a maximum severity Node-RED flaw on those devices to drop botnet malware and leave behind command backdoors that survive a reboot.

The bug is CVE-2026-58115, and it carries a CVSS 3.1 score of 10.0, which is as high as the scale goes. Siemens disclosed it back on August 11, 2026 in advisory SSA-834709 and shipped a fix at the same time. That gave defenders nearly three months of head start. Based on what VulnCheck saw hitting its honeypots starting around October 30, a lot of that head start was spent doing something other than patching.

If you have an IoT2050 Advanced anywhere on a plant floor, in a pump house, or bolted into a customer's control cabinet, drop everything and go check it. This is the kind of flaw where "we'll get to it next maintenance window" turns into an incident report.

What the flaw actually is

Siemens classifies CVE-2026-58115 as CWE-306, Missing Authentication for Critical Function, and that description is refreshingly honest. The Node-RED HTTP interface on SIMATIC IoT2050 Advanced devices (order number 6ES7647-0BA00-1YA2) running Industrial OS with Node-RED installed does not enforce authentication. Every version below V4.3.4.1 is affected.

For anyone who has not spent time with it, Node-RED is a browser-based, low-code programming tool that lets you wire together "flows" made of nodes. It is genuinely useful on an edge gateway because it lets engineers pull data from a PLC, massage it, and push it somewhere else without writing a full application. The trouble is that a Node-RED flow is code. It can include function nodes that run arbitrary JavaScript and exec nodes that run shell commands on the host. So when the editor and admin API are reachable without a password, anyone who can reach the port can deploy a flow, and anyone who can deploy a flow owns the box.

The CVSS vector tells the whole story. It is network reachable, low complexity, requires no privileges, needs no user interaction, and has a changed scope with high impact to confidentiality, integrity, and availability. Siemens says an unauthenticated remote attacker can create malicious flows and run arbitrary code with maximum privileges, which on these devices means root. The changed scope matters here too. An IoT2050 usually sits between the IT network and operational technology, so compromising it is rarely the end goal. It is the foothold.

How the attacks look in the wild

VulnCheck reported the exploitation, and researcher Patrick Garrity described the attacker requests as complete, self-contained exploits. A single HTTP request deployed a Node-RED flow, triggered it automatically, and pulled down a binary from an attacker-controlled server. The payload was wrapped in three layers of encoding, which is less about sophistication and more about getting past anyone who might be glancing at logs with grep.

In the first wave, the flow dropped a shell script wrapper that used wget, falling back to curl if wget was missing, to grab an AMD64 botnet binary from 85.215.73[.]250 on the internet. The binary was written to /dev/shm/.b and executed. Hiding a dot file in shared memory is a classic Linux botnet move, since /dev/shm lives in RAM, is writable by everyone, and gets overlooked by people who only check /tmp.

A later campaign changed tactics. The attackers used wget to fetch a second script named wget.sh from the same 85.215.73[.]250 server. Another request reached out to 45.194.90[.]57 on port 38472 to fetch a file called .sys_update, saved it as /tmp/.kworker, and ran it. Naming malware after a kernel worker thread is about as subtle as wearing a fake mustache to a family reunion, but it does fool anyone scanning a process list too quickly. VulnCheck could not retrieve wget.sh or .kworker, so their full functionality is still unknown. Treat any system that fetched them as fully compromised.

The part that should worry OT teams most is the third pattern. Some requests did not download anything at all. Instead, the attacker deployed a flow that created a new HTTP endpoint, sometimes at /cmd and sometimes at a random path, and wired it through a function node into an exec node with the payload option enabled. The result is a web shell built entirely out of legitimate Node-RED components. Commands go in through a query parameter and come back out as a shell on the device. Garrity pointed out that, unlike a memory-only implant, this backdoor persists across reboots because it is saved as part of the device's flow configuration. Power cycling the gateway, which is the go-to fix in a lot of plants, does nothing.

There are no public numbers yet on how many devices have been compromised or which sectors are being targeted. The attacks seen so far are opportunistic and automated, which tells you the operators are scanning broadly for exposed Node-RED instances rather than hunting a specific victim. That is not comforting. Opportunistic attackers sell access, and an IoT2050 inside a manufacturing network is a far more valuable listing than a random home router. As of CISA's October 30 catalog update, CVE-2026-58115 had not been added to the Known Exploited Vulnerabilities list, so do not wait for that to show up before you act.

What to do right now

The fix is to update to V4.3.4.1 or later, and Siemens has posted the update through its industry support portal. If you cannot patch immediately because the device is in a production line that cannot go down, Siemens offers two other options. The first is to uninstall Node-RED entirely if nobody is actually using it, which is more common than you would think on gateways that shipped with it preinstalled. The second is to harden the installation according to the Node-RED user guide. In practice that means turning on HTTPS, requiring credentials or OAuth and OpenID authentication for the editor and admin API, and applying basic authentication to HTTP nodes and the Dashboard. On top of that, the device should never be reachable from the internet, and it should only be reachable from the specific engineering workstations that need it.

Patching alone does not fix a box that has already been hit. Because the backdoor lives in the flow configuration, an attacker who got in before you updated can still be sitting there afterward. Before you call any device clean, open the Node-RED editor or export the flows and look for anything nobody on the engineering team recognizes. Pay close attention to HTTP in nodes exposing unfamiliar paths like /cmd, function nodes that pass input straight into exec nodes, and any flow that calls wget or curl. If you find one, assume root compromise and plan to reimage the device from known good media rather than deleting the flow and hoping for the best.

On the host, look for files at /dev/shm/.b or /tmp/.kworker, look for a script named wget.sh, and look for processes running from /dev/shm or /tmp. A real kworker is a kernel thread and will never have a binary on disk, so anything named .kworker that maps to a file is malicious by definition. At the network layer, block and alert on traffic to 85.215.73[.]250 and to 45.194.90[.]57, especially on port 38472 where the second stage was hosted. Hunt backward through firewall and NetFlow logs for any IoT2050 that talked to those addresses, and look for unexpected inbound connections to the Node-RED port, which defaults to TCP 1880 on a stock install. An OT gateway initiating outbound downloads from a random IP on the internet is a strong signal no matter what the payload turns out to be.

Finally, use this as an excuse to do the inventory you have been meaning to do. Edge gateways tend to get installed by integrators, configured once, and forgotten. If you do not know how many IoT2050 units are in your environment, what firmware they run, and whether Node-RED is enabled on them, you are not managing them. They are managing you.

The bigger lesson

None of this is exotic. It is an unauthenticated admin interface on a device that runs as root, published with a fix three months ago, now being hit by commodity botnet operators. The same pattern played out with exposed Jenkins consoles, exposed Docker APIs, and exposed Redis servers, and it will keep happening as long as convenience tools ship wide open on devices that sit next to physical processes. Low-code is great until the code is somebody else's.

The good news is that the fix is straightforward and the indicators are concrete. Patch to V4.3.4.1 or later, lock down or remove Node-RED, get the device off any network segment it does not need to be on, and then go look for the backdoor flows before you declare victory.

MSP angle

Most small manufacturers, water utilities, and food processors have no idea what Node-RED is, let alone that it is running on a gateway in their control cabinet. That makes an OT asset discovery and exposure assessment an easy conversation to start this week, and it naturally leads into ongoing OT network segmentation and managed detection that covers the plant floor, not just the office.