西门子 IoT2050 满分洞 CVE-2026-58115 已遭利用 受影响型号增至 4 个

这两天在翻工控那边的公告，本来只想确认一下上个月西门子那个 10.0 分的洞有没有后续，结果翻出来一件比漏洞本身更值得写的事：受影响型号从媒体写的“一款”，变成了四款。

先说漏洞。CVE-2026-58115，西门子的定义是 Node-RED HTTP 接口缺失认证，CWE-306。CVSS 3.1 和 CVSS 4.0 两边都是 10.0，向量分别是 CVSS:3.1/AV:N/AC/PR:N/UI:N/S:C/C:H/I:H/A:H 和 CVSS:4.0/AV:N/AC/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H。两套口径不一样，结论一样，这个洞没有“到底是 9 分还是 10 分”的争议，跟之前那些评分打架的 CVE 不是一回事。

受影响的是 SIMATIC IoT2050，跑 Industrial OS 并且装了 Node-RED 的机器，版本低于 V4.3.4-1。

这里有个我自己核出来的差异。8 月 11 日西门子发 SSA-834709 的时候，标题和受影响清单只点了 Advanced（订货号 6ES7647-0BA00-1YA2）。到 11 月 4 日，公告更到 V1.1，标题改了，受影响清单也扩到四款：Advanced、Basic（6ES7647-0BA00-0YA2）、M.2（6ES7647-0BB00-1YA2）、SM（6ES7647-0CA00-1AA2）。我 11 月 5 日看的几篇英文报道，包括转得比较快的几家，写的还是“只有 Advanced”。也就是说，如果你手上只有一份十月底的转述，很可能会漏掉另外三个型号。在工控上这个代价不小，因为你按名单盘资产，名单本身就是错的。

还有一处写法上的出入：西门子公告原文写的是 V4.3.4-1，带连字符；媒体基本都写成 4.3.4.1。指的是同一个版本，但在固件文件名和订货系统里对着找的时候，这两种写法会让人愣一下。



机理不复杂，难听点说这不算攻破，是压根没锁门。Node-RED 官方文档 Securing Node-RED 那页第一句就是：By default, the Node-RED editor is not secured - anyone who can access its IP address can access the editor and deploy changes. 它假设你只在可信网络里用。要开认证得自己在 settings.js 里配 adminAuth，不配就是裸的。

而 Node-RED 自带 inject 和 exec 两个节点。inject 可以设成部署后一秒自动触发，exec 直接执行 shell 命令。两个节点连起来，部署即执行。攻击者只要往 flows 接口 POST 一个 JSON，就是一次完整的利用，不需要账号，不需要交互。

在野利用是 VulnCheck 报的，时间线我核了一遍：10 月 27 日他们放检测规则（PoC、版本扫描器、PCAP、Suricata 与 Snort 规则、YARA、Shodan 与 Censys 与 GreyNoise 与 FOFA 与 ZoomEye 查询），10 月 30 日蜜罐抓到第一次利用，到 11 月 1 日同一个源 IP 累计 16 次。源 IP 是 4.201.105.116，落在 AS8075，微软的网段，地理位置在巴西。VulnCheck 自己写得很克制：云厂商网段里的 IP 更可能是被入侵或租来的虚机，不代表操作者身份；他们没取回二进制和脚本，所以不知道那是反弹 shell、挖矿还是 DDoS 僵尸。

载荷这块有三层编码，值得单独说，因为它直接决定你的检测规则怎么写。最外层是 Node-RED 的 flow JSON，exec 节点里是一段经过 base64 编码的 shell，解码后才是 wget 或 curl。也就是说，在请求体里 grep wget 或 curl 是搜不到的，这两个词都在编码里面。取回来的文件存成 /dev/shm/.b，tmpfs 内存盘，不落磁盘，文件名前面带点，ls 默认看不见。

后面的变种有两条。一条是两阶段，先取 wget.sh 再执行；另一条从 45.194.90.57 的 38472 端口取 .sys_update，存成 /tmp/.kworker，伪装成内核工作线程。/tmp 下不会有真正的 kworker 路径，这个命名反而成了破绽。

更能说明问题的是第三类：有些请求根本不下载二进制，而是拿 HTTP in 节点开一个 /cmd 或者随机名字的端点，中间过一个 function 节点，接到开了 addpay 的 exec 节点上，之后攻击者用查询参数递命令。这种后门存在 flow 配置里，机器重启、内存里的东西全没了，它还在。

所以查这一波，只查文件是不够的。按我理解的优先级：

一是这个 Node-RED 接口能不能从外面摸到，这是前提，能摸到才有后面所有事。
二是 flows 里有没有 inject 直连 exec 的结构，或者 HTTP in 直连 exec 的端点，尤其是路径很随便的那种。
三是 /dev/shm/.b、/tmp/.kworker 这类文件，以及对外连 85.215.73.250 的 8080 端口和 45.194.90.57 的 38472 端口的连接。
四是有没有从陌生地址往 flows 接口 POST，VulnCheck 抓到的那次 UA 是 curl/8.5.0。

修复就是升到 V4.3.4-1 或更高。升不了的，西门子给的两条缓解是卸载 Node-RED，或者按 Node-RED 官方那页指南加固。加固具体是三件事：开 HTTPS；给编辑器和管理 API 配 adminAuth（凭据或 OAuth、OpenID）；给 HTTP 节点和 Dashboard 配 httpNodeAuth 基本认证。

有一点提醒，这是我自己的推断，不是西门子或 VulnCheck 的原话：打补丁补的是“没认证”这件事，它不一定去删你机器上已经被部署进去的 flow。所以升完版本，该看 flows 还得看一遍。我看到有分析也持同样看法，但同样没有厂商确认，当推断看。

最后说个没核实的。转述里有提到 CISA 在 8 月 25 日发过对应的 ICS 公告，还列了化工、关键制造、能源、运输四个行业。我去 CISA 的 ICS 公告索引页翻了一下，第一页是 10 月 29 日那批，里面没有这条，也没找到公告编号，所以本文不引用这个说法。VulnCheck 明确写了，他们发文时这个 CVE 不在 CISA 的 KEV 目录里。如果你的补丁节奏是跟着 KEV 截止日走的，这个洞目前还没有那条线。

来源：
西门子 ProductCERT SSA-834709（V1.0 2026-08-11，V1.1 2026-11-04）
https://cert-portal.siemens.com/productcert/html/ssa-834709.html
VulnCheck，Exploitation Targeting Node-RED, a Tool Embedded in ICS Products（2026-10-30 分析，11-01 补充）
https://www.vulncheck.com/blog/exploitation-targeting-node-red
Node-RED 官方文档 Securing Node-RED
https://nodered.org/docs/user-guide/runtime/securing-node-red
Protect.Computer，2026-11-03（给出 SSA-834709 编号与订货号，与西门子原文一致）
https://protect.computer/news/2026-11-03-siemens-iot2050-node-red-cve-2026-58115-exploited
The Hacker News 相关报道（转述，用于交叉核对在野时间与载荷路径）
FreeBuf 中文报道（核对中文译名与时间）
https://www.freebuf.com/news/510377.html
CISA ICS 公告索引（2026-11-05 查看，未见对应条目，未采用）

交叉验证说明：CVE 编号、CVSS 双版本 10.0、CWE-306、受影响型号与订货号、修复版本 V4.3.4-1，以西门子公告原文为准，与 VulnCheck、Protect.Computer 三方一致。在野时间线（10-27 检测规则、10-30 首次观测、累计 16 次）与载荷路径、IOC 只出自 VulnCheck 一家，属单一来源，未找到第二方独立确认，如实标注。受影响型号数量的差异来自西门子公告 V1.0 与 V1.1 的版本变更，不是来源冲突。

HKTULU
2026-11-05