Siemens SIMATIC IoT2050 Node-RED Missing Authentication (CVSS 10.0): ICS Detection and Remediation Guide — CISA ICSA-26-237-03

CISA has published ICSA-26-237-03, covering a maximum-severity vulnerability in Siemens SIMATIC IoT2050 Advanced industrial IoT gateways. Devices running Industrial OS with Node-RED installed ship with missing authentication on the Node-RED HTTP interface (CWE-306: Missing Authentication for Critical Function). An unauthenticated remote attacker can create malicious Node-RED flows and execute arbitrary code on the underlying server with maximum privileges — in practical terms, root on an OT network edge device.

The flaw carries a CVSS v3 score of 10.0 — the highest possible rating — reflecting the combination of remote exploitation, no authentication requirement, no user interaction, and full system compromise. Affected sectors include Chemical and Critical Manufacturing, and these gateways frequently sit at exactly the wrong place in an architecture: bridging IT and OT networks with trusted paths into both.

Siemens has released a fixed version and strongly recommends immediate updating. If you operate IoT2050 Advanced gateways, treat this as a patch-now event, not a patch-cycle event.

Technical Analysis

Affected Products

The vulnerable condition requires Node-RED to be installed on the Industrial OS image. Note that this is the Advanced variant of the IoT2050 — verify your article number before scoping remediation.

How the Vulnerability Works

Node-RED is a flow-based visual programming tool widely used in industrial IoT for protocol translation, data collection, and edge automation. Its power is also its danger: Node-RED flows can contain Function nodes executing arbitrary JavaScript and exec nodes invoking operating system commands.

The attack chain is straightforward from a defender's modeling perspective:

1. Exposure: The Node-RED HTTP interface (default TCP 1880) is reachable from an attacker-controlled position — flat OT networks, missegmented DMZs, or internet-exposed gateways.
2. Missing authentication: The admin/editor API is not protected by adminAuth, so no credentials are required to interact with the flow runtime.
3. Malicious flow deployment: The attacker issues an unauthenticated POST /flows request (or uses the editor UI) containing an exec or Function node with attacker-controlled commands.
4. Code execution as root: Node-RED on the IoT2050 Industrial OS runs with elevated privileges, so injected commands execute with maximum privileges — full device takeover.
5. Post-exploitation: Persistence via systemd units or cron, lateral movement into OT segments the gateway bridges, credential harvesting, or staging for attacks on downstream PLCs and SCADA infrastructure.

This is CWE-306 in its purest form: a critical function (flow creation/deployment) exposed without any authentication check.

Exploitation Status

As of the advisory publication, CISA reports no confirmed in-the-wild exploitation. However, several factors compress your remediation window:

• CVSS 10.0 with a trivial exploitation path — an HTTP POST is the entire exploit.
• Node-RED exploitation is a well-understood technique in both red team tradecraft and observed ICS intrusions; the barrier to weaponization is effectively zero.
• Shodan/Censys exposure of Node-RED instances is well documented — any internet-reachable IoT2050 is findable in minutes.

Assume scanning for exposed Node-RED interfaces will begin immediately upon advisory publication, if it hasn't already.

Detection & Response

The highest-fidelity detections target the outcome of exploitation: the Node-RED process spawning unexpected child processes (shells, downloaders, reconnaissance tools) and unauthorized access to the Node-RED admin interface on port 1880.

---
title: Node-RED Process Spawning Suspicious Child Processes
description: Detects the Node-RED runtime spawning shells, interpreters, or download tools — consistent with exploitation of unauthenticated flow creation on Siemens SIMATIC IoT2050 or similar industrial gateways.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-237-03
author: Security Arsenal
date: 2026/09/01
status: experimental
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/node-red'
      - '/node'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/python'
      - '/python3'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/busybox'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate Node-RED exec nodes in authorized operational flows — baseline existing flows before enabling alerting
level: high
---
title: Network Connection to Node-RED Admin Interface from Untrusted Source
description: Detects inbound connections to the Node-RED HTTP interface (TCP 1880) on industrial gateways. Should only fire for sources outside an allowlisted engineering/operations management range.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-237-03
author: Security Arsenal
date: 2026/09/01
status: experimental
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: network_connection
  product: linux
detection:
  selection:
    DestinationPort: 1880
    Initiated: 'false'
  filter_engineering_subnet:
    SourceIp|startswith:
      - '10.10.50.'
  condition: selection and not 1 of filter_*
falsepositives:
  - Legitimate engineer access from management workstations — maintain a strict allowlist of authorized source IPs for your environment
level: medium

Tuning note: The 10.10.50. filter above is a placeholder. Replace it with your actual OT management/engineering subnet(s). An untuned version of this rule in a flat network will be noisy; a tuned version in a properly segmented network is a tripwire.

KQL — Microsoft Sentinel / Defender

This query hunts across Syslog/CEF-ingested OT gateway telemetry and Defender process events for Node-RED spawning unexpected children or receiving connections on 1880:

let Lookback = 7d;
let SuspiciousChildren = dynamic(["sh","bash","dash","python","python3","curl","wget","nc","ncat","busybox","chmod","systemctl","crontab"]);
let IoT2050Hosts = (CommonSecurityLog
    | where TimeGenerated > ago(Lookback)
    | where DestinationPort == 1880
    | summarize by DestinationHostName);
union isfuzzy=true
    (Syslog
    | where TimeGenerated > ago(Lookback)
    | where Computer in~ (IoT2050Hosts)
    | where SyslogMessage has_any ("node-red", "flows", "exec")
    | project TimeGenerated, Computer, ProcessName, SyslogMessage, SeverityLevel),
    (CommonSecurityLog
    | where TimeGenerated > ago(Lookback)
    | where DestinationPort == 1880
    | extend IsExternal = iff(ipv4_is_private(SourceIP), "Internal", "EXTERNAL-REVIEW")
    | summarize ConnectionCount = count(), SourceIPs = make_set(SourceIP) by DestinationHostName, DestinationIP, IsExternal, bin(TimeGenerated, 1h)),
    (DeviceProcessEvents
    | where TimeGenerated > ago(Lookback)
    | where InitiatingProcessFileName has_any ("node-red", "node")
    | where FileName in~ (SuspiciousChildren)
    | project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, InitiatingProcessCommandLine, AccountName)
| order by TimeGenerated desc

Prioritize any row where IsExternal flags a non-private source, and any DeviceProcessEvents hit where the child process is curl, wget, or a shell — that pattern is the classic payload-delivery stage of Node-RED flow exploitation.

Velociraptor VQL — Gateway Forensic Hunt

For IR scoping on potentially compromised IoT2050-class Linux gateways, this artifact enumerates Node-RED processes, their children, and listeners on 1880:

-- Hunt: Node-RED exposure and post-exploitation indicators on Linux IoT gateways
SELECT * FROM foreach(row={
  SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
  FROM pslist()
  WHERE Name =~ '(?i)node-red|^node$'
     OR CommandLine =~ '(?i)node-red'
}, query={
  SELECT Pid, Ppid, Name, CommandLine, Username, CreateTime,
         'node_red_process' AS Indicator
  FROM scope()
})
UNION ALL
SELECT Pid, Ppid, Name, CommandLine, Username, CreateTime,
       'suspicious_child' AS Indicator
FROM pslist()
WHERE Ppid IN (
  SELECT Pid FROM pslist() WHERE Name =~ '(?i)node-red|^node$'
)
AND Name =~ '(?i)^(sh|bash|dash|python3?|curl|wget|nc|ncat|busybox)$'
UNION ALL
SELECT 0 AS Pid, 0 AS Ppid,
       Laddr.Address + ':' + Laddr.Port AS Name,
       Name AS CommandLine, '' AS Username, '' AS CreateTime,
       'listener_1880' AS Indicator
FROM netstat()
WHERE Laddr.Port =~ '^1880$' AND Status =~ 'LISTEN'

Also collect /data/node-red/flows.json (or the user-dir equivalent), ~/.node-red/settings.js (check whether adminAuth is configured), and systemd journal entries around any unexpected flow deployment timestamps.

Bash — Verify Version, Audit Node-RED, and Contain Exposure

Run on IoT2050 Advanced gateways (or via your device management tooling across the fleet):

#!/bin/bash
# IoT2050 Advanced - ICSA-26-237-03 verification and containment checks
set -euo pipefail

echo "=== [1] Industrial OS Version Check ==="
# Affected: Industrial OS < 4.3.4.1
if [ -f /etc/os-release ]; then
  grep -iE 'VERSION|PRETTY' /etc/os-release
fi
cat /etc/industrial-os/version 2>/dev/null || true

echo "=== [2] Node-RED Presence and Exposure ==="
# Is Node-RED installed and running?
systemctl is-active nodered 2>/dev/null || systemctl is-active node-red 2>/dev/null || echo "node-red service not active"
# Is port 1880 listening and on which interface?
ss -tlnp | grep -E ':1880' && echo "!! Node-RED HTTP interface is LISTENING - review exposure !!" || echo "No listener on 1880"

echo "=== [3] Authentication Configuration Audit ==="
SETTINGS=$(find / -name 'settings.js' -path '*node-red*' 2>/dev/null | head -1)
if [ -n "$SETTINGS" ]; then
  echo "Found settings: $SETTINGS"
  if grep -qE '^\s*adminAuth' "$SETTINGS" && ! grep -qE '^\s*//\s*adminAuth' "$SETTINGS"; then
    echo "OK: adminAuth appears configured"
  else
    echo "!! VULNERABLE PATTERN: adminAuth not enabled in $SETTINGS !!"
  fi
else
  echo "settings.js not found (Node-RED may not be installed)"
fi

echo "=== [4] Firewall Containment (interim workaround) ==="
# Block external access to 1880 except from your management subnet - EDIT THE SUBNET FIRST
MGMT_SUBNET="10.10.50.0/24"
iptables -C INPUT -p tcp --dport 1880 -s "$MGMT_SUBNET" -j ACCEPT 2>/dev/null || \
  iptables -I INPUT -p tcp --dport 1880 -s "$MGMT_SUBNET" -j ACCEPT
iptables -C INPUT -p tcp --dport 1880 -j DROP 2>/dev/null || \
  iptables -A INPUT -p tcp --dport 1880 -j DROP
echo "iptables rules applied for tcp/1880 (persist via your OS mechanism)"

echo "=== [5] Suspicious Child Process Audit (post-exploitation triage) ==="
NODERED_PID=$(pgrep -f 'node-red' | head -1 || true)
if [ -n "$NODERED_PID" ]; then
  ps --ppid "$NODERED_PID" -o pid,ppid,user,cmd 2>/dev/null || true
fi

echo "=== [6] Recent Flow Modifications ==="
find / -name 'flows*.json' -path '*node-red*' -mtime -14 -exec ls -la {} \; 2>/dev/null

echo "Done. If any '!!' lines appear above, isolate the device and begin IR triage."

Remediation

Primary Action — Update Immediately

1. Upgrade SIMATIC IoT2050 Advanced to Industrial OS version 4.3.4.1 or later. Siemens has released the fix and explicitly recommends updating to the latest version. Obtain the update through Siemens Industry Online Support and follow the advisory linked from CISA ICSA-26-237-03: https://www.cisa.gov/news-events/ics-advisories/icsa-26-237-03
2. Inventory first. Enumerate every IoT2050 in your estate by article number — only 6ES7647-0BA00-1YA2 (Advanced) with Node-RED installed is affected, but unknown or shadow deployments are common at OT edges.

If You Cannot Patch Immediately

3. Restrict network access to TCP 1880. Only allowlisted engineering workstations should reach the Node-RED interface — enforce at the firewall/ACL layer, not just on the device.
4. Enable Node-RED adminAuth in settings.js with strong credentials as a compensating control (this is a hardening baseline for Node-RED regardless of this advisory).
5. Disable and uninstall Node-RED if it is not operationally required (systemctl disable --now nodered and remove the package).
6. Remove internet exposure. No industrial gateway's management interface should ever be internet-reachable. Validate with external scanning (Shodan/Censys checks on your own ASN ranges).

IR and Hunting Actions

7. Hunt before you patch. Pull flows.json from each gateway and diff against known-good baselines. Unexpected exec/Function nodes, recent modification timestamps, or unfamiliar node IDs indicate possible pre-patch compromise.
8. Review network logs for any connection to port 1880 from outside your management VLAN — especially anything non-private sourced.
9. If compromise is suspected: isolate the gateway, preserve the SD card/storage image, collect journald logs and Node-RED user directory, and reimage from known-good Industrial OS 4.3.4.1+ rather than trusting an in-place upgrade.

Strategic (Purdue Model) Hardening

10. Segment OT edge devices behind an industrial DMZ with deny-by-default rules between Level 2/3.5 boundaries. An IoT gateway should never be directly routable from the business LAN.
11. Baseline and monitor legitimate Node-RED flows so the high-fidelity child-process detections above fire on true anomalies only.

CISA's standing guidance for ICS applies: minimize network exposure for all control system devices, locate control networks behind firewalls isolated from business networks, and use secure remote access methods (updated VPNs) where remote access is unavoidable.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub