跳过导航
返回列表
2026/11/4

2026年11月 Node-RED・Android 安全信息汇总:影响范围与各环境的处置步骤

Node-RED・Android の2026年11月セキュリティ情報まとめ:影響範囲と環境別の対処手順

10月30日起,出现了针对未启用认证的 Node-RED 管理界面的攻击(VulnCheck 将其归为 Siemens 产品的 CVE-2026-58115,Siemens 评分 CVSS 10.0);Android 11月的月度公告修复了216个问题(其中 Critical 23个,据我们统计)。本文整理如何确认是否受影响、Node-RED 的认证设置与升级步骤、Android 补丁级别的确认方法,以及升级后要确认的事项。

分享

要点

  • Node-RED:默认设置下,编辑器和管理 API 没有认证。10月30日起,已观测到用一次 HTTP 请求向未启用认证的 Node-RED 写入恶意流程的攻击(VulnCheck)
  • CVE-2026-58115:Siemens 分配的 CVSS 10.0 编号,范围是安装了 Node-RED 的 SIMATIC IoT2050 Advanced,并不是 Node-RED 本身的漏洞
  • Node-RED 的处置:用 adminAuth 启用认证,不要把1880端口暴露在外。即使升级到最新的5.0.9、4.1.17,认证也不会自动启用
  • Android:11月2日的公告修复了216个问题(其中 Critical 23个,据我们统计)。最严重的是 Framework 的远程代码执行(CVE-2026-58868)
  • 截至11月4日,两者都未被列入 CISA 的 KEV(已确认被利用的漏洞目录)。Node-RED 已观测到攻击,请优先处理对外开放的实例

关于本文

本文根据截至2026年11月4日(日本时间)的 Siemens、美国 CISA、CVE 记录、Node-RED 官方文档、Google 的 Android 安全公告以及 VulnCheck 的报告整理而成。情况会变化,动手前请通过文末的官方链接确认最新信息。

严重程度的数值因发布方而异。正文中会注明是哪家机构的评分。

第一步:先确认自己是否受影响

Node-RED

  • 是否在运行:除服务器、IoT 网关和监控终端外,也要把设备厂商网关产品中内置的 Node-RED 一并找出来。默认端口是 1880
  • 监听地址:默认设置(uiHost)会在所有 IPv4 接口(0.0.0.0)上监听。在 Linux 上可用 ss -ltnp | grep 1880 确认是否在 0.0.0.0:1880 或对外地址上监听
  • 是否启用了认证:在浏览器中打开 http://<主机>:1880/,如果不出现登录界面就直接显示编辑器,说明没有认证。同时确认 settings.js 中的 adminAuth 是否已设置(不是仍被注释掉)
  • 确认管理 API:如果 curl -s -o /dev/null -w '%{http_code}\n' http://<主机>:1880/settings 返回 200,说明无需认证即可使用管理 API。启用认证后会返回 401(如果在 adminAuth 的 default 中给匿名用户授予了权限,即使启用认证也会返回 200。如果改过 httpAdminRoot,请在该路径下确认;设为 httpAdminRoot: false 时会返回 404)
  • 版本:可以从启动日志中的 Node-RED version: vX.Y.Z,或管理 API GET /settings 返回的 version 查看。node-red -v 不是显示版本,而是输出详细日志的参数。4.x 及以后可用 node-red --version 查看
  • Siemens SIMATIC IoT2050 Advanced:产品号 6ES7647-0BA00-1YA2、运行低于 V4.3.4.1 的 Industrial OS 且安装了 Node-RED 的设备,是 CVE-2026-58115 的正式范围

Android

  • 补丁级别:在「设置」的设备信息中查看「Android 安全更新」的日期(位置因机型而异)。如果是2026-11-05或以后,就已覆盖本次公告的全部问题
  • 用电脑确认:adb shell getprop ro.build.version.security_patch 会显示补丁级别的日期
  • 两个补丁级别:2026-11-01 覆盖 Android 本体(Android runtime、Framework、System)和 Google Play 系统更新;2026-11-05 在此基础上还包括内核和芯片厂商(Arm、Imagination、MediaTek、Unisoc、Qualcomm)的组件

Node-RED:CVE-2026-58115 与针对未认证 Node-RED 的攻击

发生了什么

  • CVE-2026-58115(Siemens 评分):CVSS v3.1 10.0(CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H),CVSS v4.0 10.0。弱点类型为 CWE-306(关键功能缺少认证),Siemens 于8月11日发布了公告 SSA-834709
  • 原因(Siemens 的说明):受影响的设备没有在 Node-RED 的 HTTP 接口上强制认证。因此,能执行系统命令的节点无需认证即可使用,远程攻击者可以创建恶意流程,以最高权限执行任意代码
  • 公布经过:美国 CISA 于8月25日以 ICSA-26-237-03 公布了相同内容(涉及化工、关键制造、能源和交通领域)。在日本,JVN 于8月12日在汇总 Siemens 产品8月更新的 JVNVU#98375707 中提到了此事
  • 观测到的攻击(VulnCheck):VulnCheck 在11月2日的文章中表示,其诱饵(canary)于10月30日捕获到针对该 CVE 的攻击。攻击用一次 POST /flows 部署一个流程,下载并运行 Linux bot 程序(僵尸程序)。10月30日至11月1日观测到来自同一来源的16次攻击,并表示没有分析该程序的内容
  • 后续攻击:VulnCheck 表示还确认了使用另一台分发服务器,以及放置重启后仍会保留的 Webshell(把 http in 节点与 exec 节点连接起来)的攻击
  • 与官方评估的差异:CVE 记录中 CISA 的评估(8月12日)仍为「未被利用」,11月3日版的 CISA KEV 也未收录。就我们查到的范围,目前报告已被利用的只有 VulnCheck 的观测,该公司已将其加入自己的 KEV

影响范围:并非 Node-RED 本身的漏洞

  • 正式范围:根据 Siemens、CISA 和 CVE 记录,范围仅限于运行低于 V4.3.4.1 的 Industrial OS、安装了 Node-RED 的 SIMATIC IoT2050 Advanced(6ES7647-0BA00-1YA2)
  • Node-RED 项目:Node-RED 在 GitHub 上的安全信息中没有该 CVE 的公告(截至11月4日,只有2021年2月的2条公告)。没有针对该 CVE 的 Node-RED 修复版本
  • VulnCheck 的看法:VulnCheck 表示,对该 CVE 的描述是根据其诱饵的检测特征和观测到的流量给出的,并据此认为,没有 adminAuth 的 Node-RED 正被自动搜索和攻击。文中没有说攻击对象是 Siemens 的设备
  • 根本条件:Node-RED 官方文档指出,默认设置下编辑器不受保护,只应在可信网络中使用。这次的攻击针对的就是保持默认设置、可从外部访问的 Node-RED

部分报道称这是「Node-RED 的严重漏洞」,但对使用 Node-RED 的用户来说,比升级软件更重要的是启用认证,并让外部无法访问。

风险最高的环境

  • 1880 端口可以从互联网或不可信网络访问
  • 没有设置 adminAuth,任何人都能访问编辑器和管理 API
  • 可以通过 exec 节点等执行操作系统命令,并以 root 等高权限运行 Node-RED
  • 内置在设备厂商的网关等产品中,负责人并不知道有 Node-RED 在运行

处置:Node-RED 的认证设置与升级

  1. 与外部隔离:先用防火墙等把 1880 端口与互联网和不可信网络隔开。需要远程操作时经由 VPN 等。如果在 Docker 中用 -p 1880:1880 公开端口,ufw 等防火墙的设置可能不起作用。只在本机使用时,用 -p 127.0.0.1:1880:1880 重建容器
  2. 启用认证:在 settings.js 中设置 adminAuth。密码哈希可用 node-red admin hash-pw 生成(Node-RED 1.1.0 及以后)。也可使用 OAuth、OpenID。旧的 httpAdminAuth 已不推荐使用
  3. 保护对外的 HTTP 入口:对用 http in 节点公开的页面和 API,可用 httpNodeAuth;对静态文件,可用 httpStaticAuth 加上基本认证
  4. 改用 HTTPS:在 settings.js 的 https 中设置密钥和证书(PEM)
  5. 收窄监听范围:只在本机使用时,把 uiHost 设为 127.0.0.1(在 Docker 容器内这样设置,从宿主机也将无法连接;Docker 请改用第1步的 -p 127.0.0.1:1880:1880)。不需要编辑器的运行环境,可以用 httpAdminRoot: false 关闭全部管理界面和 API
  6. 重启并确认:修改设置后重启 Node-RED,确认会出现登录界面、/settings 返回 401

Node-RED 本身的升级方法因安装方式而异。动手前请备份保存流程和设置的用户目录(默认是 ~/.node-red)。

  • 用 npm 全局安装的情况:先用 node -v 确认 Node.js 版本。5.0.9 在低于 Node.js 22.9 的环境中无法启动,因此请先升级 Node.js,或继续使用 4.x,执行 sudo npm install -g node-red@4.1.17(4.1.17 需要 Node.js 18.5 或以上)。Node.js 为 22.9 或以上时,执行 sudo npm install -g node-red(Windows 上不加 sudo)
  • 在 Raspberry Pi、Debian 系上用脚本安装的情况:重新执行同一个脚本 bash <(curl -sL https://github.com/node-red/linux-installers/releases/latest/download/install-update-nodered-deb)。截至11月4日的脚本(v2.2.1)在 Node.js 为 22.9 或以上时直接沿用;没有 Node.js 时会新装,低于 22.9 时会删除现有 Node.js 并重装(装的是 Node.js 24,ARMv6 的 Pi 1、Pi Zero 等为22),然后把 Node-RED 设置为服务。官方文档仍写「20或以上」「22 LTS」,与实际脚本不同。由于 Node.js 版本会改变,同一台机器上还有其他 Node.js 应用时请注意
  • 官方 Docker 镜像:重新拉取 nodered/node-red 的新标签并重建容器(例如 docker pull nodered/node-red:5.0.9)。如果继续使用 4.x,请使用 nodered/node-red:4.1.17-22 等标签。数据保留在 /data 卷中
  • snap:Node-RED 官方文档一般不推荐 snap。snap 版 Node-RED 在受限环境中运行,exec 节点无法使用外部命令等。用 snap 安装的可执行 sudo snap refresh node-red 更新,但截至11月4日 snap 的 stable 频道仍是 3.1.0,无法升级到 5.0.9、4.1.17。需要新版本时,请考虑改用 npm 或 Docker 重新安装
  • 最新版本:最新为 5.0.9(需要 Node.js 22.9 或以上)和 4.x 维护版 4.1.17,均于10月21日发布。这是常规维护修复,没有安全公告。5.0.9 修复了未设置 adminAuth 时认证通信导致崩溃的问题
  • Siemens SIMATIC IoT2050 Advanced:升级到 V4.3.4.1 或以后。无法立即升级时,Siemens 给出的办法是卸载 Node-RED,或按 Node-RED 用户指南进行加固

无法立即处理时的临时措施(均不完全)

  • 停止不使用的 Node-RED。用脚本安装的情况下,用 sudo systemctl stop nodered 停止,并用 sudo systemctl disable nodered 取消开机自启
  • 在网络设备上把对 1880 端口的访问限制为固定的管理终端
  • 如果以 root 运行 Node-RED,改为用权限较低的专用用户运行

确认是否已被入侵

  • 在编辑器和 flows.json(默认在 ~/.node-red 中;旧的设置为 flows_<主机名>.json,Docker 为 /data/flows.json)里检查有没有不认识的流程,尤其是含有 exec 节点或 http in 节点的流程
  • 检查有没有可疑的对外通信、不认识的进程或 cron 任务
  • 怀疑已被入侵时,断开网络并考虑重装操作系统。同时更换保存在 Node-RED 凭据(flows_cred.json,旧的设置为 flows_<主机名>_cred.json)中的密码和密钥

Android:2026年11月安全公告

主要修复的漏洞

  • 发布:Google 于11月2日发布了2026年11月的 Android 安全公告(1.0版),也有简体中文版(由 AI 翻译)
  • 数量(据我们统计):公告没有写总数,按表格统计为216个,其中 Critical 23个、High 193个。补丁级别 2026-11-01 包含119个(其中 Critical 8个),2026-11-05 再增加97个(其中 Critical 15个)
  • CVE-2026-58868(Google 评为 Critical):Framework 的远程代码执行,不需要额外权限,也不需要用户操作。根据 CVE 记录,原因是 FrameDecoder.cpp 中 onOutputReceived 的堆越界写入,影响 Android 14、15、16、16-qpr2 和 17
  • 其他 Critical:System 的远程代码执行(CVE-2026-58876、CVE-2026-58936),内核 Bluetooth 和 pKVM 的权限提升,MediaTek 调制解调器的8个,以及 Qualcomm 闭源组件的1个等。公告称,内核中最严重的问题可导致无需额外执行权限和用户操作的远程权限提升
  • 媒体报道的问题:CyberInsider 报道称,System 的 Critical(拒绝服务)CVE-2026-58882,就是研究人员10月29日公布的、用特制 WAP Push 消息导致通话中断的问题。公告本身没有这样的说明
  • 利用情况:本次公告没有「有限的定向利用」的注记。CVE-2026-58868 未列入11月3日版的 CISA KEV,CVE 记录中 CISA 的评估(11月2日)也是「未被利用」
  • 源代码发布:Google 表示将在公告发布后48小时内向 AOSP 发布源代码修复,并至少提前1个月通知了设备厂商

各类设备的推送情况

  • Pixel:截至11月4日,2026年11月的 Pixel 更新公告尚未发布。最新的是10月6日发布的10月版(补丁级别 2026-10-05)
  • 其他厂商:推送时间因厂商、机型和运营商而异。请在各厂商的安全信息页面确认
  • 已停止支持的设备:厂商更新期已结束的设备收不到本次的大部分修复(部分修复可能通过 Google Play 系统更新送达)

处置:更新设备并确认

  1. 确认设备的补丁级别
  2. 在「系统更新」中安装更新并重启
  3. 确认补丁级别已变为 2026-11-05 或以后
  4. 收不到更新的旧设备,应考虑从业务用途中替换,尤其是用于管理界面或认证的设备
  • 业务用设备和在数据中心作业时使用的设备,在厂商更新推送后应尽快升级到 2026-11-05 或以后
  • 如果使用了设备管理(MDM),可在补丁级别列表中找出尚未收到更新的设备

升级后一定要确认的事项

  • Node-RED:重启后确认会出现登录界面、/settings 返回 401,以及从外部无法访问 1880
  • Node-RED 的流程:再次确认没有不认识的流程,尤其是含有 exec 节点或 http in 节点的流程
  • Docker:确认没有残留的旧容器,用 docker ps 确认运行的是新镜像标签
  • Android:逐台确认补丁级别是否为 2026-11-05 或以后
  • 嵌入式产品:内置 Node-RED 的设备,请查看设备厂商的信息

官方信息(一手资料)

免责声明

本文是 Two Sheep株式会社根据截至2026年11月4日的公开信息整理而成,不对任何产品的运行或安全性作出保证。动手前请务必查看各厂商的最新信息。文中出现的公司名和产品名均为各公司的商标或注册商标。文中提及的企业仅作为信息来源或对象,不代表与本公司有交易关系。

如果放在数据中心的服务器需要现场处理,例如重启、控制台操作、更换硬件,欢迎咨询我们的远程代维(Remote Hands)服务。

分享