CVE-2026-58115: Siemens Node-RED backdoor checks

VulnCheck found Node-RED command backdoors that survive losing a memory-backed implant on reboot. CVE-2026-58115 affects Siemens SIMATIC IoT2050 Advanced devices running Industrial OS with Node-RED installed. NVD has no fixed version published yet; Siemens recommends uninstalling Node-RED or hardening access. The immediate job is to check both the exposed interface and the flows it contains.

Siemens says missing authentication in the Node-RED HTTP interface can let an unauthenticated remote attacker create malicious flows and execute code with maximum privileges, according to The Hacker News report. If you're responsible for these gateways, that's not just an unwanted configuration change — the exposed flow editor becomes a route to command execution on the underlying server.

Check IoT2050's Node-RED exposure

Start with the device and its installed configuration. The deployment Siemens describes is specific: SIMATIC IoT2050 Advanced, Industrial OS, and Node-RED installed. Confirm the model, operating system, and Node-RED installation before assessing versions.

1. Identify the relevant gateways in your device inventory. Match the Siemens model and operating system, rather than treating every Siemens product as part of this advisory.

2. Check whether Node-RED is installed on each matching device. Its presence is part of the vulnerable configuration Siemens describes; the hardware name alone is not the complete exposure check.

3. Review access to the Node-RED HTTP interface. Establish whether the editor and administration API require authentication, then separately check the HTTP Nodes and Node-RED Dashboard protections.

Record those findings separately. A device inventory entry, an installed Node-RED instance, and an authentication check answer different questions. Treating a gateway as cleared because only its model or software version was checked would skip the interface at the centre of CVE-2026-58115.

How attackers turn a flow into command execution

VulnCheck said that, as of October 30, 2026, it had observed attempts against its honeypot network to use CVE-2026-58115 to download and run a Linux bot. Researcher Patrick Garrity described a request that deployed a Node-RED flow, triggered it automatically, and retrieved a binary from an attacker-controlled server.

The initial downloader used wget, with curl as a fallback, to retrieve an AMD64 binary. The request then saved and executed it. VulnCheck subsequently observed a two-stage approach that fetched another shell script instead of retrieving the final binary directly.

The more consequential variation did not need a downloader at all. Some requests created an HTTP input endpoint connected through a function node to an exec node with addpay enabled. That arrangement let the attacker submit commands later through a query parameter.

“This backdoor survives even if a memory-backed implant is lost on reboot.”

— Patrick Garrity, VulnCheck

That finding changes the investigation target. Looking only for the downloaded program would miss the flow that supplies a command interface. The malicious flow is itself an attacker-controlled execution path, not merely a delivery mechanism for another file.

CVE-2026-58115: severity, exploitation and fix status

Siemens assigns CVE-2026-58115 a 10.0 Critical score under both CVSS 4.0 and CVSS 3.1. NVD lists the record as Awaiting Analysis, so the score should be credited to Siemens rather than presented as an independently completed NVD assessment.

The exploitation evidence also needs its attribution preserved. VulnCheck reports the observed attempts against its honeypots. CISA does not list the vulnerability in its catalog as of November 3, 2026. Those statements are not interchangeable: the absence of a CISA listing does not cancel VulnCheck's observation, and the honeypot report should not be expanded into an unsupported count of compromised production devices.

The Hacker News says CVE-2026-58115 has been remediated. The current NVD entry, however, has no fixed version published yet. Verify the fixed release before choosing an upgrade target. It does not prove that no fix exists; it means the current NVD record does not establish a confirmed upgrade target.

Until that target is verified, Siemens' removal and hardening recommendations provide the concrete actions available here. A patch plan should not become a reason to leave the unauthenticated interface unchanged.

The unretrieved payloads leave malware identification open

VulnCheck could not retrieve the later wget.sh script or the payload saved as .kworker, so their exact functionality remains unknown. The observed requests establish what the attackers attempted to fetch and execute, not everything those missing payloads would have done.

The AMD64 binary likewise describes one observed payload. It should not be used as a substitute for the Siemens deployment description when deciding which gateways need review. Payload architecture and the vulnerable product configuration are different pieces of information.

Remove Node-RED or harden its exposed interfaces

Siemens offers two mitigation paths: uninstall Node-RED, or harden the installation. Uninstall Node-RED if the workload does not require it; otherwise, harden its interfaces.

1. Enable HTTPS access. Include this in the hardening work rather than treating authentication changes as the entire recommendation.

2. Secure the editor and administration API with credential-based authentication or an OAuth/OpenID provider. This is the authoring and administration surface through which the reported malicious flows were created.

3. Secure the HTTP Nodes and Node-RED Dashboard using basic authentication. Siemens names these separately from the editor and administration API, so check them separately too.

Use those surfaces as distinct acceptance checks. A login requirement on the editor does not, by itself, demonstrate that the separately named HTTP Nodes and Dashboard have received the recommended protection. Likewise, enabling HTTPS does not complete the authentication steps in Siemens' guidance.

Where it must remain, make the hardening decision explicit rather than assuming that keeping the service running is equivalent to accepting its existing access settings.

Review Node-RED flows alongside downloaded artifacts

The observed requests provide specific review leads, but the flow-only backdoor means a file search cannot be the whole investigation. The following artifacts and destinations come from VulnCheck's reported observations.

These are review indicators, not commands to execute. The randomly named endpoint variation is especially relevant: searching only for the literal path /cmd would not cover every flow pattern Garrity described.

• Review flows for unexplained HTTP input endpoints connected to command execution, including the reported function-node and exec-node arrangement. Establish whether those flows belong to the intended application.

• Review available request records and filesystem evidence for the reported destinations and artifacts. Keep this alongside the flow review, rather than using the absence of a downloaded file as the sole clearance condition.

My priority for CVE-2026-58115 would be to remove or harden the unauthenticated access path, then establish whether attacker-created flows remain. A reboot is not sufficient evidence of cleanup given Garrity's persistence finding. A defensible closure decision needs both an access-control check and a review of what the exposed instance was made to run.