CVE-2026-58115: Siemens Node-RED Flaw Is Now Under Active Attack

CVE-2026-58115, a maximum-severity CVSS 10.0 flaw in the Node-RED HTTP interface bundled with Siemens SIMATIC IoT2050 industrial gateways, is now being exploited in the wild. Security firm VulnCheck says one of its canary systems caught an attacker weaponizing the bug on October 30, 2026, deploying a malicious flow that pulled down a Linux bot. The vulnerability lets anyone who can reach the Node-RED admin interface build and run flows — including shell commands — with no login required. Siemens patched it in firmware V4.3.4-1, but as of this writing the CVE has not been added to CISA's Known Exploited Vulnerabilities catalog.

What happened

Siemens ProductCERT disclosed CVE-2026-58115 on August 11, 2026, in advisory SSA-834709. The bug sat quietly for about eleven weeks with no reported exploitation. That changed at the end of October: VulnCheck, a vulnerability-intelligence firm, says its canary network caught a live exploit attempt against the flaw on October 30, 2026, and published a technical write-up on November 2 describing exactly how the attack works.

The attacker's request was a single HTTP POST to Node-RED's /flows endpoint — no credentials, no prior reconnaissance step recorded by the canary. Because Node-RED's admin API on the affected devices doesn't require authentication, that one request was enough to install and immediately run a new flow.

The vulnerability: CVE-2026-58115

According to Siemens' advisory and the NVD record for CVE-2026-58115, affected SIMATIC IoT2050 devices "do not enforce authentication on the Node-RED HTTP interface, allowing unauthenticated access to programming nodes that are capable of executing system commands on the server." In practice, that means a remote attacker with network access to the device's Node-RED port can create a malicious flow — Node-RED's term for a visual program — and that flow can include an exec node that runs arbitrary shell commands with the same privileges as the Node-RED process itself, which Siemens describes as "maximum privileges" on these gateways.

Both the CVSS v3.1 and CVSS v4.0 scores for the flaw come out to a maximum 10.0, Critical. The CVSS v3.1 vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — network-reachable, low attack complexity, no privileges or user interaction needed, and complete loss of confidentiality, integrity and availability. NVD tracks the flaw as CWE-306, Missing Authentication for a Critical Function, and lists its status as "Awaiting Analysis" as of this writing.

Which devices are affected

Siemens' advisory originally named only the SIMATIC IoT2050 Advanced model, but a November 4, 2026 revision (V1.1) widened the affected-products list to all four IoT2050 variants:

• SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2)
• SIMATIC IoT2050 Basic (6ES7647-0BA00-0YA2)
• SIMATIC IoT2050 M.2 (6ES7647-0BB00-1YA2)
• SIMATIC IoT2050 SM (6ES7647-0CA00-1AA2)

The common thread is that the device must be running Siemens' Industrial OS with Node-RED installed, on a version below V4.3.4-1. The IoT2050 line is a small, Debian-based industrial edge gateway that Siemens sells for connecting factory-floor equipment to IT networks and cloud services; Node-RED ships as an optional, pre-integrated tool for building those connections without writing full applications.

The fix and Siemens' mitigations

Siemens' remediation is straightforward: update affected IoT2050 devices to firmware V4.3.4-1 or later, available through Siemens Industry Online Support. Where an immediate update isn't possible, the advisory lists two fallback mitigations: uninstall Node-RED entirely, or harden the existing installation by following Node-RED's own security guidance — chiefly, turning on adminAuth in settings.js so the admin API requires a login, and putting the editor and admin interface behind HTTPS rather than leaving them on a cleartext, unauthenticated port. Siemens also reiterates its standing recommendation to keep industrial control devices off the open internet and behind proper network segmentation, pointing to its general operational guidelines for industrial security.

How the observed attack works

VulnCheck's write-up, published under the title "Exploitation Targeting Node-RED, a Tool Embedded in ICS Products", walks through the mechanics of the October 30 exploit attempt caught by its canary. The malicious flow the attacker pushed had three parts: an inject node set to fire once, one second after the flow is deployed; an exec node wired to it; and a shell command that pipes a base64-encoded string through base64 -d into sh, which is a simple way to dodge security tools that only flag plaintext wget or curl commands.

Once decoded, the command tries wget first and falls back to curl to fetch a binary named bot-linux-amd64, saves it to /dev/shm/.b (a RAM-backed, easy-to-miss location), makes it executable, and launches it detached from the terminal using setsid (or nohup as a fallback), discarding all output. VulnCheck notes there is no check that the download even succeeded and no cleanup step — consistent with automated, opportunistic scanning rather than a hands-on-keyboard operator. The researchers say they did not retrieve or analyze the downloaded binary itself, so they make no claims about what the bot actually does once running.

In a November 1 update to the same post, VulnCheck describes a second variant that instead downloads a staged script called wget.sh from the same payload server, and other requests that skip malware entirely in favor of planting a persistent webshell: an HTTP endpoint wired directly to an exec node, giving the attacker a standing backdoor for remote command execution that survives a reboot.

Who is behind it, and how big is this

VulnCheck traces the October 30 attack to a single IP address sitting inside Microsoft's cloud network (AS8075), geolocated to Brazil. Over a roughly two-day window, that one address hit the Node-RED flaw 16 times, and VulnCheck's broader canary telemetry shows the same address generating 125 exploitation attempts across eight different CVEs — including flaws in Apache Solr, Camunda, Gitea, MLflow, Traefik and Joomla — which the researchers read as evidence of mass, automated scanning infrastructure rather than a campaign targeting Siemens or industrial customers specifically.

That distinction matters for how seriously operators should read this: VulnCheck is explicit that its detections come from its own honeypot canaries, which emulate an exposed, unauthenticated Node-RED instance, not from a compromised Siemens IoT2050 in the field. The firm states it has not observed exploitation against an actual Siemens product. The risk the exploitation activity demonstrates is that any Node-RED admin interface left open to the internet without authentication — on a SIMATIC IoT2050 or on literally any other box running Node-RED — is already being found and hit automatically by this kind of scanning. Node-RED is a general-purpose, open-source low-code tool maintained by the OpenJS Foundation and used well beyond Siemens hardware, so the underlying weak point (an admin API with authentication switched off) is not unique to IoT2050 devices.

Why an unauthenticated Node-RED admin API is a perfect 10

Node-RED is a flow-based, low-code programming tool originally built by IBM's Emerging Technology group and now maintained by the OpenJS Foundation. It runs on Node.js, lets developers wire together hardware, APIs and online services through a browser-based visual editor, and is popular for Internet of Things and industrial IoT projects because it ships with hundreds of ready-made connectors for protocols like MQTT, Modbus and OPC-UA. That flexibility is exactly what makes an exposed, unauthenticated instance so dangerous: Node-RED's editor and admin API aren't just a dashboard, they're a way to author and immediately run new server-side logic, including nodes that shell out to the underlying operating system.

On a general-purpose server, that might be a bad day. On an industrial edge gateway like the IoT2050 — a device Siemens positions for bridging factory-floor equipment to IT networks and the cloud — it is, by design, sitting at a chokepoint with visibility into operational technology (OT) traffic. Siemens' own description of the impact, "execute arbitrary code on the underlying server with maximum privileges," combined with network-level reachability and zero authentication, is what produces a 10.0 on both the CVSS v3.1 and newer v4.0 scales: every exploitability and impact metric maxes out at once. There is no privilege boundary left for an attacker to climb, because none exists to begin with.

Timeline so far

• June 29, 2026: CVE-2026-58115 reserved.
• August 11, 2026: Siemens ProductCERT publishes advisory SSA-834709 (version 1.0), naming the SIMATIC IoT2050 Advanced as affected and firmware V4.3.4-1 as the fix.
• October 27, 2026: VulnCheck's Initial Access team says it releases detection artifacts for the flaw, including a proof-of-concept and scanning signatures, to its paying customers.
• October 30–November 1, 2026: VulnCheck canaries record exploitation attempts, including malware drops and webshell plants.
• November 2, 2026: VulnCheck publishes its public write-up on the exploitation activity.
• November 4, 2026: Siemens revises the advisory to version 1.1, widening the affected-products list from one IoT2050 model to all four.
• November 6–7, 2026: CVE-2026-58115 remains absent from CISA's KEV catalog, per our direct check of the catalog's November 6 release.

Is it in CISA's KEV catalog?

Reporting on this flaw has been inconsistent about whether it has formally landed in CISA's Known Exploited Vulnerabilities catalog. We checked directly: as of the KEV catalog's November 6, 2026 release (version 2026.11.06, 1,769 entries), CVE-2026-58115 does not appear in it. VulnCheck's own post, published November 2, says the same thing — it notes the CVE is not in CISA's KEV "at the time of writing," while stating that VulnCheck has added it to its own, separate vulnerability-intelligence catalog. We also searched CISA's ICS advisories listing for a Siemens IoT2050 or Node-RED entry and did not find a dedicated CISA ICS advisory republishing Siemens SSA-834709 under its own ICSA identifier; the authoritative advisory for this flaw, at this time, is Siemens' own SSA-834709 and the corresponding NVD record.

What to do now

If you run SIMATIC IoT2050 devices with Node-RED enabled, or any other Node-RED deployment reachable from outside a trusted network, there are a few concrete steps worth taking immediately:

• Patch first. Update affected IoT2050 devices to firmware V4.3.4-1 or later via Siemens Industry Online Support.
• Check exposure. Confirm whether your Node-RED admin interface (commonly on port 1880) is reachable from the public internet; if it doesn't need to be, take it off.
• Turn on authentication. Enable adminAuth in Node-RED's settings.js and serve the editor over HTTPS, per the Node-RED security documentation, on any instance where authentication is currently disabled.
• Audit existing flows. Look for exec nodes or HTTP-in endpoints you didn't create, which is how VulnCheck says attackers are leaving persistent webshells rather than dropping malware.
• If you can't patch yet, Siemens' fallback options are to uninstall Node-RED from the device or isolate it behind network segmentation and a firewall until the update can be applied.

Readers tracking other recent industrial and infrastructure-adjacent flaws may also want to see our coverage of the APT package manager vulnerability affecting Debian and Ubuntu and the OpenSSH flaw hitting Alpine Linux, two other unauthenticated-access bugs patched this quarter. If you manage exposed admin interfaces generally, our explainer on how attackers steal logins through session hijacking covers related exposure patterns worth closing off at the same time.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage