Ahead of the official Patch Tuesday cycle, VDE CERT coordinated a wave of industrial control system advisories covering Siemens, Phoenix Contact, Johnson Controls, and Hitachi Energy products. The headline items: Siemens flagged multiple high-severity vulnerabilities across its industrial portfolio, and the so-called Node2Shell exposure — a condition in which Node-RED deployments embedded in industrial and building automation environments allow unauthenticated or low-privileged attackers to escalate from flow-level access to full operating system command execution — is putting engineering workstations and HMI-adjacent systems squarely in the blast radius.
If you operate Siemens automation equipment, Phoenix Contact controllers, Johnson Controls building management systems, or Hitachi Energy grid products, this is not a routine patch cycle. These are the systems adversaries — from ransomware affiliates to state-sponsored actors — have consistently targeted as pivot points between IT and OT. Treat this advisory wave as a priority-one event for your vulnerability management and SOC teams.
What's at Stake
The pre-Patch Tuesday release cadence from VDE CERT (the German certification body's CERT, which coordinates much of Europe's ICS disclosure) signals that vendors wanted defenders armed with mitigation guidance before exploit development catches up. That head start is measured in days, not weeks.
The Node2Shell exposure deserves particular attention because of how modern OT environments actually look in 2026. Node-RED — the flow-based programming tool — is deeply embedded across industrial IoT gateways, building automation controllers, edge data collectors, and protocol translation layers. A typical Node2Shell scenario works like this:
- Exposed editor interface: The Node-RED admin UI (default TCP/1880) is reachable without authentication, or with default/weak credentials, from the plant network — or worse, from the internet via misconfigured remote access.
- Flow manipulation: An attacker with editor access can inject or modify flows containing
execnodes or Function nodes that invokechild_process. - Shell execution: Because Node-RED typically runs under a service account with meaningful local privileges — sometimes SYSTEM on Windows-based HMIs or root on Linux gateways — the attacker lands an interactive shell on a device sitting inside the OT perimeter.
- Lateral movement: From that foothold, the attacker pivots toward engineering workstations, historians, or OPC servers.
This is not a theoretical chain. Node-RED exposure is one of the most consistently observed misconfigurations we encounter during OT assessments, and internet-scanning data has repeatedly shown thousands of reachable Node-RED instances, many without authentication.
Technical Analysis
Affected Vendor Landscape
The advisory bundle published via VDE CERT and vendor channels covers:
- Siemens: Multiple high-severity vulnerabilities across its industrial product lines. Siemens' standard practice is simultaneous publication of SSA-prefixed advisories; check the Siemens ProductCERT portal for the full list applicable to your installed base. High-severity in Siemens parlance typically means CVSS 7.0+ — often remotely exploitable conditions in web interfaces, protocol handlers, or management services.
- Phoenix Contact: Advisories affecting industrial controllers, remote I/O, and management software. Phoenix Contact devices frequently sit at network segment boundaries, making flaws in their management planes especially dangerous for segmentation bypass.
- Johnson Controls: Building automation and management products. BMS environments are chronically under-patched and frequently bridge corporate IT and physical plant networks — a favorite initial access vector.
- Hitachi Energy: Grid and power automation products. Energy-sector operators should cross-reference against their NERC CIP obligations where applicable.
The Node2Shell Condition
Node2Shell is best understood as an exposure class rather than a single CVE. The contributing conditions:
- Node-RED editor reachable without
adminAuthconfigured - Default or vendor-shipped credentials unchanged
- Node-RED service running with excessive OS privileges (SYSTEM/root)
- No network segmentation between the Node-RED host and general plant or corporate networks
- Unrestricted outbound connectivity from the Node-RED host, enabling reverse shells and C2
Exploitation requires network reachability to the editor. If the editor is unauthenticated, no other precondition exists — the attacker has code execution as fast as they can deploy a flow. If weak authentication is in place, credential guessing or pass-the-default-credential attacks close the gap.
Exploitation Status
As of publication, the Node2Shell exposure class is actively documented with public proof-of-concept techniques, and internet-exposed Node-RED instances are routinely enumerated by scanners and botnets. For the specific Siemens, Phoenix Contact, Johnson Controls, and Hitachi Energy advisories, consult the vendor bulletins and monitor CISA's ICS advisories page and the KEV catalog — high-severity ICS flaws have been added to KEV with increasing frequency over the past two years, and remediation deadlines follow.
Detection & Response
The detections below target the Node2Shell attack chain — the most immediately actionable, behavior-based detection opportunity from this advisory wave. Patch-verification logic for the vendor advisories is covered in the remediation script section.
Sigma Rules
---
title: Node-RED Process Spawning Shell or Command Interpreter
id: 4f2a8c61-3b7d-4e59-a1c2-9d6e5f8a3b41
status: experimental
description: Detects Node.js processes (Node-RED runtime) spawning command interpreters or shells, consistent with Node2Shell exec-node abuse on Windows HMIs and gateways.
references:
- https://attack.mitre.org/techniques/T1059/
- https://attack.mitre.org/techniques/T0859/
author: Security Arsenal
date: 2026/02/10
tags:
- attack.execution
- attack.t1059
- attack.ics.t0859
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith:
- '\node.exe'
- '\node-red.exe'
- '\nodejs.exe'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\mshta.exe'
- '\rundll32.exe'
- '\certutil.exe'
- '\bitsadmin.exe'
- '\curl.exe'
- '\wget.exe'
condition: selection_parent and selection_child
falsepositives:
- Legitimate Node-RED flows using exec nodes for maintenance scripts — inventory authorized flows before tuning
level: high
---
title: Node-RED Service Spawning Shell on Linux OT Gateway
id: 8c1d4e72-5a3f-4b68-9d21-7e2f6a4c8b53
status: experimental
description: Detects shells or download utilities spawned by Node.js/Node-RED runtimes on Linux-based industrial gateways, indicating Node2Shell exec-node or Function-node child_process abuse.
references:
- https://attack.mitre.org/techniques/T1059.004/
- https://attack.mitre.org/techniques/T0859/
author: Security Arsenal
date: 2026/02/10
tags:
- attack.execution
- attack.t1059.004
- attack.ics.t0859
logsource:
category: process_creation
product: linux
detection:
selection_parent:
ParentImage|endswith:
- '/node'
- '/node-red'
selection_child:
Image|endswith:
- '/sh'
- '/bash'
- '/dash'
- '/zsh'
- '/curl'
- '/wget'
- '/nc'
- '/ncat'
- '/python'
- '/python3'
- '/perl'
condition: selection_parent and selection_child
falsepositives:
- Authorized automation flows — baseline expected exec-node behavior per gateway role
level: high
---
title: Inbound Network Connection to Node-RED Editor Port
id: 2b7e9a14-6d4c-4f81-8e37-5c9a3d1f7e62
status: experimental
description: Detects inbound connections to TCP/1880 (Node-RED default editor port) from non-baseline sources, identifying potential unauthorized access to the Node2Shell attack surface.
references:
- https://attack.mitre.org/techniques/T1190/
- https://attack.mitre.org/techniques/T0883/
author: Security Arsenal
date: 2026/02/10
tags:
- attack.initial_access
- attack.t1190
- attack.ics.t0883
logsource:
category: network_connection
product: windows
detection:
selection:
DestinationPort: 1880
Initiated: 'false'
filter_baseline:
SourceIp:
- '10.0.0.0/8'
- '192.168.10.0/24'
condition: selection and not 1 of filter_baseline*
falsepositives:
- Authorized engineering access from maintenance subnets — tune SourceIp filters to your approved jump-host ranges
level: medium
KQL — Microsoft Sentinel / Defender
The query below hunts the Node2Shell process chain across both Windows (Defender) and Syslog-ingested Linux gateways in Sentinel. The second query surfaces inbound connections to the Node-RED editor port from network device logs.
// Hunt: Node-RED runtime spawning shells, script interpreters, or LOLBins
let suspiciousChildren = dynamic(["cmd.exe","powershell.exe","pwsh.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe","certutil.exe","bitsadmin.exe","curl.exe","wget.exe","sh","bash","nc","ncat","python","python3","perl"]);
union isfuzzy=true
(DeviceProcessEvents
| where InitiatingProcessFileName in~ ("node.exe","node-red.exe","nodejs.exe","node")
| where FileName in~ (suspiciousChildren)
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine, AccountName, ReportId),
(Syslog
| where Facility == "user" or Facility == "daemon"
| where SyslogMessage has_all ("node", "child_process") or SyslogMessage has ("exec node")
| project TimeGenerated, Computer, ProcessName, SyslogMessage, SeverityLevel)
| sort by TimeGenerated desc;
// Hunt: Inbound connections to Node-RED editor (TCP/1880) from non-baseline sources
CommonSecurityLog
| where DestinationPort == 1880
| where Direction == "0" or Direction == "inbound"
| summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
by SourceIP, DestinationIP, DeviceVendor, DeviceProduct
| order by ConnectionCount desc;
Velociraptor VQL
Deploy this artifact across suspected engineering workstations and HMI hosts to identify Node-RED runtimes with suspicious child processes and to enumerate listening instances of TCP/1880.
-- Hunt: Node-RED runtimes with shell children and exposed editor listeners
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)node'
// Correlate with listening sockets on the Node-RED default editor port
SELECT Pid, Name, Family, Type, LocalAddress, LocalPort, RemoteAddress, RemotePort, Status
FROM netstat()
WHERE LocalPort = 1880 AND Status =~ 'LISTEN'
Remediation & Verification Script
Run this PowerShell audit across Windows-based HMIs and engineering workstations to locate Node-RED installations, identify exposed editor listeners, and flag missing authentication configuration. Adapt the authorized-source list to your environment.
# ICS Node2Shell Exposure Audit — Windows HMI / Engineering Workstations
# Run elevated. Produces a CSV for fleet-wide review.
$results = @()
# 1. Detect Node.js / Node-RED processes and their privilege context
$nodeProcs = Get-CimInstance Win32_Process -Filter "Name LIKE '%node%'" -ErrorAction SilentlyContinue
foreach ($p in $nodeProcs) {
$owner = (Invoke-CimMethod -InputObject $p -MethodName GetOwner -ErrorAction SilentlyContinue)
$results += [pscustomobject]@{
Check = 'NodeRuntime'
Detail = "$($p.Name) PID $($p.ProcessId) running as $($owner.User)"
Risk = if ($owner.User -match 'SYSTEM|Administrator') { 'HIGH - privileged runtime' } else { 'Review' }
Hostname = $env:COMPUTERNAME
}
}
# 2. Detect listeners on TCP/1880 (Node-RED editor default)
$listeners = Get-NetTCPConnection -LocalPort 1880 -State Listen -ErrorAction SilentlyContinue
foreach ($l in $listeners) {
$risk = if ($l.LocalAddress -in @('0.0.0.0','::')) { 'CRITICAL - exposed on all interfaces' } else { 'Review - bound to specific interface' }
$results += [pscustomobject]@{
Check = 'EditorListener'
Detail = "TCP/1880 listening on $($l.LocalAddress)"
Risk = $risk
Hostname = $env:COMPUTERNAME
}
}
# 3. Check Node-RED settings for adminAuth configuration
$settingsPaths = @("$env:USERPROFILE\.node-red\settings.js", "C:\node-red\settings.js", "C:\ProgramData\node-red\settings.js")
foreach ($path in $settingsPaths) {
if (Test-Path $path) {
$content = Get-Content $path -Raw
$authConfigured = ($content -match 'adminAuth\s*:') -and ($content -notmatch '//\s*adminAuth')
$results += [pscustomobject]@{
Check = 'AuthConfig'
Detail = "$path — adminAuth configured: $authConfigured"
Risk = if ($authConfigured) { 'Lower - verify credential strength' } else { 'CRITICAL - editor unauthenticated' }
Hostname = $env:COMPUTERNAME
}
}
}
# 4. Export findings
$results | Export-Csv -Path ".\node2shell_audit_$env:COMPUTERNAME.csv" -NoTypeInformation
$results | Format-Table -AutoSize
For Linux gateways, this Bash equivalent audits the same exposure:
#!/bin/bash
# ICS Node2Shell Exposure Audit — Linux OT Gateways
# Run as root. Outputs findings to /var/log/node2shell_audit.log
LOG=/var/log/node2shell_audit.log
echo "=== Node2Shell Audit $(date -Iseconds) on $(hostname) ===" | tee -a "$LOG"
# 1. Identify node processes and privilege context
echo "--- Node runtimes ---" | tee -a "$LOG"
ps -eo user,pid,comm,args | grep -E '[n]ode' | while read -r user pid comm args; do
if [[ "$user" == "root" ]]; then
echo "HIGH: $comm (PID $pid) running as root — $args" | tee -a "$LOG"
else
echo "INFO: $comm (PID $pid) running as $user" | tee -a "$LOG"
fi
done
# 2. Check for listeners on TCP/1880
echo "--- Editor listeners ---" | tee -a "$LOG"
ss -tlnp | grep ':1880' && echo "CRITICAL: Node-RED editor reachable — verify bind address and adminAuth" | tee -a "$LOG"
# 3. Verify adminAuth in settings.js
echo "--- Auth configuration ---" | tee -a "$LOG"
for f in /root/.node-red/settings.js /home/*/.node-red/settings.js /opt/node-red/settings.js; do
[ -f "$f" ] || continue
if grep -qE '^\s*adminAuth' "$f"; then
echo "OK: adminAuth present in $f — verify credential hashing (bcrypt)" | tee -a "$LOG"
else
echo "CRITICAL: adminAuth NOT enabled in $f" | tee -a "$LOG"
fi
done
# 4. Flag exec nodes in deployed flows
echo "--- Exec nodes in flows ---" | tee -a "$LOG"
grep -l '"type": *"exec"' /root/.node-red/flows*.json /home/*/.node-red/flows*.json 2>/dev/null | while read -r flow; do
echo "REVIEW: exec node present in $flow — confirm business justification" | tee -a "$LOG"
done
Remediation — Prioritized Actions
1. Inventory and isolate (today). Identify every Node-RED instance in your environment — including instances vendor-shipped inside gateways, building controllers, and edge collectors that your team never deployed directly. Confirm whether TCP/1880 is reachable beyond the local host. Any editor bound to 0.0.0.0 without adminAuth is an emergency remediation item: restrict binding to localhost, enable adminAuth with bcrypt-hashed credentials, and place a firewall rule in front of the port immediately.
2. Patch per vendor advisories (this cycle). Pull the current bulletins from each vendor's advisory portal:
- Siemens ProductCERT: https://www.siemens.com/global/en/products/services/cert.html
- Phoenix Contact PSIRT: https://www.phoenixcontact.com/en-us/company/psirt
- Johnson Controls product security: https://www.johnsoncontrols.com/cyber-solutions/product-security-advisories
- Hitachi Energy cybersecurity advisories: https://www.hitachienergy.com/products-and-solutions/cybersecurity/alerts-and-notifications
- VDE CERT: https://www.vde.com/en/topics-en/technology/vde-cert
- CISA ICS Advisories: https://www.cisa.gov/news-events/cybersecurity-advisories?f[0]=advisory_type%3A93
Map each advisory to your installed base by model and firmware version. In OT, apply the vendor-listed mitigations (port restrictions, disabling unused services, firewall rules) immediately even where firmware updates require a maintenance window.
3. Harden the Node-RED attack surface. Beyond authentication: run Node-RED under a dedicated low-privilege service account (never SYSTEM/root), disable the editor entirely in production where flows are deployed via CI/CD (httpAdminRoot: false or reverse-proxy gating), audit deployed flows for exec and Function nodes invoking child_process, and enforce egress filtering on gateway hosts so a compromised instance cannot establish outbound C2.
4. Enforce segmentation. Node-RED hosts and the affected Siemens/Phoenix Contact/Johnson Controls/Hitachi Energy devices should sit in dedicated OT zones with brokered access through jump hosts. If your BMS or IoT gateway VLAN can reach the corporate LAN or the internet directly, this advisory wave is your forcing function to fix that.
5. Monitor for KEV additions. ICS flaws from coordinated disclosure events like this one have been landing in CISA's Known Exploited Vulnerabilities catalog with increasing speed. Assign an owner to re-check the KEV and each vendor PSIRT weekly for the next 30 days; KEV listing triggers your federal or internal accelerated remediation SLA (typically 2–3 weeks for BOD 22-01-scoped organizations — apply the same discipline internally even if you're not bound by it).
6. Validate detections. Deploy the Sigma rules above to your SIEM, run the KQL hunts over the trailing 30 days, and execute the audit scripts fleet-wide before your patch window — finding an already-exposed editor is more urgent than the patch itself.
The pattern here is one we see in every major OT incident we respond to: the attacker didn't defeat the PLC — they walked through an unauthenticated management interface that nobody was watching. Close that door this week.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.