TL;DR - 一次 CA 密钥生成缺陷,把 Agent 的运维门槛从”应用版本”推到”运行时版本”

2026 年 10 月 17 日晚,研究人员向 Chrome、Mozilla、Apple、Microsoft 和印度 CA 机构 eMudhra 通报:该机构 8 张中间 CA 证书的私钥随机性严重不足,私钥实际是 1 到 255 之间的整数(公开报道点名过 4、56、66、115、155、156、230、237 等取值),任何人拿公开证书几分钟就能反推出来——Google 的原话是 “anyone can compute them from the public certificates”。这不是入侵,不是 HSM 被偷,是 2025 年 4 月 30 日一次密钥生成仪式的脚本缺陷:24 枚中间 CA 中的 8 枚 P-384 “B/C 系列”弱密钥与正式密钥一并被送进了根证书库。

浏览器四天内全部封锁:Chrome 10-17 18:05 UTC 收到报告、19:45 UTC 部署 CRLSet 封锁 6 张 TLS 中间证书,Firefox 20:06 收到、22:59 推送 OneCRL,Apple 10-19(含 Android Play Services 约 22:00 UTC)、Microsoft 10-20。Go 1.27.3 / 1.26.10 先行(CVE-2026-111943),NSS 3.131.1、Python certifi 2026.10.19、Rust webpki-roots 1.0.10、Debian/Ubuntu、Homebrew 相继移除根证书。真正打挂正常业务的是第二波:Chrome 根证书库 43 预计 10-27 移除 emSign ECC Root CA - G3 整条信任链——受影响者不是攻击者,而是持有完全合法证书的站点。

Node.js 这层原本有缺口。浏览器有 CRL/OneCRL 吊销机制,Node.js 没有等价物:一条走 eMudhra 中间 CA 的伪造链,只要终点能连到受信任根,握手照常通过。10 月 22 日 Node.js 发布 22.23.4 / 24.22.1 / 26.12.1,在核心里编译进”已知坏公钥”黑名单(PR #66871),对 TLS、QUIC、DTLS 全部握手校验拦截,命中即返回 CERT_REVOKED,与 Go、Electron 修复口径完全一致;同批还修了 Brotli 解码器越界写导致的远程代码执行。官方强调两个限制:升级前建立、之后发生会话恢复的连接不会重新校验证书(只升版本不重启等于没修);设置 rejectUnauthorized: false 的代码不受黑名单保护。

OpenClaw 的反应最直接。10 月 22 日 05:53 PT,v2026.10.6 上线(GitHub Releases 与 npm latest 同时指向),第一条 Highlights 就是”强制已修补的 Node 运行时”:要求 Node 24 线 24.22.1+ 或 26 线 26.12.1+,Docker 镜像内置 Node 24.22.1,源码构建锁定 pnpm 12.15.0(此前自动选中的 pnpm 自带受影响的原生 TLS 运行时)。工程上最关键的是失败姿势——openclaw update 在旧 Node 上”拒绝并给出恢复指引”,而不是装出一个带洞的版本把正在跑的实例搞坏(PR #179992)。这是 OpenClaw 第二次设置破坏性运行时下限(第一次是 9 月 3 日的 Node 24.16),9 月官方就已提示”先升 Node 再升 OpenClaw,否则 SQLite TEXT 截断”。

一句话:Agent 落地的风险不只在模型和提示词,也在证书信任链这种平时完全看不见的层面;而 OpenClaw 这次做对的事,是把一次 CA 安全事件翻译成了一条运维人员能照着做的红线。

一、信任根被算出来:一次密钥生成缺陷如何变成八张”万能证书”

时间(2026)事件关键数字
04-30eMudhra 密钥生成仪式24 枚中间 CA,其中 8 枚 P-384 B/C 系列私钥熵不足
10-17 18:05Chrome 收到通报19:45 UTC 部署 CRLSet,封锁 6 张 TLS 中间证书
10-17 20:06Mozilla 收到通报22:59 UTC 推送 OneCRL;NSS 3.131.1 移除 emSign 根
10-19 / 10-20Apple / Microsoft 封锁含 Android Play Services 约 22:00 UTC
10-20Go 1.27.3 / 1.26.10拒绝 8 个密钥,CVE-2026-111943
10-22Node.js 22.23.4 / 24.22.1 / 26.12.1内核公钥黑名单,PR #66871
10-27Chrome 根证书库 43预计移除 emSign ECC Root CA - G3

三点值得注意。第一,这不是”密钥被盗”,而是密钥”熵不足”:Mozilla 工程师 Dennis Jackson 公开演示过用 baby-step giant-step 离散对数算法还原,任何人都能复现。第二,截至目前 CT 日志中没有出现任何一张由这 6 张中间 CA 签发的终端实体证书,eMudhra 21 日称弱密钥来自 4 月那次仪式并已撤销整批证书,但”自证书创建起是否被利用仍不可知”——CT 只覆盖已登记证书。第三,误伤面大于攻击面:Chrome 根证书库 43 移除整条信任链,会连带打挂所有合法证书,Google 的指引是”必须在那之前换成另一条信任层级下的证书”。

二、浏览器的封锁不够:Node.js 这层为什么是缺口

浏览器有现成的吊销机制(CRLSet / OneCRL),Node.js 没有等价物。信任不在协议里,而在每个运行时各自维护的一份根证书文件里——升了操作系统修好了 curl,但上个月编译的 Go 二进制、虚拟环境里的 certifi、跑着旧 Node 的服务进程,都还抱着旧信任链。

Node.js 这次的处理方式比浏览器更精准:不删根,而是在握手校验里检查证书链是否包含被封锁的公钥,命中即报 CERT_REVOKED。这条修复在官方公告里只是依赖更新列表中的一行(“ca-cert(eMudhra Intermediate CA Compromise) on 26.x, 24.x, 22.x”),实际解决的是所有依赖 Node 做 HTTPS 出站校验的服务——AI Agent 网关正是这类:它手里握着 API Key,每天向外发几十次 TLS 请求。

官方明确的两个限制运维含义
升级前建立的会话,恢复时不重新校验证书只升版本不重启 = 没修
rejectUnauthorized: false 绕过的是正常校验流程关闭校验的代码不受黑名单保护
v25(2026-06-01 EOL)、v23、v20 无补丁这几条线不存在”打补丁”选项,只能迁移
v24 于 10-20 进入维护 LTS,v26 于 10-28 成为活跃 LTS迁移要有窗口,不能临时抱佛脚

三、OpenClaw 的翻译:把安全事件写成一条可执行的红线

版本日期与本次事件相关的动作
v2026.10.610-22强制 Node 24.22.1+ / 26.12.1+;Docker 内置 Node 24.22.1;pnpm 锁 12.15.0;旧 Node 上 update 拒绝并给恢复指引
v2026.9.34(extended-stable / LTS 等价线)10-24同步抬高到 Node >=24.22.1 <25 || >=26.12.1
v2026.10.710-24恢复来源追踪、未完成工具结果保留;apply_patch 有序封套预检
v2026.10.810-27secret egress proxy 拒绝不可信 eMudhra 链;test -v 操作数展开需审批;沙箱子进程不得调用宿主 CLI 后端

规模上,v2026.10.6 是纯修复版:约 294 次提交 / 293 个 PR(官方文档另称 233 PR、30 直接提交、149 位贡献者),主 PR 是 joshavant 于 10-21 15:39 PT 提交、21:00 合并的 #179992。生态侧,GitHub 上 openclaw/openclaw 约 392,000 star / 82,000 fork(2026-10-18),722 条安全公告(14 critical、249 high),基金会以 501(c)(3) 托管、MIT 协议,维护 stable / extended-stable / beta / dev 四条发布通道。

值得单独表扬的是那条失败姿势:“旧运行时被拒绝,而不是被装坏”。这条决策把一次安全事件从”半夜告警”变成了”有明确恢复路径的例行升级”。

四、给国内企业私有化部署方的四步清单

  1. 先 node -v,而且要查服务管理器实际加载的那个 Node——它可能和 PATH 上的不是同一个,托管型 Gateway 服务尤其容易对不上。
  2. 排期重启。不做重启,会话恢复窗口里旧信任仍然生效,这是官方唯一强调的硬限制。
  3. 清理 rejectUnauthorized: false 这类”关校验换稳定”的写法,黑名单对它无效。
  4. 顺序是”先升运行时、再升 OpenClaw、再重启 Gateway”,不是反复重试 openclaw update。10.6 之后的 update 会主动拒绝并给指引,重试没有意义。

对铂傲智能自己的交付也有直接含义:面向商会、园区、行业客户的私有化交付包,需要把 Node 运行时版本写进交付检查单——否则客户三个月后自己开一台新机器装 OpenClaw,会直接撞上一条他们完全理解不了的硬门槛。而这次事件本身就是一个极好的售前素材:Agent 落地的风险不只在模型能力和提示词工程,也在证书信任链这种平时完全看不见的层面。

五、还没解决的部分

  • 未登记证书无法观测。CT 只覆盖已登记证书,私有签发且未登记的伪造证书至今无解。
  • 会话恢复的窗口。官方明确升级前建立的会话不重新校验,这要求运维把”重启”当成安全动作而非运维习惯。
  • 根证书库 43 的余波。10-27 之后链条到 emSign 根的合法站点会大面积报错,这类误伤和攻击混在一起,处置需要先分清是哪一类。
  • 自管运行时是最脆的一环。Infisical 自己的复盘写得很直白:升级顺序错了有 SQLite TEXT 截断风险;外置调度器和写死的 crontab 路径只能靠人管。

FAQ(高频问题直答)

Q1:这次证书泄露,我的 OpenClaw 部署受影响了吗? A:取决于你的 Node 版本是否在 24.22.1+ / 26.12.1+(或 22.23.4)且已经重启。没打补丁的 Node 会继续信任被封锁的中间 CA。运行 node -v 再查服务管理器加载的版本。

Q2:为什么浏览器早就堵上了,OpenClaw 还要发一个版本? A:因为浏览器有吊销列表,Node.js 没有。OpenClaw 的运行时是 Node,它的 TLS 出站校验走的是 Node 的信任链,只能靠 Node 自己补黑名单。这是运行时层的问题,应用层无法代劳。

Q3:是不是所有 OpenClaw 用户都必须升? A:要连第三方模型 API、走公网、或持有 API Key 的部署,属于”必须升”;只在本地跑短问答、完全离线的单机场景,风险等级低,但官方 update 依然会拒绝旧运行时,想留在旧版就得停在 10.5 或更早。

Q4:升级顺序错了会怎样? A:9 月那次的官方警告是 SQLite TEXT 截断,数据可能被损坏;这次文档强调的风险是”运行时被跳过导致修复没生效”。正解永远是先升运行时,再升 OpenClaw,最后重启。

Q5:关掉证书校验能不能绕过? A:不能,而且更危险。黑名单是编译在校验流程里的,rejectUnauthorized: false 直接绕过整个流程,等于主动放弃这层保护。

Q6:这对国产化/信创环境有影响吗? A:影响点不在模型或芯片,而在运行时版本管理。信创环境往往自带较老的 Node 版本,私有化交付时必须确认 Node 版本线是否还受支持(22/24/26 才有补丁),否则等于交付了一个无法升级的实例。

Q7:和 10 月的 Brotli 远程代码执行漏洞有关系吗? A:是同一天、同一批发布的两个独立问题,但对企业 Agent 落地的意义不同:Brotli 那个是”解不可信压缩数据”触发 RCE,证书这个是”信任链本身被伪造”。前者管输入,后者管信任,两条都得查。

关键术语(Key Terminology)

  • 中间 CA(Intermediate CA):夹在终端证书和根证书之间签发证书的机构;其私钥泄露等于获得对任意域名的签发权。
  • 证书透明日志(Certificate Transparency, CT):公开记录所有被签发证书的日志,用于事后发现滥用;只覆盖已登记证书,私有未登记的签发无法观测。
  • CRLSet / OneCRL:浏览器用的证书吊销分发机制;Node.js 这类运行时没有等价物,只能靠编译期黑名单。
  • 公钥黑名单(Compiled-in Public Key Blocklist):Node.js 10 月安全版本引入的机制,在握手校验中检查证书链是否含被封锁的公钥,命中返回 CERT_REVOKED。
  • 会话恢复(Session Resumption):TLS 连接复用;升级前建立的会话在恢复时不会重新校验证书,因此升级后必须重启。
  • 运行时下限(Runtime Floor):软件声明的最低运行环境版本;低于此版本时拒绝安装并给出恢复指引,而不是装出一个带洞的版本。
  • Extended-stable(LTS 等价线):OpenClaw 的长期支持分支,只做安全与可靠性回合;2026.10.5、9.34、9.35 均属此线。
  • Secret Egress Proxy(密钥出口代理):OpenClaw v2026.10.8 引入的出站代理,直接拒绝不可信 eMudhra 证书链,把防线从运行时推到应用层。

参考资料

官方文档与公告

安全事件与官方复盘

行业与技术媒体

中文报道