CVE-2026-58115: Node-RED flaw (CVSS 10) exploited since 30 October; Siemens IoT2050 fix is V4.3.4.1

Attackers are exploiting CVE-2026-58115, a maximum-severity (CVSS 10.0) missing-authentication flaw in the Node-RED HTTP interface on Siemens SIMATIC IoT2050 Advanced devices, to run commands on exposed Node-RED servers and drop a Linux bot. The flaw was fixed in August, but exploitation was first seen on 30 October by security firm VulnCheck, and its sensors recorded the same attacker hitting a mix of other internet-facing software. Node-RED is a popular low-code tool that is often left open on industrial and lab networks, so the practical question for many teams is simple: can anyone who can reach your Node-RED editor deploy a flow?

Key points

• CVE-2026-58115 is a missing-authentication flaw (CWE-306) with a CVSS 3.1 and 4.0 base score of 10.0, per Siemens advisory SSA-834709.
• Siemens lists SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2) running Industrial OS with Node-RED installed, in all versions before V4.3.4.1; the fix is V4.3.4.1 or later.
• VulnCheck's canary network caught the first exploitation attempt on 30 October 2026 and counted 16 events against this CVE from one source IP address between 30 October and 1 November.
• The attack posts a three-node flow to Node-RED that runs a base64-encoded shell command, which downloads a Linux binary called bot-linux-amd64 and runs it from /dev/shm/.b.
• As of VulnCheck's post and The Register's report on 2 November, the flaw was in VulnCheck's KEV catalogue but not in the US CISA Known Exploited Vulnerabilities list.

What to do

Who is affected. Siemens names one product: the SIMATIC IoT2050 Advanced with Industrial OS and Node-RED, in versions before V4.3.4.1. VulnCheck's analysis describes the abuse as targeting the Node-RED admin API on instances that do not have authentication switched on, and says Emerson documentation mentions Node-RED use but that it did not validate whether any Emerson product is affected. Whether other Node-RED installations count under this particular CVE is not stated by Siemens; the attack technique, however, works on any Node-RED server whose admin interface is open.

Fix. Update the IoT2050 to V4.3.4.1 or later. Siemens points to its support article 109741799 for the update. If you cannot update, Siemens offers two workarounds: uninstall Node-RED, or harden it following the Node-RED guide on securing the runtime. It also advises protecting network access to the devices and following its industrial security operational guidelines.

Harden Node-RED. Node-RED's own documentation says the editor is unsecured by default, that anyone who can reach its address can deploy changes, and that this is only suitable on a trusted network. To turn on login, uncomment adminAuth in the settings file and define users with bcrypt-hashed passwords (node-red admin hash-pw creates the hash on Node-RED 1.1.0 and later). To protect routes created by HTTP In nodes, set httpNodeAuth.

Check whether you were hit. VulnCheck recommends:

• Find out whether any Node-RED instance, including ones embedded in industrial gear, is reachable from outside your network.
• Review deployed flows for unexpected exec nodes, and for http in endpoints (for example /cmd) wired to command execution.
• Look for the files /dev/shm/.b, /tmp/.s and /tmp/.kworker, and for processes you do not recognise.
• Search logs for connections to 4.201.105[.]116, 85.215.73[.]250 (port 8080) and 45.194.90[.]57 (port 38472).
• Because the first dropper lives in RAM-backed /dev/shm, a reboot removes that file, but the persistent webshell flows VulnCheck saw later survive restarts until the flow is deleted.

What happened

According to VulnCheck, a canary it operates received a single POST /flows request from curl/8.5.0 on 30 October. The posted flow had three nodes: an empty tab, an inject node set to fire once after one second, and an exec node wired to it. Because an inject node can fire on deployment, the command runs without any further interaction. The canary answered with HTTP 200 and a new flow revision hash, which is the normal reply of a vulnerable instance.

The command was echo <base64> | base64 -d | sh. Encoding it hides the real commands from filters that look for wget or curl inside request bodies. Decoded, the dropper downloads bot-linux-amd64 from http://85.215.73[.]250:8080/ with wget, falling back to curl, saves it as the hidden file /dev/shm/.b, marks it executable and starts it with setsid (falling back to nohup), discarding all output. VulnCheck notes that the script does not check the download succeeded and does not clean up.

VulnCheck did not retrieve the binary, so what it does is unconfirmed. The name suggests a Linux AMD64 bot. The Register likewise reports that the researchers did not retrieve the binary, so its behaviour is unconfirmed.

On 1 November VulnCheck updated its post with more activity. A staged-script variant fetched wget.sh from the same server. A second payload server, 45.194.90[.]57:38472, served a file saved as /tmp/.kworker, a name chosen to look like a kernel thread. Some requests deployed persistent webshell flows: an http in endpoint wired through a function node to an exec node, giving command execution through query parameters that stays after a reboot. VulnCheck did not retrieve wget.sh or .kworker either.

The source of the requests, 4.201.105[.]116, sits in Microsoft's AS8075 network and geolocates to Brazil. VulnCheck assesses it as opportunistic exploitation infrastructure, possibly a compromised or rented virtual machine used by several operators, and says the address alone does not identify who is behind it. The same address produced 125 hits across eight CVEs in recent days, including Apache Solr's CVE-2019-17558 and products such as Camunda, Gitea, MLflow, Traefik and Joomla, using at least five different user agents. That pattern points to mass scanning rather than a campaign aimed at industrial targets, and VulnCheck says as much.

Background

Node-RED is a flow-based programming tool built on Node.js. Users drag nodes onto a canvas and wire them together; nodes can read sensors, call APIs, and, in the case of exec, run shell commands on the host. That flexibility is why it is common in automation and industrial settings, and why an open editor is serious: deploying a flow is the same as running code.

Siemens published advisory SSA-834709 on 11 August 2026, describing the SIMATIC IoT2050 Advanced issue as CWE-306, missing authentication for a critical function: the Node-RED HTTP interface on affected devices does not enforce authentication, so an unauthenticated remote attacker could create malicious flows and execute arbitrary code with maximum privileges. The CVSS vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, which means network-reachable, low complexity, no privileges, no user interaction. CISA republished the advisory as ICSA-26-237-03 on 25 August 2026. VulnCheck published a detection for the flaw on 27 October, three days before it saw the first attack.

How the attack works

The chain has no exploit code in the usual sense. It uses the product as designed: with no login, the admin API accepts a new flow, and the exec node does the rest.

1. Reach the Node-RED admin API over the network.
2. POST /flows with an inject node wired to an exec node.
3. The inject fires after a second and runs the encoded shell command.
4. The shell downloads and starts the implant, or installs a webshell flow.

The numbers VulnCheck gives are small, and we are not charting them: 16 events against this CVE from one address, 125 hits from that address across eight CVEs. Counts like these show the flaw is on attackers' scan lists. They do not show how many servers were compromised.

What it means

For owners of IoT2050 gateways, the message is plain: the fix has been out since August, and there is now evidence of active attacks from the internet. For everyone else running Node-RED, the lesson is wider. A flaw on one vendor's device is an instance of a configuration problem, an editor reachable without login, that the Node-RED documentation itself warns about. Embedded copies matter most because they are easy to forget: a gateway shipped with Node-RED installed is rarely in the same asset list as a server you patch monthly.

For defenders, this is also a reminder that CVSS 10 on paper does not need a clever exploit. The Siemens score reflects that no privileges or interaction are needed, and the observed attack is a single HTTP request. Detection should focus on flows containing exec nodes and on outbound connections from industrial hosts to unfamiliar servers on odd ports such as 8080 and 38472.

What we don't know yet

• What bot-linux-amd64, wget.sh and .kworker do: none were retrieved.
• How many internet-exposed Node-RED servers are vulnerable or already compromised; VulnCheck gives no such count.
• Whether other vendors' products that embed Node-RED are affected under this CVE; Siemens lists only the IoT2050 Advanced and VulnCheck did not validate other vendors.
• Who operates the source address, which VulnCheck says could be shared by several operators.
• Whether and when CISA will add the flaw to its KEV catalogue; it was not listed at the time of VulnCheck's post and The Register's report.

What to watch next

Watch for a CISA KEV entry, which would set a remediation deadline for US federal agencies, for analysis of the dropped binaries, and for further Siemens or third-party advisories if other products that embed Node-RED turn out to be affected. We will add dated updates here if any of these happen.

Sources

• VulnCheck: exploitation targeting Node-RED (CVE-2026-58115) (primary source for the attacks)
• Siemens ProductCERT SSA-834709
• CISA ICS advisory ICSA-26-237-03
• Node-RED documentation: securing Node-RED
• The Register: max-severity bug in widely used OT programming tool exploited to deliver Linux malware