Attackers Exploit CVSS 10 Siemens SIMATIC IoT2050 Node-RED Flaw to Drop Bots and Plant Command Backdoors

A maximum-severity vulnerability in Siemens SIMATIC IoT2050 Advanced devices is now being exploited in the wild. VulnCheck reports that starting October 30, 2026, attackers began sending full exploits for CVE-2026-58115 (CVSS 10.0) to its honeypot network. The goal was to install Linux bot binaries and, in some cases, leave behind HTTP backdoors that accept commands and keep working after a reboot. Siemens published its advisory and a fix in August 2026, so any device still unpatched has been exposed for about three months.

The Vulnerability

CVE-2026-58115 is classified as missing authentication for a critical function. It affects SIMATIC IoT2050 Advanced devices running Industrial OS with Node-RED installed. According to Siemens, the Node-RED HTTP interface does not require authentication, which lets an unauthenticated remote attacker "create malicious flows and execute arbitrary code on the underlying server with maximum privileges."

This is not a memory corruption bug, and attackers do not need a complicated chain. Node-RED is designed to let users build flows that run code and system commands. If the editor and admin API accept requests without credentials, anyone who can reach the interface can deploy a flow that does whatever they want. The CVSS 10.0 score follows from that: network access, no credentials, no user interaction and full control of the device.

Attack Chain Observed by VulnCheck

VulnCheck researcher Patrick Garrity called the first request seen "a complete exploit." In a single request, the attacker deployed a Node-RED flow, triggered it automatically and downloaded a binary from an attacker-controlled server. The payload was hidden under three layers of encoding.

The first-stage flow ran a shell script wrapper that:

• Used wget to fetch a bot binary built for AMD64 from 85.215.73[.]250
• Used curl as a fallback if the wget download failed
• Saved the binary as /dev/shm/.b, a hidden file on a memory-backed filesystem
• Ran the binary immediately

Writing to /dev/shm means the implant never touches persistent storage. It leaves less evidence on disk and disappears when the device reboots. The attackers apparently accept that trade-off, because they also installed persistence a different way, described below.

Campaign Evolution

After the first wave, the operators moved to a two-stage process. The wget command now fetches a second shell script, wget.sh, from the same 85.215.73[.]250 server, and that script handles the next stage. A separate set of requests sent wget and curl to 45.194.90[.]57 on port 38472 to download a payload named .sys_update. That payload was saved to disk as /tmp/.kworker, a name chosen to look like a normal Linux kernel worker thread in a process list, and then run.

VulnCheck could not retrieve wget.sh or .kworker, so their functions are unknown. Based on the delivery method and the bot binary in the first stage, the most likely result is that the device joins a botnet. That cannot be confirmed until the payloads are recovered.

Backdoors That Survive Reboot

For OT defenders, the most important finding is a set of requests that downloaded nothing. Garrity explained that in these cases, "the flow exposes an HTTP in endpoint (for example /cmd, or a randomly named path) wired through a function node to an exec node with addpay enabled, so the attacker could run arbitrary commands later by passing them in a query parameter."

This turns Node-RED into a persistent web shell. The flow is saved in the Node-RED configuration, so it reloads every time the service starts. In VulnCheck's words, "This backdoor survives even if a memory-backed implant is lost on reboot." Rebooting the device or deleting the bot binary does not remove access. The flow itself has to be found and deleted.

Why This Matters for OT Environments

The IoT2050 is an industrial edge gateway. It is often installed between PLCs, sensors and plant networks on one side and IT systems or cloud platforms on the other. Node-RED is popular on these devices because it makes protocol translation and data collection quick to build, and that same convenience makes an unauthenticated instance dangerous.

The payloads seen so far are opportunistic bots, not ICS-specific tooling. Even so, a compromised gateway with root access sits in a trusted position in the network. A command backdoor on that device gives an attacker a foothold to scan nearby OT segments, intercept or change data passing through the gateway, or sell access to a more capable group. The bot operators may only want bandwidth, but the access they hold is worth much more to someone else.

Vendor Fix and Mitigation

Siemens fixed the vulnerability in Industrial OS version 4.3.4.1 and later. Where updating is not yet possible, Siemens recommends removing Node-RED entirely or hardening the installation by:

• Enabling HTTPS access
• Securing the Node-RED editor and admin API with credential-based authentication or an OAuth/OpenID provider
• Securing HTTP Nodes and the Node-RED Dashboard with basic authentication

Patching or hardening stops new exploitation, but it does not remove anything an attacker has already installed. A malicious flow deployed before the update stays in the Node-RED configuration and keeps running after the patch. Any device that was exposed during the past three months needs a compromise assessment as well as the update.

RedEye Assessment

CVE-2026-58115 follows a familiar pattern for edge devices: a known flaw with a public fix, a three-month gap before exploitation, and attackers who plan for both short-term payloads and long-term access. The memory-resident bot plus a persistent Node-RED web shell shows the operators understand how these devices are usually cleaned up. RedEye Security can help confirm IoT2050 exposure across your OT estate, check Node-RED configurations for unauthorized flows, and verify that fixed gateways are actually clean. Contact RedEye to schedule an assessment.