Siemens IoT2050 Node-RED RCE 已被在野利用（CVE-2026-58115）

TL;DR

• SIMATIC IoT2050 Advanced 工业网关在出厂状态下运行 Node-RED，其 HTTP 接口没有认证。能连到该设备的任何人都可以部署执行 shell 命令的流程。Siemens 于 2026 年 8 月 11 日披露该漏洞，CVSS v3.1 与 v4.0 均评 10.0。
• 所有镜像版本低于 V4.3.4.1 的 SIMATIC IoT2050 Advanced（物料号 6ES7647-0BA00-1YA2）都受影响。VulnCheck 补充：任何未配置 adminAuth 的 Node-RED 实例都会接受同样的一次请求部署。
• 该漏洞正在被在野利用：VulnCheck 的蜜饵自 2026 年 10 月 30 日起记录到完整的利用。截至 2026 年 11 月 3 日（已查证数据源），该 CVE 不在 CISA 的 KEV 目录中；VulnCheck 已将其加入自有目录。
• 将每台 IoT2050 更新到 V4.3.4.1 或更高版本。对每个 Node-RED 部署，确认其接口无法从外部访问并启用 adminAuth。加固步骤见“我如何修复？”

我受影响吗？

以下条件全部成立时，您处于暴露状态：

• 设备是安装了 Node-RED、运行 Industrial OS 的 SIMATIC IoT2050 Advanced（6ES7647-0BA00-1YA2），镜像版本低于 V4.3.4.1。Siemens 未列出其他受影响型号。
• 攻击者能够连到 Node-RED 接口。按照 Node-RED 配置文档，它默认在所有 IPv4 接口的 1880 端口监听。
• 该接口未强制认证。Siemens 声明，受影响设备不对 Node-RED HTTP 接口强制认证。

同样的部署攻击对任何未加防护的 Node-RED 实例都成立，不限于西门子设备。Node-RED 部署广泛：node-red 包每周 npm 下载量为 92,432，其官方 Docker 镜像拉取量为 327,470,066（两项均于 2026 年 11 月 3 日查证）。

在每台主机和网关上检查您运行的内容：

# Node-RED on any host: which interface and port it listens on
ss -tlnp | grep ':1880 '

# Node-RED on any host: is editor authentication configured?
grep -n "adminAuth" ~/.node-red/settings.js

adminAuth 行仍以 // 开头保持注释状态，表示编辑器和 Admin API 接受不带凭据的请求。从您的网络之外，尝试打开每个部署的编辑器地址 http://<host>:1880。

无需登录即加载的编辑器就是暴露的。对 IoT2050，请将已部署的 Industrial OS 镜像版本与 V4.3.4.1 比对；更新条目是 Siemens Industry Online Support 门户的 109741799。

我如何修复？

先更新网关，再加固其他所有 Node-RED 部署：

1. 从 Siemens 支持条目 109741799 将每台受影响的 SIMATIC IoT2050 Advanced 更新到 V4.3.4.1 或更高。Siemens 已发布修复镜像并建议更新。
2. 在其他每个 Node-RED 部署上，取消注释并填写配置文件中的 adminAuth 属性，然后重启 Node-RED，为编辑器和 Admin API 启用认证：

// ~/.node-red/settings.js, adapted from the Node-RED securing guide
adminAuth: {
    type: "credentials",
    users: [ {
        username: "admin",
        password: "$2a$08$zZWtXTja0fB1pzD4sHCMyOCMYz2Z6dNbM6tl8sJogENOMcxWV9DN.",
        permissions: "*"
    } ]
}

示例哈希是指南中密码 password 的哈希，请替换为用 node-red admin hash-pw 生成的哈希。

1. 启用 HTTPS 访问，并用基本认证或 OAuth/OpenID 提供方保护 HTTP 节点和 Node-RED 仪表板。Siemens 推荐这三步，或者直接卸载 Node-RED。

没有任何 Node-RED 版本单独修复此问题，因此升级 npm 包没有任何改变。如果某台主机不需要编辑器，可在配置文件中设置 httpAdminRoot: false 完全禁用管理端点。

Siemens 的通用建议是用适当的机制保护设备的网络访问：更新之后仍要让 1880 端口远离不受信任的网络。

根本原因是什么？

Node-RED 的编辑器和 Admin API 提供了一个设计上就执行命令的 HTTP 接口，而受影响设备在该接口上不强制任何认证。

Node-RED 是构建在 Node.js 之上的流程式编程工具：操作者在浏览器编辑器中连接节点，服务器执行流程所描述的动作。两种内置节点类型让该接口直接变得危险。

inject 节点按计划或在启动时一次性发出消息，exec 节点在主机上执行系统命令。

Admin API 通过 HTTP 暴露这种能力。其 POST /flows 端点“设置活动流程配置”，需要 flows.write 权限；文档写明 Authorization: Bearer [token] 头只在“启用认证时”需要。

加固指南直白地说明了默认状态："By default, the Node-RED editor is not secured - anyone who can access its IP address can access the editor and deploy changes."

对 IoT2050，Siemens 公告描述了后果：受影响设备不对 Node-RED HTTP 接口强制认证。这使得未经认证即可访问能执行系统命令的编程节点。CVE 记录将其归类为 CWE-306（关键功能缺少认证）。

Node-RED 如此出厂，是因为正如其文档所述，该工具假设处于可信网络。在网络可达接口的工业网关上，这个假设不成立。

漏洞如何被利用？

公开的概念验证就是利用流量本身，由 VulnCheck 于 2026 年 11 月 2 日解码并发布：

1. 攻击者向 Node-RED 接口发送单个 POST /flows 请求。VulnCheck 于 2026 年 10 月 30 日捕获的请求来自 curl/8.5.0。
2. 请求体携带一个三节点的流程：一个空标签页、一个 inject 节点和一个 exec 节点。inject 节点在一秒后触发一次。以下是第一层编码，引自该分析：

{"flows":[
  {"id":"t","type":"tab"},
  {"id":"inj","type":"inject","z":"t","once":true,"onceDelay":"1","wires":[["e"]]},
  {"id":"e","type":"exec","z":"t","command":"echo <base64> | base64 -d | sh","addpay":false,"wires":[[],[],[]]}
]}

1. 接口返回 HTTP/1.1 200 OK 和新的流程修订哈希，因此该事件被记录为一次成功的利用。
2. 部署一秒后，inject 节点触发。exec 节点随即执行解码后的投放器。据 VulnCheck 的解码，它用 wget 获取二进制文件（失败时改用 curl），保存到 /dev/shm/.b，加上可执行位，然后用 setsid 或 nohup 脱离运行。

该二进制文件从未被取回，因此 VulnCheck 不对其行为作任何断言。同一来源的后续请求变换了载荷：保存并以 /tmp/.s 运行的分段脚本 wget.sh、保存为 /tmp/.kworker 的植入体，以及完全不部署下载器的流程。

攻击流程是怎样的？

一次发往无认证接口的 HTTP 请求，在一秒内部署一个执行攻击者命令的流程。

攻击者能做什么？

已证实的影响是在运行 Node-RED 的主机上执行任意命令。

• Siemens 评估认为，未认证的远程攻击者可以创建恶意流程，并通过该 HTTP 接口“在底层服务器上以最高权限执行任意代码”。
• VulnCheck 观察到两种攻击后形态：保存到内存型 /dev/shm 的 bot，以及持久化的 Webshell。Webshell 流程暴露一个 HTTP 端点（例如 /cmd），经由 function 节点接到启用了 addpay 的 exec 节点。攻击者之后通过查询参数传入命令。
• 条件极少：接口网络可达、无 adminAuth，且无需用户交互。VulnCheck 将该部署描述为一次 HTTP 请求。

尚无受害方得到确认。VulnCheck 的事件来自单一源 IP 4.201.105[.]116，且载荷未被取回或分析，因此无法断言该 bot 的能力。

修复为何有效？

V4.3.4.1 更新是厂商的修复方案，公告确认受影响范围止于其下。Siemens 分发的是闭源工业镜像，因此没有可引用的公开补丁差异。

对其他所有 Node-RED 部署的配置修复，恰好封堵该利用所用的缺口。设置 adminAuth 即在编辑器和 Admin API 上启用基于凭据的认证。

此后 POST /flows 需要 API 文档所述的 Authorization: Bearer [token] 头，未认证的请求会被拒绝。设置 httpAdminRoot: false 则彻底移除这些端点。其余加固步骤，即 HTTPS 以及 HTTP 节点和仪表板的基本认证，关闭流程能打开的其他门。

这些步骤是在收窄问题，而不是改变 Node-RED 本身。exec 节点按设计保留其能力；修复做到的是只有经过认证的操作者才能连线和部署它。

我如何检查是否已被入侵？

VulnCheck 公布了所观测利用的指标。命中是需要调查的线索，不是被入侵的证据，而且失败的尝试可能不留痕迹。

# Look for the dropped files on the Node-RED host
ls -la /dev/shm/.b /tmp/.kworker /tmp/.s 2>/dev/null

# Find every exec node and every HTTP endpoint in the deployed flows
grep -nE '"type": ?"exec"' ~/.node-red/flows*.json
grep -nE '"type": ?"http in"' ~/.node-red/flows*.json

需封禁并在连接日志中检索的网络指标，由 VulnCheck 公布：

• 4.201.105[.]116，位于 Microsoft 的 ASN AS8075 中的利用源。该地址在 2026 年 10 月 30 日至 11 月 1 日之间命中此漏洞 16 次。
• 端口 8080 上的 85.215.73[.]250，bot-linux-amd64 与 wget.sh 的载荷服务器。
• 端口 38472 上的 45.194.90[.]57，保存为 /tmp/.kworker 的 .sys_update 植入体背后的服务器。

检查流程本身，寻找非您创建的节点：带有意外命令的 exec 节点，或接到该节点的 http in 端点（如 /cmd）。在访问日志中，查找来自未知来源并以 HTTP 200 和 rev 哈希应答的 POST /flows。

VulnCheck 的分析页面载有完整指标表及其初始访问制品，可用于排查。

时间线

• 2026-08-11：Siemens 发布公告 SSA-834709，含 CVE-2026-58115、CVSS 评分和修复镜像版本 V4.3.4.1。
• 2026-08-12：CVE 记录中的 CISA ADP 评估将该日期的 SSVC Exploitation 记为“none”。
• 2026-10-27：VulnCheck 发布该 CVE 的检测制品，包括利用 PoC、版本扫描器以及 Suricata、Snort 和 YARA 规则。
• 2026-10-30：VulnCheck 蜜饵捕获第一个完整利用，并将该 CVE 加入其自有 KEV 目录。
• 2026-10-30 至 2026-11-01：同一源 IP 针对该漏洞发送 16 次事件；11 月 1 日出现分段载荷和 Webshell。
• 2026-11-02：VulnCheck 发布利用分析。

常见问题

Node-RED 项目本身受影响吗？

Node-RED 没有对应 CVE，也没有任何 Node-RED 版本修复此问题。该 CVE 属于西门子的产品，其嵌入该工具却未在接口上强制认证。Node-RED 文档声明编辑器默认无防护，仅适用于可信网络。

该漏洞在 CISA 的 KEV 目录中吗？

不在。截至 2026 年 11 月 3 日，该目录的 JSON 数据源中没有 CVE-2026-58115 的条目。VulnCheck 于 2026 年 10 月 30 日将其加入自有 KEV 目录，那天正是其蜜饵捕获首个利用的日子。

有组织被入侵了吗？

没有受害方报告。VulnCheck 记录的是来自单一源 IP 针对其蜜饵网络的利用尝试，且未取回载荷。它不就该 bot 的能力作任何断言。

CISA ADP 评估在 10 月观测之前的 8 月 12 日记录 Exploitation 为“none”。

攻击是否专门针对西门子设备？

蜜饵模拟的是一个 Node-RED 实例，因此观测到的攻击命中它们找到的任何未防护 Node-RED。该源 IP 还命中了互不相关产品上的另外 7 个 CVE，VulnCheck 将其解读为机会性大规模扫描。

VulnCheck 指出 Node-RED 被嵌入商用 ICS 和 OT 产品。它还指出 Emerson 的文档强调该厂商自身对 Node-RED 的使用，但未验证影响。

“最高权限”在这里指什么？

Siemens 声明攻击者在网关的底层服务器上“以最高权限”执行任意代码。在普通 Node-RED 主机上，命令以 Node-RED 进程的用户身份运行。同样的部署机制同样适用。

Node-RED 默认在哪里监听？

按照 Node-RED 配置文档，编辑器和 Admin API 默认在所有 IPv4 接口 0.0.0.0 的 1880 端口监听。在多接口网关上，除非部署覆盖 uiHost，它桥接的每个网络都能连到它。

用 Ostorlab 发现已暴露的工业接口

Ostorlab 的攻击面发现会清点您网段中面向互联网的主机，从而找出每台在 Node-RED 接口上应答的设备。逐一与修复版本比对。用 Ostorlab 开始扫描，即可知道哪些主机需要最先更新。

参考文献

• Siemens 安全公告 SSA-834709，2026 年 8 月 11 日发布，含 CVSS v3.1 与 v4.0 10.0 向量、受影响产品列表、V4.3.4.1 修复方案和缓解措施：https://cert-portal.siemens.com/productcert/html/ssa-834709.html（2026 年 11 月 3 日查证）
• CVE-2026-58115 记录，Siemens CNA，2026 年 8 月 11 日发布，含 CISA ADP 的 SSVC 区块：https://www.cve.org/CVERecord?id=CVE-2026-58115（2026 年 11 月 3 日查证）
• VulnCheck，"Exploitation Targeting Node-RED, a Tool Embedded in ICS Products"，2026 年 11 月 2 日发布，含解码后的利用、指标表和后续载荷：https://www.vulncheck.com/blog/exploitation-targeting-node-red（2026 年 11 月 3 日查证）
• The Hacker News，"Attackers Exploit Critical Siemens IoT2050 Flaw to Plant Remote Command Backdoors"，2026 年 11 月 3 日发布：https://thehackernews.com/2026/11/attackers-exploit-critical-siemens.html（2026 年 11 月 3 日查证）
• Node-RED 加固指南"Securing Node-RED"，含编辑器默认无防护的表述以及 adminAuth、HTTPS 和 HTTP 节点步骤：https://nodered.org/docs/user-guide/runtime/securing-node-red（2026 年 11 月 3 日查证）
• Node-RED Admin HTTP API，POST /flows，“启用认证时”才需要的 Bearer token 头：https://nodered.org/docs/api/admin/methods/post/flows/（2026 年 11 月 3 日查证）
• Node-RED 配置文档，uiHost 与 uiPort 默认值及 httpAdminRoot：https://nodered.org/docs/user-guide/runtime/configuration（2026 年 11 月 3 日查证）
• npm 的 node-red 包页面，每周下载数：https://www.npmjs.com/package/node-red（2026 年 11 月 3 日查证）
• Docker Hub 的 nodered/node-red 页面，镜像拉取数：https://hub.docker.com/r/nodered/node-red（2026 年 11 月 3 日查证）
• CISA KEV 目录 JSON 数据源，检索 CVE-2026-58115 无匹配，截至 2026 年 11 月 3 日：https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json（2026 年 11 月 3 日查证）