Node-RED CVSS 10 漏洞：一筆 HTTP 請求拿到 shell，預設就不需要你登入

你大概聽過 Node-RED——那個在瀏覽器裡拖拖曳曳把裝置、API、服務串起來的工具。Raspberry Pi 上跑 Home Assistant 的、工廠裡接感測器的、homelab 上玩 automations 的，都用得到。

2026 年 8 月 11 日，Siemens 發布了一個 advisory，給 SIMATIC IoT2050 Advanced 上的 Node-RED 編了個 CVE：CVE-2026-58115，CVSS 10.0。問題不複雜：Node-RED 的 HTTP 介面預設沒有登入，而 Node-RED 的 exec node 能跑 shell 指令。(source: Siemens SSA-834709)

10 月 30 日，VulnCheck 的 canary 網絡抓到有人在野外利用它：一筆 POST /flows，部署一個包含 exec node 的 flow，base64 解碼後 pipe 給 /bin/sh，wget 一個 bot 到 /dev/shm/.b，setsid 背景執行。完事。(source: VulnCheck)

白話導讀

想像你辦公室有一台印表機，任何走到前面的人都能按「打印」，而且印表機旁邊放了一整箱公司機密文件。Node-RED 預設就是這樣：編輯器跟管理 API 都對著網路開著，沒有密碼欄位。而「部署一個 flow」在技術上等於「在這台機器上跑程式」——因為 Node-RED 有 exec node、function node，這些東西就是直接呼叫作業系統的。

💡 重點：這不是 Node-RED 的 code bug，是預設設定。Node-RED 官方文件自己寫著「By default, the Node-RED editor is not secured」。(source: Node-RED Security Guide) 沒有哪個版本升級能幫你修——你要自己開 adminAuth。

漏洞到底怎麼回事

CVE-2026-58115 是 Siemens 給自家產品 SIMATIC IoT2050 Advanced（order number 6ES7647-0BA00-1YA2）的 CVE，影響範圍是「所有 V4.3.4.1 以下、跑了 Node-RED 的版本」。CWE-306：缺少關鍵功能的認證。(source: NVD)

但根因不是 Siemens 的——是 Node-RED 本身預設沒開認證。Siemens 的 advisory 描述很直白：「do not enforce authentication on the Node-RED HTTP interface, allowing unauthenticated access to programming nodes that are capable of executing system commands」。CVSS 3.1 和 4.0 都打 10.0，vector 是 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H——遠端、低複雜度、不需權限、不需使用者互動、影響完整性。(source: Siemens CSAF)

CISA 在 8 月 25 日把這件轉發為 ICS advisory ICSA-26-237-03，涵蓋的基礎設施部門：化工、關鍵製造、能源、交通。(source: CISA ICSA-26-237-03)

⚠️ 這不是只有 Siemens 的事：任何跑 Node-RED 且沒開 adminAuth 的機器都中——Raspberry Pi、Docker 容器、工廠 server。VulnCheck 的結論是「Node-RED instances without adminAuth are being found and exploited automatically」。2025 年 7 月 Pilz IndustrialPI 4 也出過同類問題（CVE-2025-41656，同樣 CVSS 10）。(source: Ciphers Security, CERT@VDE VDE-2025-045)

攻擊鏈：一筆請求、一秒延遲

VulnCheck 在 10 月 30 日到 11 月 1 日之間，從一個 IP（4.201.105[.]116，AS8075，Microsoft 的網絡，geo 定位到巴西）抓到 16 個事件。攻擊流程：

1. 偵察 — 掃 port 1880，GET /auth/login 回 {}（空 JSON = 沒開認證）
2. 部署 — 一筆 POST /flows，內容是一個 flow：inject（1 秒後觸發一次）→ exec（跑 shell 指令）
3. 執行 — exec node 解碼 base64 string，pipe 給 /bin/sh
4. 下載 — wget 從 85.215.73[.]250:8080 拉 bot-linux-amd64，存成 /dev/shm/.b
5. 啟動 — chmod +x、setsid（或 nohup fallback）背景執行

同一個 IP 對 8 個不同 CVE 打了 125 次（包含 2019 年的 Apache Solr CVE-2019-17558），VulnCheck 判斷是「opportunistic mass scanning」而非定向攻擊。bot 的功能還沒有人公布——VulnCheck 沒抓到 binary，也沒想到 hash。(source: VulnCheck, SecurityWeek)

11 月 1 日開始出現變體：staged script 到 /tmp/.s、.sys_update 到 /tmp/.kworker（偽裝成 kernel worker thread 的檔名）、以及 webshell——一個 HTTP In 節點掛在 /cmd 路徑上、接到 exec node，攻擊者之後用 URL 參數就能下指令。webshell 比 RAM 裡的 bot 麻煩：它存在你的 flows 裡，重開機不會消失。

查你有沒有中招

以下指令在你的機器上跑：

# 1. 管理 API 有沒有要求登入
curl -s -m 5 http://localhost:1880/auth/login
# {} = 沒開認證（裸露）
# {"type":"credentials","prompts":[...]} = 有要求

# 2. settings.js 有沒有 adminAuth
# （只印沒被註解掉的行；沒有 adminAuth 行 = 編輯器不用登入）
grep -nE '^[[:space:]]*(adminAuth|httpNodeAuth|uiHost|uiPort|httpAdminRoot)[[:space:]]*:' ~/.node-red/settings.js

# 3. 監聽在哪
sudo ss -ltnp | grep ':1880'
# 0.0.0.0:1880 = 所有介面；127.0.0.1:1880 = 本機 only

# 4. 從外面打（手機熱點、或別台機器）
nc -vz -w 5 <你的公網IP> 1880
curl -s -m 5 http://<你的公網IP>:1880/auth/login

# 5. 看有沒有奇怪的 flow（需要 jq）
jq -r '(.flows? // .)[] | select(.type=="exec" or .type=="http in") | [.id, .type, (.command // .url // "")] | @tsv' ~/.node-red/flows*.json

# 6. 查 VulnCheck 公布的 drop path
ls -la /dev/shm/.b /tmp/.s /tmp/.kworker 2>/dev/null
ps -eo pid,ppid,user,lstart,args | grep -E '/dev/shm/.b|/tmp/.kworker' | grep -v grep

修：三步驟

1. 開 adminAuth（所有 Node-RED 都要做）

# 產生 bcrypt hash
node-red admin hash-pw
# 把 hash 放進 settings.js：

// settings.js
adminAuth: {
    type: "credentials",
    users: [{
        username: "admin",
        password: "<bcrypt hash>",
        permissions: "*"
    }]
},
httpNodeAuth: { user: "flowuser", pass: "<bcrypt hash>" },

httpNodeAuth 是給你的 HTTP In node 掛的——flow 對外面發布的 route 也要有認證。(source: Node-RED Security Guide)

2. 綁到本機或管理網絡

// settings.js
uiHost: "127.0.0.1",

Docker 的話：-p 127.0.0.1:1880:1880，不要 -p 1880:1880。工程師要編輯就走 SSH tunnel 或 VPN。

3. Siemens IoT2050 使用者：升級到 V4.3.4.1

Siemens 的修法：升級、卸掉 Node-RED、或依 Node-RED 文件加固。如果短期升不了，先確認 port 1880 不對外。

⚠️ 找到不認識的 flow 就當它被入侵了：/dev/shm 的 payload 重開機就消失，但 webshell flow 不會。先抓證據再重開機。用 node-red --safe 啟動可以只開編輯器不跑 flow，方便清不认识的 exec / HTTP In / function node。(source: Ciphers Security)

跟之前幾篇的關係

你如果讀過這個 blog 的 security 系列，會發現一個重複出現的模式：

日期	主題	共同點
11/1	LMDeploy SSRF (CVE-2026-33626)	推論伺服器無認證 → 從裡面打出去
11/3	Langflow 33 CVE	Agent builder 預設 auto-login → 不用登入就能 RCE
11/4	Node-RED (CVE-2026-58115)	IoT/OT 工具預設無認證 → 一筆請求拿 shell

三個不同領域（推論、agent 組裝、IoT），同一個根因：預設不對外要求憑證，而工具本身有能力跑程式。Self-host 的工具預設都假設「只有你連得到」，但你的路由器 port forward、DMZ、或 NAT traversal 可能讓「只有你」變成「任何人」。

If You're Stuck

• /auth/login 回 {} 但你不確定是不是真的沒開認證 → 也開一下瀏覽器看 http://host:1880/——直接進編輯器沒有登入表就是沒開
• settings.js 改完沒效果 → 確認你改的是 Node-RED 實際讀的那個檔案；啟動 log 會印 Settings file : 路徑
• Docker 裡改 settings.js 不生效 → 確認你有把改過的 settings 掛進容器（volume mount），不是只改了 host 上的檔案
• 開 adminAuth 後連不進編輯器 → 密碼是 bcrypt hash 不是明文；node-red admin hash-pw 產生
• 升級 Siemens 後還是 10.0 的風險 → V4.3.4.1 修的是那個 specific advisory；如果你的 Node-RED 是手動裝的、不是隨 IoT2050 來的，升級 OS 不會幫你開 adminAuth
• 找不到 settings.js 在哪 → Node-RED 啟動 log 第一行會印路徑；預設 ~/.node-red/settings.js
• disableEditor: true 以為關了編輯器就安全 → 那只藏了 UI，管理 API 還活著；要用 httpAdminRoot: false 才能關掉所有 admin 端點

Further Reading

• Inference server SSRF: 12 小時被利用 — 推論伺服器的「無認證代理」模式
• Langflow 33 CVE 同批曝光 — Agent builder 的 auto-login 預設
• Running a homelab by yourself — 基礎架構層面怎麼想 attack surface

Sources

• Siemens ProductCERT SSA-834709
• Siemens CSAF (machine-readable)
• NVD: CVE-2026-58115
• CISA ICSA-26-237-03
• VulnCheck: Exploitation targeting Node-RED
• SecurityWeek: Critical Node-RED Flaw Exploited in Attacks
• The Register: Max-severity bug in widely-used OT programming tool exploited
• Ciphers Security: Node-RED CVE-2026-58115 Exploited: Check and Fix
• Node-RED Security Guide
• CISA KEV catalog（截至 2026.11.03 版本，此 CVE 尚未列入）