VulnCheck’s Honeypot Caught Exploitation of a CVSS 10 “Node-RED Flaw,” but the CVE Names One Siemens Device, and Upstream Node-RED Ships With No Login on Its Admin API

On November 2, VulnCheck published a write-up saying one of its canaries, a honeypot that answers requests the way a vulnerable instance would, recorded an attacker exploiting CVE-2026-58115 on October 30. SecurityWeek headlined the story “Critical Node-RED Flaw Exploited in Attacks,” and The Register wrote “Max-severity bug in widely used OT programming tool exploited to deliver Linux malware.” The record behind those headlines is narrower. Siemens published the CVE and its advisory on August 11 for one product, the SIMATIC IoT2050 Advanced, and the advisory lists no other device. The request VulnCheck recorded is a single unauthenticated call to Node-RED’s admin API, and Node-RED ships without a login on that API.

We checked that last point by running stock Node-RED 5.0.9, the latest release on November 3, on localhost. With the settings file it ships with, a request to the deployment endpoint with no credentials was accepted. After we turned on adminAuth, the same request was refused. That makes exposure a question of how each install is configured, and a CVE feed or a version scan does not answer it for installs that are not Siemens devices. The read-only test that does answer it is one request to /auth/login, shown below.

At a glance

What Siemens and NVD say

Siemens published advisory SSA-834709, titled “Missing Authentication Vulnerability in Node-RED on SIMATIC IoT2050 Advanced with Industrial OS,” on August 11. It shows version V1.0 and no later revision; its machine-readable CSAF file has the same single history entry. The summary says devices running Industrial OS “with Node-RED installed” contain a flaw in the Node-RED HTTP interface that “could allow an unauthenticated remote attacker to create malicious flows and execute arbitrary code on the underlying server with maximum privileges.” The only affected product it lists is “SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2)”.

Siemens’s remediation is “Update to V4.3.4.1 or later version,” and its two mitigations are to “Uninstall Node-RED” or to “Harden the Node-RED installation (see Node-RED User Guide)”. The advisory does not say what V4.3.4.1 changes, and the support page it links for the download answered our scripted request with Access Denied, so we could not read the release notes.

The NVD record was created on August 11 at 13:19 UTC with Siemens as the source. When we fetched it from the NVD API on November 3, the status was Awaiting Analysis, the last modification was October 23, and the only scores were Siemens’s own, 10.0 under CVSS v3.1 and 10.0 under v4.0. The record has no product configuration, so a scanner that relies on NVD’s product data has nothing to match yet, and its only reference is the Siemens advisory. It does carry an SSVC entry from CISA, stamped August 12, that says exploitation none, automatable yes and technical impact total. That stamp predates every VulnCheck report, and it still said the same on November 3.

What VulnCheck’s canary recorded

One small discrepancy: SecurityWeek says VulnCheck warned on Sunday, while the blog post is dated Monday, November 2 and has an update section dated November 1.

What the request was

According to VulnCheck, the attacker sent one POST to /flows from curl/8.5.0. The body defined three nodes: an empty tab, an inject node set to fire once after a one-second delay, and an exec node wired to it. The exec node’s command carries a base64-encoded dropper behind three layers of encoding. VulnCheck decoded it: the dropper downloads a Linux binary named bot-linux-amd64 from a separate server into /dev/shm/.b, a memory-backed path, runs it detached, and never checks whether the download worked. In VulnCheck’s words, “Wire one to the other and the flow executes a command as soon as it is deployed, with no further interaction.” We are not reproducing the request itself.

Where the evidence stops

VulnCheck says plainly that it “did not retrieve or analyze the bot binary itself,” and so it makes “no claims about its capabilities.” Its canary “answered the request with HTTP 200 and a new flow revision hash, exactly as a vulnerable instance would,” and “That response is why the signature records this event as a successful exploit.” So the exploitation in the headlines is, as far as the public record shows, a decoy’s reply to a complete exploit request, not a confirmed compromise of a real device, and none of the three accounts we read names a victim. SecurityWeek’s story never mentions canaries; The Register refers to them twice, once inside a quotation and once in passing.

The same address logged 125 hits against eight CVEs across VulnCheck’s wider canary network, among them Apache Solr (CVE-2019-17558), Camunda, Gitea, MLflow, Traefik and Joomla. Its Node-RED hits used at least five user agents and several payloads. VulnCheck reads that breadth as “opportunistic mass scanning rather than a targeted attack,” and says the variety fits “shared or rented infrastructure used by more than one operator.”

On November 1 VulnCheck added three variants: a second dropper from the same server that fetches a staged shell script, a different payload server whose file is saved as /tmp/.kworker (a name that mimics a kernel worker thread), and persistent webshells. For the webshells, “the flow exposes an http in endpoint” wired through a function node to an exec node, so the attacker can run commands later by passing them in a query parameter. VulnCheck notes that “This backdoor survives even if a memory-backed implant is lost on reboot.”

Indicators VulnCheck published

The file paths VulnCheck lists on a victim are /dev/shm/.b, /tmp/.s and /tmp/.kworker. The registry lookups are ours; the rest is VulnCheck’s. VulnCheck cautions that an address in a major cloud provider’s range is “more often a compromised or rented virtual machine than the operator’s own hardware,” so abuse reports are worth sending but “the address says little about who is behind it.”

Why “Node-RED flaw” overstates the CVE and understates the exposure

The Siemens CVE does not describe a bug in Node-RED’s code. It describes devices that “do not enforce authentication on the Node-RED HTTP interface.” Upstream Node-RED does not enforce it by default either, and the project says so in its own documentation. We read each place where that default is written down.

What we measured on a stock install

We ran Node-RED 5.0.9 on Node.js v24.22.2 on Windows 11, bound to 127.0.0.1 only. For the first run we used the settings.js the package ships with and added only -D uiHost=127.0.0.1 on the command line so the instance never listened on the network. For the second we used a minimal settings file holding the adminAuth block from the Node-RED guide (with its sample password hash) and the same uiHost line. The write test deployed an empty flow list; we did not deploy an exec node or any flow that runs a command.

The unauthenticated deployment on the default install uses the same route VulnCheck recorded, so on any install the Siemens advisory does not cover, the adminAuth setting is what separates exposed from not exposed. The Admin API docs describe GET /auth/login as “Get the active authentication scheme” and list “No active authentication” as {}, which is what the default install returned.

What that means for inventory

A scanner keyed to CVE-2026-58115 or to Siemens’s product list finds the Siemens devices. It does not find a Raspberry Pi or a container that runs Node-RED with no adminAuth, because nothing assigns those a CVE, and it finds another vendor’s appliance only if that vendor has published its own advisory. VulnCheck notes that “Emerson’s documentation also highlights its use of Node-RED, although we haven’t validated whether their products are impacted by this vulnerability.” The Node-RED project treats the default as a deployment choice: its GitHub security advisories list two published entries, both from February 2021 (CVE-2021-21297 and CVE-2021-21298), and neither concerns this. No primary source we found gives a count of reachable Node-RED instances, so we give none; VulnCheck says it shipped Shodan, Censys, GreyNoise, FOFA and ZoomEye queries to customers on October 27, but its post gives no count.

What to check today

If you run a SIMATIC IoT2050 Advanced

Update to V4.3.4.1 or later, as Siemens recommends. If you cannot, Siemens’s other mitigations are to uninstall Node-RED or to harden it, which is the adminAuth step below. Siemens also “strongly recommends to protect network access to devices with appropriate mechanisms.”

Ask any Node-RED you run whether it needs a login

From a machine that sits where an attacker would, outside your trust zone, request the authentication scheme. This is a read-only call documented in the Node-RED Admin API, and we ran its equivalent against 5.0.9 above.

curl -s http://HOST:1880/auth/login

An answer of {} means no authentication is configured, so anyone who can reach that port can deploy flows. An answer that starts with {"type":"credentials" means a login is required. If you changed httpAdminRoot to a path, put that path in front of /auth/login; a 404 can mean the admin endpoints are disabled, which is covered below. A reverse proxy that adds its own login answers for itself, so run the check against the Node-RED port as well.

Turn on adminAuth, and secure HTTP In routes separately

Generate each password hash with node-red admin hash-pw (documented for Node-RED 1.1.0 and later, and it worked on 5.0.9), then add the properties to settings.js and restart. This is the same shape we ran in our tests; never reuse the sample hash from the documentation.

// settings.js (Node-RED 5.0.x)
adminAuth: {
    type: "credentials",
    users: [{
        username: "admin",
        password: "PASTE_BCRYPT_HASH_HERE",
        permissions: "*"
    }]
},
httpNodeAuth: { user: "user", pass: "PASTE_BCRYPT_HASH_HERE" },
// Optional: listen on the local machine only and put a proxy or VPN in front
uiHost: "127.0.0.1",

adminAuth protects the editor and the admin API, not the routes that flows expose. The guide says “The routes exposed by the HTTP In nodes can be secured using basic authentication” through httpNodeAuth. We tested the gap: with adminAuth on and httpNodeAuth unset, a harmless flow that serves /status answered an anonymous GET with 200. After we set httpNodeAuth the same request got 401, and a request with the Basic credentials got 200 again. A webshell flow like the one VulnCheck describes is such a route, so turning on adminAuth does not close one that is already planted.

If a deployed device does not need the editor or the admin API at all, the configuration reference says that with httpAdminRoot set to false “all admin endpoints are disabled. This includes both API endpoints and the editor UI.” In a third run on 5.0.9 with only that setting changed (plus uiHost), GET /auth/login, GET /flows and the empty-list POST /flows all returned 404. That also removes the editor, so it suits fixed-function devices better than development machines.

Look for what VulnCheck saw

ls -la /dev/shm/.b /tmp/.s /tmp/.kworker 2>/dev/null

That prints nothing when none of the three files exists. The memory-backed file disappears at reboot, so an empty result is weak evidence. A better place to look is the flow file: Node-RED saves deployed flows there, as we saw in our second test, and VulnCheck says the webshell variant survives a reboot. Point the script below at your flow file (flows.json in the shipped settings, set by the flowFile option, in the Node-RED user directory, which the configuration docs give as $HOME/.node-red by default). It lists exec nodes and HTTP In routes and flags the markers VulnCheck described in the dropper (base64, wget, curl, /dev/shm, hidden /tmp names, nohup, setsid, chmod), an exec node that appends the message payload to its command, and a tab that has both an HTTP In route and an exec node.

# audit_flows.py
# List the exec nodes and HTTP In endpoints in a Node-RED flow file and flag the patterns VulnCheck described.
# usage: python audit_flows.py /path/to/flows.json      (exit 0 = nothing flagged, 1 = flagged, 2 = unreadable)
import json
import sys

MARKERS = ("base64", "wget", "curl", "/dev/shm", "/tmp/.", "nohup", "setsid", "chmod +x")

try:
    with open(sys.argv[1], encoding="utf-8") as f:
        data = json.load(f)
except (OSError, ValueError) as err:
    print("cannot read flow file:", err)
    sys.exit(2)

nodes = [n for n in (data["flows"] if isinstance(data, dict) else data) if isinstance(n, dict)]
execs = [n for n in nodes if n.get("type") == "exec"]
http_in = [n for n in nodes if n.get("type") == "http in"]
print(f"{len(nodes)} nodes: {len(execs)} exec, {len(http_in)} http in")

flagged = False
for n in execs:
    cmd = str(n.get("command", ""))
    hits = [m for m in MARKERS if m in cmd.lower()]
    appends = n.get("addpay") not in (False, "", None, "false")
    if hits or appends:
        flagged = True
    note = ("  <- markers: " + ", ".join(hits) if hits else "") + ("  <- appends the message payload" if appends else "")
    print(f"exec  id={n.get('id')} tab={n.get('z')} command={cmd[:60]!r}{note}")
for n in http_in:
    print(f"http  id={n.get('id')} tab={n.get('z')} {str(n.get('method')).upper()} {n.get('url')}")

mixed = {n.get("z") for n in execs} & {n.get("z") for n in http_in}
for tab in sorted(mixed, key=str):
    flagged = True
    print(f"tab {tab} has both an HTTP In endpoint and an exec node  <- webshell shape")
print("FLAGGED" if flagged else "nothing flagged")
sys.exit(1 if flagged else 0)

On the flow file Node-RED wrote during our second test (four nodes, one HTTP In route, no exec node) it prints this and exits with status 0:

4 nodes: 0 exec, 1 http in
http  id=hin1 tab=tabH GET /status
nothing flagged

On a ten-node file we wrote ourselves, containing an exec node whose command is a harmless base64 decode, an exec node that appends the message payload, and a tab with both an HTTP In route and an exec node, it flags all three and exits with status 1:

10 nodes: 3 exec, 2 http in
exec  id=ex1 tab=tabA command='ls -l /var/log'
exec  id=ex2 tab=tabC command=''  <- appends the message payload
exec  id=ex3 tab=tabC command='echo aGk= | base64 -d'  <- markers: base64
http  id=hin1 tab=tabB GET /status
http  id=hin2 tab=tabC GET /cmd
tab tabC has both an HTTP In endpoint and an exec node  <- webshell shape
FLAGGED

The marker list is ours, built from VulnCheck’s description. A clean result does not prove a clean host, and a flag is a reason to look, not a verdict. Also block the three indicator addresses and search logs for earlier connections to them.

What is still open

• Who is behind it. VulnCheck saw one source IP and says the infrastructure looks shared or rented; it names no actor.
• What the bot does. VulnCheck did not retrieve the binary or the staged scripts.
• Whether any real device was compromised. The public accounts describe events against VulnCheck’s canaries and name no victim.
• Which other products ship Node-RED without a login. Siemens lists one device, and VulnCheck has not validated Emerson’s products.
• What V4.3.4.1 changes. Siemens’s advisory does not say, and its download page was not readable to us.
• What CISA and NVD will do. CISA’s KEV feed did not list the CVE when we fetched it, and NVD’s analysis was pending.

Our reading. A decoy confirmed that the one-request exploit is in circulation and is being fired at unrelated software. The Siemens fix covers one image. For installs the advisory does not cover, the exposure test is the answer to /auth/login, and the fix is configuration, not a patch, which is why a story filed under “Node-RED flaw” and a CVE filed under one Siemens SKU are describing the same missing login from two sides.

Sources and related coverage

• Siemens ProductCERT, SSA-834709 (HTML and CSAF), and the NVD record for CVE-2026-58115.
• VulnCheck, Exploitation Targeting Node-RED, a Tool Embedded in ICS Products; SecurityWeek; The Register.
• Node-RED documentation: Securing Node-RED, POST /flows, GET /flows, GET /auth/login and the configuration reference.
• CISA’s Known Exploited Vulnerabilities catalog and its JSON feed.
• On sxz.io: Danfoss controllers and French supermarkets (The Register cites “the ongoing refrigeration controller hacks across Europe”), the water utility hacks on exposed PLCs, the NSA and CISA warning about Siemens PLCs (a different product family from the IoT2050), and honeypot probes against Oracle E-Business Suite.