VulnCheck says its canary caught CVE-2026-58115, a CVSS 10 Siemens flaw, exploited 80 days after the advisory

Eighty days between Siemens' advisory and VulnCheck's canary

Siemens published advisory SSA-834709 and the CVE record for CVE-2026-58115 on 11 August 2026. On 2 November, VulnCheck published a post saying one of its canaries caught an attacker exploiting that flaw on 30 October. From the advisory to that sighting is 80 days (derived from the printed dates). The flaw is scored 10.0 on both CVSS 3.1 and CVSS 4.0, and Siemens's advisory already carried a fixed version, V4.3.4.1, on the day it was published.

What the 80 days does not establish: the time to first exploitation anywhere, because a canary sees only what is aimed at it; any real victim; or that any Siemens device was reached. The printed advisory date is also not necessarily the date V4.3.4.1 was released: the support site the advisory links to for the update answered this site's request for its robots file with an access denied, so the page was not requested and the release date of V4.3.4.1 was not read. VulnCheck itself says it "did not retrieve or analyze" the bot its canary was served, and says the address behind the request "says little" about who is behind it.

This briefing is built from the primaries, read from about 12:22 UTC on 3 November 2026: the Siemens advisory page, the CVE.org record and the NVD entry, VulnCheck's post including its update section, the two Node-RED documentation pages on securing the editor and the admin API, and the CISA Known Exploited Vulnerabilities file. VulnCheck sells exploit and vulnerability intelligence, including canary data, so it has a commercial interest in showing exploitation; its claims are attributed to it throughout. No file was downloaded from any attacker address, no exploit was run, and nothing was tested.

What Siemens and the CVE record say

The name on the record is narrower than the name in the headlines. Siemens's advisory is titled "Missing Authentication Vulnerability in Node-RED on SIMATIC IoT2050 Advanced with Industrial OS". The affected product is one device, and one configuration of it: all versions before V4.3.4.1 "running Industrial OS with Node-RED installed". The advisory does not say whether Node-RED comes installed on those devices or is added by the user, only that the flaw exists where it is installed.

Two things about the records at the time of reading. First, the Siemens advisory is still at version V1.0 with a last update of 11 August: nothing on the page was revised after VulnCheck's sighting. Second, the National Vulnerability Database entry shows status "Awaiting Analysis", last modified on 23 October 2026, and carries only Siemens's two scores, marked secondary. NVD has not added a score of its own.

The mitigation matters more than it first looks. The Node-RED User Guide that Siemens points to is the page titled Securing Node-RED, and it is the page that says what the default is. That is the subject of the section on scope below.

What VulnCheck's canary caught, and what a canary is

A canary, in general, is a deliberately exposed decoy system built to log whoever touches it. VulnCheck's post does not say which product or version its canary presents itself as. It says the canary answered the attacker's request with HTTP 200 and a new revision hash, "exactly as a vulnerable instance would", and that this reply is why its signature records the event as a successful exploit. So the event is a decoy being told it was compromised, not a device being compromised.

What VulnCheck says the request was: a single POST to the flows path of the Node-RED admin API, sent by curl, that deployed a flow of three parts, an empty tab, an inject node set to fire once shortly after deployment, and an exec node wired to it. The exec node ran an encoded command that, once decoded, fetched a Linux binary from a second address and ran it detached. VulnCheck says the encoding has three layers and that a filter looking for plain download commands in the request body would have missed it. This briefing does not reproduce the flow or the commands; the indicators VulnCheck prints are in the technical section below.

Zoom

VulnCheck's update of 1 November adds to the picture, in its words. The same address delivered a second dropper variant from the same server that fetches a staged shell script; the original bot dropper again, several times; a request pointing at a different payload server, saving a file under a name that mimics a kernel worker thread; and several requests that downloaded nothing at all but deployed a flow exposing a web endpoint wired to an exec node, so commands could be run later. VulnCheck says that backdoor would survive a reboot that wipes a memory backed implant. It did not retrieve the staged script or the second server's file, and makes no claim about either.

The counts, as VulnCheck prints them: 16 events from the one address against this CVE between 30 October and 1 November, with at least five different user agents and several payloads. Across its wider canary data the same address logged 125 hits against 8 CVEs over recent days, among them flaws in Apache Solr, Camunda, Gitea, MLflow, Traefik and Joomla, alongside this one. VulnCheck's reading is that this breadth "is the signature of opportunistic mass scanning rather than a targeted attack", and that the shared infrastructure may serve more than one operator. The address sits in a major cloud provider's network range. An address range says nothing about who operates the host: VulnCheck notes that such an address is more often a compromised or rented machine than the operator's own hardware.

Taken together this is evidence that automated tooling is probing for unauthenticated Node-RED and that one address was delivering several payloads to a decoy. It is not a victim count. One canary and one source address cannot say how many real devices were reached, and VulnCheck says so: "These events come from one source IP."

"Node-RED flaw" is a shorthand: one device on the record, a class in the post

VulnCheck's post is titled "Exploitation Targeting Node-RED, a Tool Embedded in ICS Products" and its opening calls the flaw "an unauthenticated Node-RED admin API flaw". The CVE record does not use that phrase. It names the Siemens device and the configuration in which Node-RED is installed. The wider claim in VulnCheck's post is that Node-RED is "embedded in commercial ICS/OT products", for which it cites the Siemens CVE itself, and that Emerson's documentation "highlights its use of Node-RED". On Emerson, VulnCheck is explicit: "we haven't validated whether their products are impacted by this vulnerability."

The Node-RED documentation says what the default is. On the page Siemens links to, the first lines read: "By default, the Node-RED editor is not secured - anyone who can access its IP address can access the editor and deploy changes." The next sentence adds that this is "only suitable if you are running on a trusted network". The admin API documentation says the API "is secured using the adminAuth property" in the settings file, and that if the property is not set, the admin API "is accessible to anyone with network access to Node-RED".

That is the context for the label. By the documentation's own description, any reachable Node-RED without adminAuth would answer the same request the same way. This is inference, not something either primary says in so many words, but it follows from the two sources side by side: a canary imitating an open Node-RED cannot tell a Siemens device from any other open Node-RED, and VulnCheck's own conclusion is about "Node-RED instances without adminAuth", not about one vendor. The CVE, however, covers the Siemens device only. Whether another vendor's product has the same property is that vendor's question to answer, and a flaw record for it, if one exists, is a separate record.

Zoom

The word "exploited" needs the same care. In VulnCheck's post it means one canary event on 30 October and a count of 16 events from the same address by 1 November, with several payloads. It does not mean a compromised device or a compromised organisation. A headline that reads "Siemens Node-RED flaw exploited" compresses a Siemens device, a decoy and a class of software into three words. For context on the same device family, this site's earlier briefing on nine CISA ICS advisories notes the IoT2050 Advanced among products with no fix at all for the unrelated lwIP advisories.

The dates, and what the other records say about exploitation

The printed dates give several derived gaps. Reservation to publication is 43 days (29 June to 11 August). Advisory to VulnCheck's canary is 80 days, and advisory to VulnCheck's post is 83 days. VulnCheck also says its own detection artifacts shipped on 27 October, three days before the sighting and 77 days after the advisory. Those artifacts, it says, went to its Initial Access customers and include "an exploit PoC", a version scanner, packet captures, Suricata, Snort and YARA rules and internet scan queries. The post does not describe the proof of concept further.

Zoom

CISA's added assessment in the CVE record, stamped 12 August 2026 at 17:59 UTC, reads Exploitation: none, Automatable: yes, Technical Impact: total. That is a snapshot from the day after publication, 79 days before the sighting (derived). It was accurate for what was known on 12 August and says nothing about 30 October. The record itself was last updated on 12 August. Anyone who treated "Exploitation: none" as a live status would have been reading a stale field.

On the exploited list: VulnCheck says it moved the CVE into its own Known Exploited Vulnerabilities catalogue, and that it "is not in CISA's KEV at the time of writing". This site read the CISA catalogue file at about 12:26 UTC on 3 November 2026. It is version 2026.10.30, released 30 October at 17:02 UTC, with 1,766 entries; CVE-2026-58115 is not among them, and no entry in it mentions Node-RED or the IoT2050. That is a statement about that version only and may be overtaken at any time. The catalogue's latest addition date in that version is 30 October, the same day as the sighting.

What is stated, and what is not

What to do, in order

Items one and two come from Siemens and the Node-RED documentation. Items three, four, five and six are this site's suggestions, and items four and five say where they lean on VulnCheck. None involves testing anything against a system you do not own.

Technical details

The primaries print the artifacts below. Each block names who published it and the date read, and is copied exactly except where marked as defanged or derived. VulnCheck's post also prints a flow definition, an encoded string and the decoded dropper commands; those are deliberately not reproduced here. Neither Siemens nor VulnCheck prints a hash of the bot, because VulnCheck did not retrieve it.

First, the CVE description, which Siemens wrote as the CVE numbering authority. It is the shortest accurate statement of the flaw and the text any asset inventory or scanner should be matched against.

A vulnerability has been identified in SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2) (All versions < V4.3.4.1 running Industrial OS with Node-RED installed). Affected 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.
This could allow an unauthenticated remote attacker to create malicious flows through the HTTP interface in order to execute arbitrary code on the underlying server with maximum privileges.

The affected product, fix and mitigations as the Siemens advisory prints them. Use the product line to find devices and the fix line as the target version.

SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2)
All versions < V4.3.4.1 running Industrial OS with Node-RED installed
affected by CVE-2026-58115

Remediation: Update to V4.3.4.1 or later version

Mitigations:
Uninstall Node-RED
Harden the Node-RED installation (see Node-RED User Guide)

General security recommendations:
As a general security measure, Siemens strongly recommends to protect network access to devices with appropriate mechanisms.

The scores and weakness type. Both vectors say no privileges and no user interaction are needed, over the network. These are Siemens's assignments.

CVSS v3.1 Base Score 10.0
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

CVSS v4.0 Base Score 10.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

CWE-306: Missing Authentication for Critical Function

The CISA added assessment in the CVE record, with its timestamp. The timestamp is the important part: these values date from 12 August.

CISA ADP Vulnrichment, role: CISA Coordinator, SSVC version 2.0.3
timestamp: 2026-08-12T17:59:33.476267Z
Exploitation: none
Automatable: yes
Technical Impact: total

The exploited list check. This block is derived by this site from the CISA file, not printed by CISA, and it can be overtaken at any time.

catalogVersion: 2026.10.30
dateReleased: 2026-10-30T17:02:45.3665Z
count: 1766
CVE-2026-58115 listed: no
Any entry mentioning Node-RED or IoT2050: no

The Node-RED documentation lines that define the default and the control. A defender can read them against a device's settings file. The property is called adminAuth. The admin API documentation also describes a read only request to the login path of the admin API that returns the active authentication scheme, and says an empty result means no active authentication. Run that only against devices you own.

By default, the Node-RED editor is not secured - anyone who can access its IP address can access the editor and deploy changes.
This is only suitable if you are running on a trusted network.

The Node-RED admin API is secured using the adminAuth property in your settings.js file.
If that property is not set the Node-RED admin API is accessible to anyone with network access to Node-RED.

The request and reply shapes VulnCheck prints for the canary event, in words and values it published. The reply is the standard answer to a flow deployment, which is why VulnCheck's signature counted the event as a success. The revision hash VulnCheck prints is not reproduced here, because it is a canary record value with no use to a defender.

Request:  POST /flows
User agent: curl/8.5.0
Body: a Node-RED flow definition (not reproduced here)

Reply:    HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 74
Body: one field named rev holding a 64 character revision hash

The network indicators from VulnCheck's table, further defanged by this site (hxxp and bracketed dots). Treat them as a starting point for log searches, not a block list: VulnCheck says the sending address is shared or rented infrastructure, and a hit in either direction does not identify an operator.

Attack source (VulnCheck places it in a major cloud provider's network):
4[.]201[.]105[.]116

Payload server, port 8080:
85[.]215[.]73[.]250
hxxp://85[.]215[.]73[.]250:8080/bot-linux-amd64
hxxp://85[.]215[.]73[.]250:8080/wget.sh

Second payload server, port 38472:
45[.]194[.]90[.]57
hxxp://45[.]194[.]90[.]57:38472/.sys_update

File names and paths that VulnCheck says the payloads used, taken from its description of the decoded commands. They are hunting artefacts, not commands. The first is a memory backed location, which VulnCheck says is why nothing is written to disk and why the file vanishes on reboot unless the bot persists some other way.

/dev/shm/.b      (first dropper: hidden file in a RAM backed directory)
/tmp/.s          (second variant: staged script)
/tmp/.kworker    (different payload server: name mimics a kernel worker thread)

The detection artifacts VulnCheck says it shipped on 27 October are available only to its Initial Access customers and were not read. The post lists a version scanner, packet captures, Suricata, Snort and YARA rules and internet scan queries for Shodan, Censys, GreyNoise, FOFA and ZoomEye.

The question that exposes the gap

A decoy was told it had been compromised 80 days after Siemens published a fix. The decoy is not the problem. The question is the one the records leave open: if the Node-RED editor on a device in your plant answered a stranger with no login, which of your records would have told you, and would any of them have changed in the 80 days since Siemens printed the fix?

Key facts