Siemens IoT2050 Node-RED RCE, Exploited in the Wild (CVE-2026-58115)

TL;DR

• SIMATIC IoT2050 Advanced industrial gateways run Node-RED with no authentication on its HTTP interface, so anyone who can reach the device deploys flows that execute shell commands. Siemens disclosed the flaw on August 11, 2026 and rates it CVSS v3.1 and v4.0 10.0.
• Every SIMATIC IoT2050 Advanced device (article number 6ES7647-0BA00-1YA2) below image version V4.3.4.1 is affected. VulnCheck adds that any Node-RED instance without adminAuth accepts the same one-request deployment.
• Exploitation is running in the wild: VulnCheck canaries recorded complete exploits from October 30, 2026. The CVE is not in CISA's Known Exploited Vulnerabilities catalog as of November 3, 2026 (feed checked); VulnCheck added it to its own catalog.
• Update every IoT2050 to V4.3.4.1 or later. For every Node-RED deployment, verify the interface is not reachable from outside and enable adminAuth. "How do I fix it?" carries the hardening steps.

Am I affected?

You are exposed when all of these hold:

• The device is a SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2) running Industrial OS with Node-RED installed, below image version V4.3.4.1. Siemens lists no other affected model.
• The Node-RED interface is reachable by the attacker. Node-RED listens on all IPv4 interfaces on port 1880 by default, per its configuration documentation.
• No authentication is enforced on that interface. On the IoT2050, Siemens states the affected devices do not enforce authentication on the Node-RED HTTP interface.

The same deployment attack works against any unsecured Node-RED instance, not only Siemens devices. Node-RED is widely deployed: the node-red package records 92,432 weekly npm downloads, and its official Docker image records 327,470,066 pulls. Both figures were checked on November 3, 2026.

Check what you run on each host and on the gateway:

# Node-RED on any host: which interface and port it listens on
ss -tlnp | grep ':1880 '

# Node-RED on any host: is editor authentication configured?
grep -n "adminAuth" ~/.node-red/settings.js

An adminAuth line that stays commented out, starting with //, means the editor and the Admin API accept requests without a credential. From outside your network, try to open the editor URL of each deployment, http://<host>:1880.

An editor that loads without a login prompt is exposed. For the IoT2050, compare the deployed Industrial OS image version with V4.3.4.1; the update entry is 109741799 on the Siemens Industry Online Support portal.

How do I fix it?

Update the gateway, then harden every other Node-RED deployment:

1. Update every affected SIMATIC IoT2050 Advanced to V4.3.4.1 or later, from Siemens support entry 109741799. Siemens has released the fixed image and recommends updating.
2. On every other Node-RED deployment, enable authentication on the editor and Admin API by uncommenting and filling the adminAuth property in the settings file, then restart Node-RED:

// ~/.node-red/settings.js, adapted from the Node-RED securing guide
adminAuth: {
    type: "credentials",
    users: [ {
        username: "admin",
        password: "$2a$08$zZWtXTja0fB1pzD4sHCMyOCMYz2Z6dNbM6tl8sJogENOMcxWV9DN.",
        permissions: "*"
    } ]
}

Replace the example hash, which the guide uses for the password password, with one generated by node-red admin hash-pw.

1. Enable HTTPS access, and secure the HTTP Nodes and the Node-RED Dashboard with basic authentication or an OAuth/OpenID provider. Siemens recommends these same three steps, or uninstalling Node-RED outright.

No Node-RED release fixes this by itself, so upgrading the npm package changes nothing. If the editor is not needed on a host, disable the admin endpoints entirely by setting httpAdminRoot: false in the settings file.

Siemens' general recommendation is to protect network access to devices with appropriate mechanisms, so keep port 1880 off untrusted networks after the update.

What is the root cause?

Node-RED's editor and Admin API serve an HTTP interface that performs command execution by design, and the affected devices enforce no authentication on it.

Node-RED is a flow-based programming tool built on Node.js: an operator wires nodes together in a browser editor, and the server executes what the flows describe. Two built-in node types make the interface directly dangerous.

An inject node fires a message on a schedule or once at startup, and an exec node runs a system command on the host.

The Admin API exposes that power over HTTP. Its POST /flows endpoint "set[s] the active flow configuration" and requires permission flows.write, documented with the header Authorization: Bearer [token] only "if authentication is enabled".

The securing guide states the default plainly: "By default, the Node-RED editor is not secured - anyone who can access its IP address can access the editor and deploy changes."

On the IoT2050, Siemens' advisory describes the consequence: affected devices do not enforce authentication on the Node-RED HTTP interface. That gives unauthenticated access to programming nodes that execute system commands. The CVE record classifies it as CWE-306, Missing Authentication for Critical Function.

Node-RED ships this way because the tool assumes a trusted network, as its documentation says. On an industrial gateway with a network-reachable interface, that assumption fails.

How is it exploited?

The public proof of concept is the exploit traffic itself, decoded and published by VulnCheck on November 2, 2026:

1. The attacker sends a single POST /flows request to the Node-RED interface. The request VulnCheck caught on October 30, 2026 came from curl/8.5.0.
2. The body carries a flow of three nodes: an empty tab, an inject node and an exec node. The inject node fires once after a one-second delay. This is the layer-one encoding, quoted from the analysis:

{"flows":[
  {"id":"t","type":"tab"},
  {"id":"inj","type":"inject","z":"t","once":true,"onceDelay":"1","wires":[["e"]]},
  {"id":"e","type":"exec","z":"t","command":"echo <base64> | base64 -d | sh","addpay":false,"wires":[[],[],[]]}
]}

1. The interface replies HTTP/1.1 200 OK with a new flow revision hash, which is why the event records as a successful exploit.
2. One second after deployment, the inject node fires. The exec node then runs the decoded dropper. VulnCheck's decoding shows it fetches a binary over wget, with curl as fallback, saves it to /dev/shm/.b, marks it executable and runs it detached with setsid or nohup.

The binary was never retrieved, so VulnCheck makes no claims about what it does. Later requests from the same source varied the payload: a staged script wget.sh, saved and run as /tmp/.s, an implant saved as /tmp/.kworker, and flows that deploy no downloader at all.

How does the attack flow?

One HTTP request to the unauthenticated interface deploys a flow that runs the attacker's command within a second.

What can an attacker do?

The demonstrated impact is arbitrary command execution on the host that runs Node-RED.

• Siemens assesses that an unauthenticated remote attacker can create malicious flows and "execute arbitrary code on the underlying server with maximum privileges" through the HTTP interface.
• VulnCheck observed two post-exploitation shapes: bots saved to memory-backed /dev/shm, and persistent webshells. The webshell flows expose an HTTP endpoint, for example /cmd, wired through a function node to an exec node with addpay enabled. The attacker passes commands in a query parameter later.
• The conditions are minimal: network reachability of the interface, no adminAuth, and no user interaction. VulnCheck describes the deployment as one HTTP request.

No victim has been confirmed. VulnCheck's events came from one source IP, 4.201.105[.]116, and the payloads were not retrieved or analyzed, so no claim is possible about the bot's capabilities.

Why does the fix work?

The V4.3.4.1 update is Siemens' remediation, and the advisory confirms the affected range ends below it. Siemens distributes a closed-source industrial image, so no patch diff is public to quote.

The configuration fix for every other Node-RED deployment closes the exact gap the exploit uses. Setting adminAuth enables credential-based authentication on the editor and the Admin API.

POST /flows then requires the Authorization: Bearer [token] header the API documentation describes, and an unauthenticated request is rejected. Setting httpAdminRoot: false removes the endpoints entirely. The remaining hardening steps, HTTPS and basic authentication on the HTTP Nodes and Dashboard, close the other doors a flow can open.

These steps narrow the issue rather than change Node-RED itself. The exec node keeps its power by design; the fix is that only authenticated operators can wire and deploy it.

How do I check if I was compromised?

VulnCheck published the indicators from the observed exploitation. A hit is a lead to investigate, not proof of compromise, and a failed attempt may leave no trace.

# Look for the dropped files on the Node-RED host
ls -la /dev/shm/.b /tmp/.kworker /tmp/.s 2>/dev/null

# Find every exec node and every HTTP endpoint in the deployed flows
grep -nE '"type": ?"exec"' ~/.node-red/flows*.json
grep -nE '"type": ?"http in"' ~/.node-red/flows*.json

Network indicators to block and hunt in connection logs, published by VulnCheck:

• 4.201.105[.]116, the exploit source in Microsoft's ASN AS8075. It hit this flaw 16 times between October 30 and November 1, 2026.
• 85.215.73[.]250 on port 8080, the payload server for bot-linux-amd64 and wget.sh.
• 45.194.90[.]57 on port 38472, the server behind the .sys_update implant saved as /tmp/.kworker.

Review the flows themselves for nodes you did not author: an exec node with an unexpected command, or an http in endpoint such as /cmd wired into one. In access logs, look for POST /flows from unknown sources answered with HTTP 200 and a rev hash.

VulnCheck's analysis page carries the full indicator table and its initial-access artifacts for hunting.

Timeline

• 2026-08-11: Siemens publishes advisory SSA-834709 with CVE-2026-58115, the CVSS scores and the fixed image version V4.3.4.1.
• 2026-08-12: The CISA ADP assessment in the CVE record records SSVC Exploitation as "none" at that date.
• 2026-10-27: VulnCheck ships detection artifacts for the CVE, including an exploit PoC, a version scanner and Suricata, Snort and YARA rules.
• 2026-10-30: VulnCheck canaries catch the first complete exploit, and VulnCheck adds the CVE to its own KEV catalog.
• 2026-10-30 to 2026-11-01: The same source IP sends 16 events against the flaw; staged and webshell payloads appear on November 1.
• 2026-11-02: VulnCheck publishes the exploitation analysis.

FAQ

Is the Node-RED project itself affected?

No CVE exists for Node-RED, and no Node-RED release fixes this. The CVE belongs to Siemens' product, which embeds the tool without enforcing authentication on its interface. Node-RED's documentation states the editor is unsecured by default and suitable only for trusted networks.

Is the flaw in CISA's Known Exploited Vulnerabilities catalog?

No. The catalog's JSON feed carried no entry for CVE-2026-58115 as of November 3, 2026. VulnCheck added it to its own KEV catalog on October 30, 2026, the day its canaries caught the first exploit.

Has anyone been compromised?

No victim is reported. VulnCheck recorded exploitation attempts against its canary network from one source IP and did not retrieve the payloads. It makes no claims about the bot's capabilities.

The CISA ADP assessment recorded Exploitation "none" on August 12, before the October observations.

Do the attacks target Siemens devices specifically?

The canary emulates a Node-RED instance, so the observed attacks hit any unsecured Node-RED they find. The source IP also hit seven other CVEs across unrelated products, which VulnCheck reads as opportunistic mass scanning.

VulnCheck notes Node-RED ships inside commercial ICS and OT products. It also notes Emerson's documentation highlights that vendor's own Node-RED use, without validating impact.

What does maximum privileges mean here?

Siemens states the attacker executes arbitrary code "with maximum privileges" on the underlying server of the gateway. On a generic Node-RED host, the commands run as the user of the Node-RED process. The same deployment mechanism applies.

Where does Node-RED listen by default?

The editor and Admin API listen on all IPv4 interfaces, 0.0.0.0, on port 1880 by default, per the Node-RED configuration documentation. On a gateway with multiple interfaces, every network it bridges can reach it unless the deployment overrides uiHost.

Find exposed industrial interfaces with Ostorlab

Ostorlab's attack surface discovery inventories the internet-facing hosts in your ranges, so you can find every device answering on the Node-RED interface. Check each against the fixed version. Start a scan with Ostorlab to know which hosts need the update first.

References

• Siemens security advisory SSA-834709, published August 11, 2026, with the CVSS v3.1 and v4.0 10.0 vectors, the affected product list, the V4.3.4.1 remediation and the mitigations: https://cert-portal.siemens.com/productcert/html/ssa-834709.html (checked November 3, 2026)
• CVE-2026-58115 record, Siemens CNA, published August 11, 2026, with the CISA ADP SSVC block: https://www.cve.org/CVERecord?id=CVE-2026-58115 (checked November 3, 2026)
• VulnCheck, "Exploitation Targeting Node-RED, a Tool Embedded in ICS Products", published November 2, 2026, with the decoded exploit, the indicator table and the follow-up payloads: https://www.vulncheck.com/blog/exploitation-targeting-node-red (checked November 3, 2026)
• The Hacker News, "Attackers Exploit Critical Siemens IoT2050 Flaw to Plant Remote Command Backdoors", published November 3, 2026: https://thehackernews.com/2026/11/attackers-exploit-critical-siemens.html (checked November 3, 2026)
• Node-RED securing guide, "Securing Node-RED", the editor-unsecured-by-default statement and the adminAuth, HTTPS and HTTP-node steps: https://nodered.org/docs/user-guide/runtime/securing-node-red (checked November 3, 2026)
• Node-RED Admin HTTP API, POST /flows, the Bearer token header "if authentication is enabled": https://nodered.org/docs/api/admin/methods/post/flows/ (checked November 3, 2026)
• Node-RED configuration documentation, uiHost and uiPort defaults and httpAdminRoot: https://nodered.org/docs/user-guide/runtime/configuration (checked November 3, 2026)
• npm package page for node-red, weekly downloads: https://www.npmjs.com/package/node-red (checked November 3, 2026)
• Docker Hub page for nodered/node-red, image pull count: https://hub.docker.com/r/nodered/node-red (checked November 3, 2026)
• CISA Known Exploited Vulnerabilities catalog JSON feed, searched for CVE-2026-58115 with no match as of November 3, 2026: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (checked November 3, 2026)