Node-RED Vulnerability CVE-2026-58115: Who Is Affected and How adminAuth Protects

Running Node-RED and unsure whether the instance can be reached without a login? WZ-IT checks Node-RED instances for reachability and configuration, sets up adminAuth and access through a VPN, and operates Node-RED with monitoring and maintenance, see Node-RED, IoT and CVE monitoring. Book a meeting

On 11 August 2026, Siemens published the advisory SSA-834709 on missing authentication in Node-RED on SIMATIC IoT2050 devices, with the identifier CVE-2026-58115 and CVSS 10.0. On 2 November 2026, VulnCheck reported that a honeypot had recorded a complete attack on 30 October: a single request to the admin API submitted a flow meant to download and start a Linux bot. Media such as The Register reported from 2 November.

The reports blur two things. The identifier belongs to a Siemens product. The observed attack, however, hits Node-RED instances without adminAuth, according to VulnCheck. This article separates the two using the primary sources, gives versions, ratings and exploitation status in tables, and provides check commands and a configuration example for administrators. All information reflects 9 November 2026.

Table of Contents

1. The vulnerability at a glance
2. Core flaw or product flaw: what the sources say
3. Affected devices and fixed version
4. What VulnCheck observed
5. Exploit status and KEV
6. Which Node-RED installations are at risk
7. Check commands for administrators
8. Setting up adminAuth in settings.js
9. Keeping the editor off the public internet
10. Signs of compromise
11. Checklist: hardening Node-RED
12. Our approach at WZ-IT
13. Further guides

The vulnerability at a glance

Sources: Siemens SSA-834709, NVD CVE-2026-58115, VulnCheck.

The vector describes a flaw that can be exploited over the network without privileges and without user interaction. S:C (Scope Changed) means, per the CVSS 3.1 specification, that the vulnerability can affect resources in components beyond its own security scope. Siemens rated the flaw this way.

Core flaw or product flaw: what the sources say

Whether CVE-2026-58115 is a flaw in Node-RED itself is answered differently by the sources on three levels.

Assessment. According to the sources, CVE-2026-58115 is a product flaw of Siemens: on the affected devices, authentication is not enforced on the Node-RED HTTP interface ("do not enforce authentication"). For the Node-RED core we found neither a fix nor an advisory, and the project documents the open state without configuration as the default. In our assessment this is not a weakness in the Node-RED code but an operating state: the attack works against instances whose admin API is reachable without a login, such as the delivery state without adminAuth, as soon as the attacker reaches the port. That VulnCheck uses the Siemens identifier for all such instances is VulnCheck's attribution and does not appear that way in the Siemens advisory. VulnCheck itself notes that its description rests on the canary signature and the observed traffic. We found no statement by the Node-RED project on the case.

The class of error is not new. For the Pilz IndustrialPI 4 industrial PC, the same pattern has applied since 2025: VDE-2025-045 states that authentication is not configured by default for the Node-RED server, likewise with CVSS 10.0. The following table separates the cases; FUXA is a different product that only embeds Node-RED as a plugin.

Affected devices and fixed version

Source: Siemens SSA-834709, revision V1.1 of 4 November 2026.

Five notes for classification:

• Only with Node-RED installed. The advisory applies to devices running Industrial OS with Node-RED. Without Node-RED installed, this attack surface does not exist.
• Product list. According to the revision history, revision V1.1 of 4 November clarified the list of affected products and adjusted the title and summary. The CISA notice ICSA-26-237-03, in contrast, lists only the IoT2050 Advanced. The current Siemens version with four models is authoritative.
• Version notation. Siemens writes V4.3.4-1; the machine-readable version (CSAF) and some databases use 4.3.4.1. The same release is meant.
• Mitigations without an update. Siemens names two: uninstall Node-RED, or harden the installation per the Node-RED guide. Devices should also run only in a protected network, following the Siemens Industrial Security guidelines.
• What the advisory does not say. It gives no command to read the installed version and does not describe which login the fixed image presets. Determine the version from the Siemens product documentation; whether access is protected after the update is shown by the check commands below.

What VulnCheck observed

VulnCheck describes the observation in the report Exploitation Targeting Node-RED (2 November 2026, updated 1 November). The data comes from VulnCheck's canary telemetry, a honeypot infrastructure.

How the attack works. A single POST /flows (user agent curl/8.5.0) delivers a flow in three parts: an empty tab, an inject node that fires once after one second, and an exec node. The exec node runs whatever a base64-encoded string contains, so simple filters for wget or curl in the request body find nothing. The canary answered like a vulnerable instance, with HTTP 200 and a new revision hash; that is why the VulnCheck signature records the event as a successful exploit. The sequence follows from the decoded command; the report does not show a download or an execution on the canary.

What is unknown. VulnCheck retrieved neither the bot file nor wget.sh or .kworker. Whether they are a cryptominer, a DDoS bot, a reverse shell or something else is open. The report gives no hashes. According to VulnCheck, the same address produced 125 hits over recent days against eight CVEs in Apache Solr, Camunda, Gitea, MLflow, Traefik, Joomla and Node-RED; VulnCheck reads this as opportunistic mass scanning rather than a targeted attack, and stresses that an address in the Microsoft cloud says little about the operator.

Exploit status and KEV

None of the sources checked gives figures for openly reachable instances, and we have no scan data of our own. A statement such as "thousands of exposed instances" is therefore not substantiated.

Which Node-RED installations are at risk

Three assumptions that do not hold:

• "It is a Node-RED bug, so an update helps." Releases 5.0.9 and 4.1.17 do not change the default; the login has to be configured.
• "The instance is behind a firewall." That narrows the field to hosts with network access but does not protect against every machine on the same network. With Docker, published ports also bypass ufw firewall rules (see below).
• "A changed editor path protects." httpAdminRoot moves the paths but is not access control.

Check commands for administrators

Run all commands only against your own systems. The output shows how the instance stands on the network.

1. Which address does Node-RED listen on?

sudo ss -tlnp | grep 1880

If the output shows 0.0.0.0:1880, *:1880 or [::]:1880, the process listens on all interfaces. With 127.0.0.1:1880 it is directly reachable locally only; a proxy or tunnel on the host can still pass it on. Port 1880 is the default (uiPort); if it was changed, use your own number.

2. Docker: how is the port published?

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Ports}}'

Under Ports, 0.0.0.0:1880->1880/tcp or [::]:1880->1880/tcp means the port is published on all host interfaces. 127.0.0.1:1880->1880/tcp is reachable from the host only from Docker 28.0.0 onwards (for older versions see below). Docker calls published ports "insecure by default" (Docker, port publishing) and diverts the traffic before the ufw rules, so a ufw block does not protect published ports (Docker, packet filtering).

3. Is the login active?

curl -s --max-time 5 http://127.0.0.1:1880/auth/login; echo
curl -s -o /dev/null -w '%{http_code}\n' --max-time 5 http://127.0.0.1:1880/flows

According to the admin API, /auth/login returns {} when no login is active. With an active login you get an object with "type":"credentials", or "type":"strategy" when signing in through Passport strategies (source code). GET /flows answers HTTP 200 without a token if the instance is open or an anonymous default user with read permission is set up (documentation), and HTTP 401 if a token is required. The status code alone does not show which component is answering: an upstream proxy can return 401 as well. The combination of /auth/login and /flows is what counts. The check deliberately contains no deploy attempt (POST /flows). If the instance sets httpAdminRoot, the path follows it, for example /admin/flows.

4. The same check from another machine on the network. Replace 127.0.0.1 with the server's address. If /auth/login returns {} from there, the admin API is reachable without a Node-RED login at least from that machine; whether the same applies to other source addresses depends on upstream controls such as a firewall or proxy. If /flows returns HTTP 200 and the response is a JSON array of node objects, at least read access is possible; a 200 status alone can also come from a proxy or fallback page. A small script checks several instances in turn:

#!/usr/bin/env bash
# Checks one of your own Node-RED instances: is the admin API reachable without a login?
# Usage: ./check-nodered.sh http://192.0.2.10:1880
BASE="${1:-http://127.0.0.1:1880}"

login=$(curl -s --max-time 5 "$BASE/auth/login")
echo "Login scheme (GET /auth/login): ${login:-no response}"

code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 5 "$BASE/flows")
echo "GET /flows without token: HTTP $code"
case "$code" in
  200)
    if [ "$login" = "{}" ]; then
      echo "-> OPEN: no login active, flows readable, deploy without login to be expected"
    else
      echo "-> flows readable without token, login active: check the anonymous default user and its permissions"
    fi ;;
  401) echo "-> token required (adminAuth or an upstream access control)" ;;
  000) echo "-> not reachable" ;;
  *)   echo "-> unexpected, check the path prefix (httpAdminRoot) and proxy" ;;
esac

We tested the script against a local test server that reproduces the responses the admin API documentation describes: open instance, active login, anonymous read access, status 401 without a login scheme, unexpected status and unreachable server. A real Node-RED instance was not part of the test.

Setting up adminAuth in settings.js

The adminAuth setting protects the editor and the admin API. In the bundled settings.js it is commented out (template in the repository). With the script-based installation the file is in the user directory ~/.node-red/settings.js, in the official Docker image at /data/settings.js. Which file Node-RED loads is shown at startup in the log line "Settings file".

Step 1: generate a password hash.

node-red admin hash-pw

The command exists from Node-RED 1.1.0 and asks for the password. In a Docker container it runs as the Docker image describes:

docker exec -it mynodered npx node-red admin hash-pw

The value printed is a bcrypt hash and starts with $2a$ or $2b$. The example hashes in the documentation belong to known passwords and must not be reused.

Step 2: add the block to settings.js. The following configuration follows the official guide; hashes are placeholders:

module.exports = {
    uiPort: process.env.PORT || 1880,

    // Accept the whole HTTP listener (editor, admin API, HTTP In, dashboard) only on the local host
    // or a VPN address (omit in a Docker container, see below)
    uiHost: "127.0.0.1",

    // Editor and admin API: enforce login
    adminAuth: {
        type: "credentials",
        users: [
            {
                username: "admin",
                password: "$2b$08$HASH-FROM-hash-pw-GOES-HERE",
                permissions: "*"
            },
            {
                username: "readonly",
                password: "$2b$08$OTHER-HASH-FROM-hash-pw",
                permissions: "read"
            }
        ],
        sessionExpiryTime: 86400
    },

    // HTTP In routes and node-red-dashboard: separate user, separate hash
    httpNodeAuth: { user: "dashboard", pass: "$2b$08$THIRD-HASH-FROM-hash-pw" }
};

In an existing settings.js, only add or uncomment the uiHost, adminAuth and httpNodeAuth lines; the rest stays. In a Docker container uiHost is omitted (see below). We loaded the example's syntax with Node.js and checked it; we did not test it with a running Node-RED instance.

Step 3: restart Node-RED.

Step 4: verify the result. GET /auth/login shows "type":"credentials", and GET /flows returns HTTP 401 without a token (check command 3) as long as no anonymous default user is set up. If no login dialog appears when opening the editor, usually a different file was edited from the one Node-RED loads, or the service was not restarted.

Source: Node-RED, Securing Node-RED and configuration. With permissions: "read" you can create users with read-only access; with default: { permissions: "read" } in adminAuth, everyone without a login additionally gets this read access, which the guide describes as an option. The permissions of the default user are freely configurable; with permissions: "*", everyone without a login would also have write access. Upstream access controls such as a reverse proxy or httpAdminMiddleware can protect the admin API as well; adminAuth is the standard solution the guide describes. Anyone who wants to sign in to the editor through OAuth or OpenID will find the variant with Passport strategies in the guide.

Keeping the editor off the public internet

adminAuth is the first layer. The second is that the editor cannot be reached from the internet at all. Usually only a small group of administrators needs the admin interface.

• Bind to localhost or a VPN address only. With uiHost: "127.0.0.1", Node-RED listens locally only, and that applies to the whole HTTP listener: HTTP In routes and dashboards are then reachable locally only as well. If the editor should be reachable over a private network, uiHost can point to the host's VPN address. The default is 0.0.0.0, that is, all IPv4 interfaces (configuration documentation). In a Docker container uiHost stays unchanged (see the next point).

• Publish the Docker port on localhost only. Docker forwards published ports to the container's address in the default bridge network; a process that listens only on 127.0.0.1 inside the container does not accept these connections. Node-RED therefore stays on 0.0.0.0 inside the container, and the restriction lies solely in the host address of the -p flag. Instead of -p 1880:1880, give the port with an address:

  docker run -d -p 127.0.0.1:1880:1880 -v node_red_data:/data --name mynodered nodered/node-red
  

  In Compose the entry is "127.0.0.1:1880:1880" under ports. In Docker versions before 28.0.0, machines in the same layer 2 segment could also reach ports published to localhost (Docker, port publishing); on older Docker hosts an update is advisable.

• Access through a mesh VPN or WireGuard. Administrators then reach the editor only with a device signed in to the private network. The pattern is described on the pages for VPN and secure access and NetBird and in the article Replacing Your VPN: From Classic VPN to Zero Trust and Mesh VPN.

• Reverse proxy for HTTP In paths only. If webhooks or a dashboard have to be public, only the paths meant for that (httpNodeRoot, such as /ui) belong behind the proxy, with httpNodeAuth or a token in the flow. The admin API paths (/flows, /auth, /settings, /nodes) stay outside. The editor keeps a WebSocket connection to the runtime open (source code comms.js); behind a proxy, it must pass that through.

• Firewall at the perimeter. Block port 1880 at the network edge and test the result from outside rather than just reading the rule.

• No unnecessary privileges. Run Node-RED as its own user rather than root. The same applies to the container: where not needed, no -u root and no mounted Docker socket.

These layers do not replace adminAuth but complement it. If the VPN and adminAuth are configured independently of each other, a fault in one of the two layers alone is usually not enough for access; this is not a guarantee.

Signs of compromise

The checks follow the traces in the VulnCheck report. Not finding them proves nothing: attackers can change file names and addresses, and VulnCheck does not know what the malware does.

# List flows with command execution or incoming HTTP routes
jq -r '.[] | select(.type=="exec" or .type=="http in") | [.type, .id, (.command // .url // "")] | @tsv' ~/.node-red/flows.json

# Without jq
grep -n -E '"type": ?"(exec|http in)"' ~/.node-red/flows.json

# Traces from the VulnCheck report on the host
ls -la /dev/shm/.b /tmp/.s /tmp/.kworker 2>/dev/null
ps -eo pid,user,args | grep -E '/dev/shm|\.kworker|\.sys_update' | grep -v grep
sudo ss -tnp | grep -E '85\.215\.73\.250|45\.194\.90\.57'

With Docker the file sits in the volume; its content can be evaluated with docker exec mynodered cat /data/flows.json | jq .... The paths apply to the default settings; flowFile and userDir in settings.js and Node-RED projects can move them. An exec node is not suspicious in itself, and many flows use it legitimately. Exec nodes without a known purpose, with encoded commands, or behind an HTTP In endpoint stand out.

If traces exist or misuse cannot be ruled out:

1. Disconnect the instance from the network and secure the flows file, logs and process list before changing anything.
2. Treat all credentials readable on the host as compromised and rotate them: access from flows (MQTT, databases, APIs), SSH keys, cloud tokens. This is our assessment; the sources give no list.
3. Rebuild the host or container from a clean state and check the flows node by node before reusing them. An update alone does not remove injected flows.
4. Set adminAuth and the network restriction before the instance goes back online.
5. Check reporting duties. Under Art. 33 GDPR, the controller must report a personal data breach to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to the rights and freedoms of natural persons; a processor notifies the controller of a breach without undue delay. Where a high risk is likely, the controller must also notify the data subjects without undue delay under Art. 34 GDPR, subject to the exceptions in Art. 34(3) (EDPB). Entities within the scope of the NIS 2 Directive submit for significant incidents under Art. 23(4) an early warning without undue delay and within 24 hours of becoming aware of the incident, an incident notification within 72 hours of becoming aware of it (trust service providers: 24 hours), an intermediate report on request, and a final report not later than one month after the incident notification; if the incident is still ongoing at that point, a progress report follows, and the final report within one month of handling the incident. Scope and details depend on national implementing law. Which duty applies depends on the role (controller or processor), on whether personal data was affected, whether the entity is covered and how significant the incident is. The assessment in the individual case should be made with the data protection officer or legal counsel; responsibility stays with the party under the obligation.

Checklist: hardening Node-RED

Our approach at WZ-IT

WZ-IT installs, hosts and operates Node-RED with monitoring, backups and maintenance and, within the IoT services, connects PLC and HMI systems. For a report like CVE-2026-58115 the work runs in five steps:

1. Take inventory. Record Node-RED instances, versions, ports, container mappings and devices such as the IoT2050, including those another team set up.
2. Check reachability. Use the commands above to establish whether admin API and editor are reachable without a login, from inside and from outside.
3. Secure. Set adminAuth and httpNodeAuth, restrict binding and port mapping, and route access through a mesh VPN or WireGuard. For IoT2050 devices the procedure follows the Siemens advisory.
4. Check for traces. Review flows and host for the indicators; if suspicious, rotate credentials in a controlled way and rebuild the instance cleanly.
5. Monitor continuously. Add instances to CVE monitoring, which evaluates vendor advisories alongside the NVD. A broader review of a server's configuration and access is provided by the server audit.

Support, consulting and implementation by WZ-IT.

Further guides

• Node-RED MQTT dashboard for sensor data, how Node-RED ingests and displays measurements.
• n8n Alternative: n8n, Activepieces and Node-RED Compared, licences, operations and security advisories of the three tools.
• ThingsBoard, Grafana & ChirpStack in the Modern IoT Stack, where Node-RED sits in IoT operations.
• CVE Monitoring for Self-Hosted Software, how vulnerabilities are tracked in a structured way.
• Replacing Your VPN: From Classic VPN to Zero Trust and Mesh VPN, access to internal services without public ports.
• LiteLLM Vulnerability: Check Versions and Harden the Gateway, another case in which a management interface has to be secured.
• IoT services from WZ-IT and Node-RED operations, the hubs for this topic.
• SSHole (CVE-2026-123158): check OpenSSH on Alpine - another current security case (as of November 2026)
• Linux kernel TCP flaw CVE-2026-98432: patch Proxmox, Debian, Ubuntu - another current security case (as of November 2026)
• APT vulnerability CVE-2026-109518 in Debian and Ubuntu - another current security case (as of November 2026)
• CWPdoor: check for the Control Web Panel backdoor - another current security case (as of November 2026)

Have your Node-RED instances checked? We establish which instances can be reached without a login, implement adminAuth and access over VPN, and add Node-RED to CVE monitoring. Book a meeting

Sources

• Siemens ProductCERT, SSA-834709 (CVE-2026-58115)
• NVD, CVE-2026-58115
• CISA, ICSA-26-237-03 Siemens SIMATIC IoT2050 Advanced
• CISA, Known Exploited Vulnerabilities Catalog
• VulnCheck, Exploitation Targeting Node-RED, a Tool Embedded in ICS Products
• The Register, Node-RED flaw exploited (2 November 2026)
• Node-RED Docs, Securing Node-RED
• Node-RED Docs, Runtime configuration
• Node-RED Docs, Admin API: GET /auth/login
• Node-RED Docs, Admin API: GET /flows
• Node-RED Docs, Admin API: POST /flows
• Node-RED Docs, Docker
• Node-RED Docs, Raspberry Pi
• node-red-docker, README
• Node-RED, settings.js (template)
• Node-RED, Security Advisories
• Node-RED, Changelog
• Node-RED, Release 4.1.17
• Node-RED, source code editor-api comms.js
• Node-RED, source code editor-api auth/index.js
• Docker Docs, Port publishing and mapping
• Docker Docs, Packet filtering and firewalls
• CERT@VDE, VDE-2025-045 Pilz IndustrialPI
• NVD, CVE-2025-41656
• NVD, CVE-2026-25938
• FUXA, Security Advisory GHSA-v4p5-w6r3-2x4f
• Cisco Talos, TALOS-2026-2419 (FUXA)
• NVD, CVE-2026-42922
• FIRST, CVSS v3.1 Specification Document
• EDPB, Data breaches
• EUR-Lex, Directive (EU) 2022/2555 (NIS 2)
• Siemens, Operational Guidelines for Industrial Security