On this page (8 sections)
Attackers are exploiting CVE-2026-58115, a missing authentication flaw in the Node-RED HTTP interface on Siemens SIMATIC IoT2050 Advanced devices. VulnCheck, as reported by Help Net Security, says it caught a complete exploit attempt on October 30, 2026, which installed a Linux bot and backdoors.
If you run Node-RED anywhere, on an industrial gateway, a Raspberry Pi, a VM or a cloud server, this is worth a check today. The core problem is a Node-RED editor reachable without a login, and that is not unique to Siemens hardware.
What happened
Siemens published an advisory in August 2026 (see the Siemens ProductCERT advisory SSA-834709). It describes affected devices as not enforcing authentication on the Node-RED HTTP interface. That exposes programming nodes able to run system commands, so an unauthenticated remote attacker can create malicious flows and execute code on the underlying server with maximum privileges.
More than two months later, VulnCheck researcher Patrick Garrity reported that one of the company's decoy systems (canaries) had been hit by a working exploit. According to the report, the request deployed a flow, triggered it automatically and fetched a binary from an attacker-controlled server, with the content hidden behind three layers of encoding.
Why this class of flaw is so dangerous
Node-RED is a flow-based tool: users wire nodes together in a browser editor, and the runtime executes those flows. Some built-in nodes can run shell commands by design. That is fine when only trusted administrators can reach the editor. If the editor and its admin API accept requests without a login, anyone who can reach the port can author a flow that runs commands, and the flow runs with the privileges of the Node-RED process. On the affected Siemens devices, the advisory says that means maximum privileges.
The weakness (CWE-306) scores a 10.0 because it is reachable over the network and needs no privileges, no user interaction and no special conditions, per the CVSS v4 metrics in the GitHub advisory. Garrity noted that Node-RED instances without adminAuth are being found and exploited automatically, so the issue is as much about configuration as product version.
What attackers did, based on VulnCheck's findings
The following comes from VulnCheck's observations as relayed by Help Net Security and The Hacker News. Both are reporting on the same VulnCheck research, so they are not independent confirmations.
- The first flow downloaded a Linux binary named bot-linux-amd64, saved it in a memory-backed location (/dev/shm/.b) and ran it in the background. VulnCheck did not retrieve the binary, so its purpose (miner, DDoS bot, reverse shell or other) is unknown.
- Later requests switched to a two-stage approach, fetching a shell script first, and another fetched a file saved as /tmp/.kworker, a name made to look like a kernel worker thread. What those files do is also unknown.
- Several requests installed webshell-style backdoors that let attackers run commands later. Per VulnCheck, the webshells stay in place after a restart, while the memory-backed bot is lost on reboot unless it sets up persistence another way.
- The source address sat in Microsoft's network and geolocated to Brazil. VulnCheck describes the activity as opportunistic mass scanning and notes that such an address is usually a rented or compromised virtual machine, so it says little about who is behind it.
Who is exposed
Two groups should act. First, owners of SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2) devices running Industrial OS with Node-RED installed on any version before V4.3.4.1. Second, anyone running Node-RED elsewhere, since the reporting stresses that unprotected instances are being found automatically. Website and hosting administrators sometimes run Node-RED on a side server for automations or dashboards, and those are easy to forget.
The risk is highest where the Node-RED port is reachable from the internet or from a flat internal network that includes untrusted devices. Devices inside OT networks are not automatically safe; Garrity specifically advised checking OT environments too.
How to check your exposure
Start by finding every Node-RED instance you own, then confirm whether each one asks for a login and who can reach it.
On a Linux host, this read-only command lists listening TCP ports with their owning process, so you can spot a Node-RED process and the port it uses (Node-RED's documented default is 1880). Run it with sudo to see process names:
sudo ss -tlnp | grep -i -E 'node|1880'Next, from a machine outside your trusted network, check whether the port answers at all. If an editor page or API responds without asking for credentials, treat the instance as exposed. Replace the placeholders with your host and port; this only requests response headers and changes nothing:
curl -sI http://HOST:PORT/ | head -n 5Finally, look for the artifacts named in the reporting. This lists hidden files in the two locations used. A hit is a strong sign of compromise, though a clean result does not prove the device is safe, since attackers can rename files:
ls -la /dev/shm /tmp | grep -E '\.b$|\.kworker|\.sys_update'What to do now
0 of 9 done
Siemens' own hardening guidance, as reported by The Hacker News, covers three areas: HTTPS access, credential or OAuth/OpenID protection of the editor and admin API, and basic authentication for HTTP nodes and the dashboard. Where you can, also limit which source addresses may reach the service at all, since authentication should be a second layer rather than the only one.
Detection and monitoring afterwards
Because the activity is automated and opportunistic, expect repeated probing. VulnCheck observed a complete exploit sent in a single POST to /flows, so watch for such requests from unfamiliar addresses, new or modified flows, shell processes spawned by the Node-RED process, and outbound downloads from the device to servers you do not recognize. VulnCheck's post lists indicators including the attack source and both payload servers; The Hacker News names 85.215.73[.]250 and 45.194.90[.]57:38472 as download hosts.
Keep an eye on whether CISA adds the flaw to its own KEV catalog, since the reports say it had not at the time of writing. For public-facing web servers in the same environment, certificate, DNS and header change monitoring and the website hacked guide help you notice when something nearby has changed. A web application firewall can add a network-level layer in front of web services, but it is no substitute for authentication or patching.
Timeline
| Date | Event |
|---|---|
| August 2026 | Siemens publishes its advisory; the CVE is published to NVD and the GitHub Advisory Database on August 11, 2026 |
| October 30, 2026 | VulnCheck's canary catches a complete exploit attempt |
| October 30 to November 1, 2026 | The same source address hits the Node-RED flaw 16 times, per VulnCheck |
| November 3, 2026 | Public reporting of active exploitation; CISA KEV listing not present at time of writing |
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.