Node-RED No Login Hijacked (CVE-2026-58115): How to Check and Secure Port 1880

CVE-2026-58115 is an authentication flaw in the Node-RED HTTP interface in the Siemens SIMATIC IoT2050 Advanced (CVSS 10.0) gateway that has now been exploited. An attacker only needs to send one request to install a malicious flow and execute commands on the server. The pattern hits all open RED-Nodes without login.

This flaw was actually announced by Siemens on August 11, 2026. What made it buzz this week were the VulnCheck (November 2) and Help Net Security (November 3) reports: the first real attack was caught on October 30, 2026, with a payload in the form of a Linux bot and webshell.

Node-RED is popular in Indonesia. Widely used on Raspberry Pi for IoT projects, factory dashboards, home automation, and simple WhatsApp bot integration. So even though the CVE is official for one Siemens product, the lessons and how to check it are relevant for almost all Node-RED users.

What exactly is the CVE-2026-58115 vulnerability?

According to Siemens advisory SSA-834709, the affected device "does not enforce authentication on the Node-RED HTTP interface." As a result, anyone who can reach the device can use a programming node capable of executing system commands. Siemens calls the code running "with maximum access rights."

The classification is CWE-306 (Missing Authentication for Critical Function). It scores 10.0 on both CVSS 3.1 and CVSS 4.0, with network vectors, no login, and no user interaction.

Please understand: this is not a memory bug or a complicated parser. Node-RED is designed so that editors can create flows, and flows can run shell commands via node exec. The problem is that Node-RED's editor and Admin APIs are natively open without login and listening on all interfaces ( 0.0.0.0:1880). If the port is reachable from the internet, "deploy flow" is the same as "execute any command".

Summary of facts

How did the attack go?

VulnCheck released a detection for this vulnerability on October 27. Three days later their canary caught the first exploit attempt. Reconstruct the flow like this:

1. Scan. The attacker scans the internet en masse looking for Node-RED that does not use adminAuth.
2. Deploy. One request POST /flows (user agent curl/8.5.0) sends a flow containing node inject which fires once after 1 second, connecting to node exec. The server replies HTTP 200 plus the hash of the new flow revision, indicating successful deployment.
3. Execution. The exec node runs echo <base64> | base64 -d | sh. The command is wrapped in three layers of encoding.
4. Settled. Dropper downloads bot-linux-amd64 with wget (the backup is curl), stores it in /dev/shm/.b, then runs it in the background with setsid or nohup.

In the November 1 update, VulnCheck saw payload variations from the same IP: a staged script in /tmp/.s, an implant from a second server stored as /tmp/.kworker (disguised as a kernel thread), and a webshell. The webshell is created with node http in (e.g. path /cmd) connected to the exec node, so that the attacker can send commands via query parameters at any time.

There are some things that are unknown. VulnCheck does not sample its bots, so their function (mining, DDoS, or other) is unclear. The bot in /dev/shm is gone on reboot, but the webshell inside the flow remains after the restart.

The attacker's IP (4.201.105.116) is on Microsoft's network (AS8075) and is geolocated to Brazil. The same IP also shot 125 times at 8 other CVEs in Apache Solr, Camunda, Gitea, MLflow, Traefik, and Joomla. VulnCheck assessed this as an opportunistic mass scan, likely of a rented or compromised VM, rather than a targeted attack.

Who is affected?

Formally, this CVE is only for SIMATIC IoT2050 Advanced. But the attack technique applies to all Node-REDs that:

• its editor/Admin API can be reached from untrusted networks (internet, guest Wi-Fi, shared VPN), and
• haven't activated adminAuth in settings.js.

Examples often encountered in the field: Raspberry Pi with port 1880 forwarded via a home or office router, cheap VPS running a nodered/node-red by -p 1880:1880 container, and industrial gateways in factories connected to office networks. VulnCheck also notes that Emerson documented use of Node-RED in its product line, but has not validated whether the product was impacted.

Ostorlab notes the scale of usage: around 92,432 npm downloads per week and over 327 million Docker Hub pulls (checked November 3, 2026). There is no source that publishes exact figures on how many instances are open on the internet.

Brief chronology

How do I check if my Node-RED is open?

Do it from a machine outside the network (for example from a VPS or cellphone tethering), then repeat from inside the network. Replace HOST with your Node-RED IP or domain.

# 1) Apakah Admin API mau membaca flow tanpa login?
#    200 = TERBUKA (bahaya), 401 = sudah butuh login
curl -s -o /dev/null -w "%{http_code}\n" http://HOST:1880/flows

# 2) Skema login yang dipakai editor
#    {} berarti tidak ada autentikasi sama sekali
curl -s http://HOST:1880/auth/login

Then check directly on the host running Node-RED:

# Node-RED mendengarkan di mana? 0.0.0.0:1880 = semua antarmuka
ss -tlnp | grep ':1880 '

# adminAuth aktif? Baris yang masih diawali // berarti belum aktif
grep -n "adminAuth" ~/.node-red/settings.js

# Versi firmware IoT2050 (aman bila >= V4.3.4.1)
cat /etc/os-release

Mitigation: what to do now?

1. SIMATIC IoT2050 Advanced users

Update to V4.3.4.1 or later as per SSA-834709. Ostorlab cautions that simply updating the Node-RED npm package does not close the gap in this device. If you can't update, Siemens recommends strengthening the Node-RED installation or uninstalling it.

2. All Node-RED installations: enable adminAuth

Create a password hash with the built-in command:

node-red admin hash-pw
# Masukkan password, salin hash yang diawali $2b$...

Then fill in ~/.node-red/settings.js and restart Node-RED:

module.exports = {
  // Hanya dengarkan di localhost bila editor diakses lewat reverse proxy/SSH tunnel
  uiHost: "127.0.0.1",

  adminAuth: {
    type: "credentials",
    users: [{
      username: "admin",
      password: "$2b$08$GANTI_DENGAN_HASH_ANDA",
      permissions: "*"
    }]
  },

  // Di server produksi yang tidak butuh editor sama sekali:
  // httpAdminRoot: false,
};

3. Reduce the attack surface

• Do not forward port 1880 on the router. Access the editor via VPN, SSH tunnel, or reverse proxy with HTTPS by logging in.
• For Docker, bind to localhost: -p 127.0.0.1:1880:1880.
• Restrict TCP 1880 to admin IPs on firewall only.
• Also protect endpoint http in and Dashboard with basic auth or OAuth, because that's the webshell's favorite path.
• Run Node-RED as a normal user, not root.

Detection: how do you know it's been hacked?

The indicators below are from VulnCheck and Ostorlab. Finding nothing is not a guarantee of safety, because failed experiments may leave no trace. Conversely, matching the indicators also needs to be confirmed.

# File yang dijatuhkan payload
ls -la /dev/shm/.b /tmp/.s /tmp/.kworker 2>/dev/null

# Node exec dan http in di flow (cek apakah memang Anda yang membuat)
grep -nE '"type": ?"exec"' ~/.node-red/flows*.json
grep -nE '"type": ?"http in"' ~/.node-red/flows*.json

# Proses mencurigakan dan koneksi ke server payload
ps -eo pid,user,cmd | grep -E '\.b$|kworker|bot-linux' | grep -v grep
ss -tnp | grep -E '85\.215\.73\.250|45\.194\.90\.57'

# Log reverse proxy: POST /flows dari IP asing
grep -E 'POST /flows' /var/log/nginx/access.log*

VulnCheck released network indicators:

If you find signs of compromise: first save flows.json, settings.js, and journald logs as evidence, disconnect the device from the internet, delete foreign flows, replace all credentials stored on the node (API tokens, database passwords, MQTT keys), then consider reinstalling. If your Node-RED stores a service token such as an API key at console.apipedia.id, revoke it and create a new key.

This "admin service exposed without login" pattern is similar to the case we discussed in the GitLab CVSS 10.0 and Node2Shell cracks in Node.js: once exposed, mass scanners usually find it within days.

FAQs

I use Node-RED on Raspberry Pi, not Siemens. Am I affected by CVE-2026-58115?

Formally no, because this CVE is assigned to SIMATIC IoT2050 Advanced. But if your editor is exposed to the internet without adminAuth, the exact same attack still works. Attackers don't check the brand of the device, they look for a Node-RED that is willing to accept POST /flows.

Does updating Node-RED to the latest version close this loophole?

Not automatic. The crux of the problem is configuration without authentication. In IoT2050, the fix is ​​in firmware V4.3.4.1. In another installation, the one that closes the gap is adminAuth and does not expose port 1880.

Is CVE-2026-58115 already in CISA KEV?

Per VulnCheck reports (November 2, 2026) and Help Net Security (November 3, 2026), not yet. This flaw has been included in VulnCheck's KEV catalog because there is evidence of exploitation.

What is the bot that the attacker installed for?

Not yet known. VulnCheck says it does not capture and analyze its binaries, so it makes no claims about its capabilities. To be sure, the attacker has full command execution on the host.

What if the Node-RED editor needs to be accessible to the team from outside the office?

Use a VPN (WireGuard, Tailscale) or an HTTPS reverse proxy by logging in, keeping adminAuth enabled, and giving each person their own account with the necessary permissions (for example "read" for monitoring only).

Source

• VulnCheck: Exploitation Targeting Node-RED, a Tool Embedded in ICS Products (2 November 2026)
• Help Net Security: Attackers exploit critical Node-RED flaw to deploy Linux bots and backdoors (November 3, 2026)
• Siemens ProductCERT: SSA-834709
• CVE Program: record CVE-2026-58115
• Ostorlab: Siemens IoT2050 Node-RED RCE, Exploited in the Wild
• IoT Tech News: Node-RED admin API flaw exploited to drop Linux bots