2.1 发生了什么#

TLS 证书链是“根证书 → 中间证书 → 站点证书”。浏览器和操作系统预装根证书，根证书给中间证书签名，中间证书再给站点签名。拿到中间证书私钥的人，就能给任意域名签一张被信任的证书。

eMudhra（品牌名 emSign）在 2025-04-30 的一次密钥仪式里生成了 8 张中间 CA。问题不是算法，而是随机数：

• 正常 P-384 私钥应该是 384 位随机数，暴力枚举要试约 2^384 次。
• 这 8 把私钥的实际值是小整数：4、56、66、115、155、156、230、237。
• 也就是说，从 1 开始最多试 255 次就能还原。

研究员 Scott Helme 不到 1 秒就算出了全部 8 把私钥。8 张里 6 张可用于 TLS（DV/OV/EV），2 张用于代码签名。它们挂在 emSign Root TLS CA - G3 下；这条链还通过 Sectigo 的 AAA Certificate Services 交叉签名，进一步扩大了信任面。

2.2 为什么浏览器修得快，服务器修得慢#

浏览器的吊销机制是集中式的：Chrome 用 CRLSet，Firefox 用 OneCRL，Apple 也有自己的列表。10-17 到 10-20 之间，主流浏览器基本都封了这批中间证书，并且会检查 Certificate Transparency 日志。

但大量非浏览器客户端默认不查吊销，也不查 CT：

• Go 的 crypto/x509 只认编译进去的根池；
• Rust 的 webpki-roots 是静态根列表；
• Python 的 certifi 是打包的 CA bundle；
• Node.js 自带根证书；
• curl、CI 流水线、curl | sh 安装脚本、物联网设备，很多都不会主动更新。

这就是为什么同一张证书，浏览器已经拒绝，服务器端的 curl 还能验证通过。事件披露时，macOS 自带的 curl 访问测试站仍然能过。

2.3 修复矩阵#

检查命令：

1
# Python：确认 certifi 里已经没有受影响的根
2
python -c "import certifi; print(certifi.where())"
3
grep -c "emSign ECC Root CA - G3" "$(python -c 'import certifi; print(certifi.where())')"
4
# 期望输出 0
5

6
# Go：确认工具链版本，然后重新编译所有二进制
7
go version
8
# 期望 go1.27.3+ 或 go1.26.10+
9

10
# Rust：确认依赖树里的 rustls-webpki
11
cargo tree -i rustls-webpki
12
# 期望 0.103.16+ 或 0.104.0-alpha.8+
13

14
# Node.js
15
node -v
16
# 期望 v24.22.1+ / v22.23.4+ / v26.12.1+

注意：更新 lockfile 不等于更新镜像。容器里 vendored 的 certifi、静态链接的 Go 二进制、打包进 Electron 的 Node 根库，都需要重新构建镜像才会生效。

3.1 nginx：5 个漏洞，3 个 9.2#

10-14 的带外更新修了 5 个：

修复版本：1.30.6（stable）/ 1.31.7（mainline），njs 同步升到 1.0.2。临时缓解：避免 alias 与 $request_filename 组合、关闭 AIO/SSI、改用命名捕获、关闭 HTTP/3。

3.2 PHP 8.1：最危险的组合是“EOL + 公网”#

10-20 披露、10-21 发补丁的 PHP2Shell：

• CVE-2026-109618：OOM 路径下的内存破坏，可 RCE。
• CVE-2026-109619：全局状态未清理导致的 use-after-free，可 RCE。
• CVSS 4.0 均为 9.2，无需登录，影响所有 Web SAPI（FPM、mod_php、CGI、FrankenPHP、LiteSpeed）。
• 受影响版本最早到 PHP 5.4（2012 年）；相关代码路径可以追到 2004 年。

官方修复版本：

PHP 8.1 已于 2025-12-31 结束安全支持。官方只给 7.4/8.0/8.1 提供了最小源码回移，需要自己编译；cPanel 的 ea-php8.1.34-5、宝塔的 8.1.35、Heroku 的重建包都属于第三方回移。任何“8.1.35 是官方版本”的说法都是错的。

如果还在跑 8.1，正确动作不是找补丁，而是迁到 8.2+；考虑到 8.2 的安全支持也将在 2026-12 结束，建议直接上 8.4/8.5。升级后记得重启 PHP-FPM / Apache worker，否则旧进程还在跑旧代码。

3.3 Node.js 24.x：Brotli 解码器 RCE#

10-21 的 Node.js 安全更新修了 10 个问题，最严重的是 CVE-2026-111497：Brotli 解码器越界写，可远程执行代码。

根因在 DecodeBlockTypeAndLength()：快速路径丢弃了错误返回值。当 metablock 头声明 num_block_types <= 1，但流仍然走到 block switch 时，解码器会用陈旧的 block_type_rb[3] 去索引一个长度为 1 的 Huffman 树数组，造成越界。上游修复来自 google/brotli 的 0ed4268a4401abcb44720963。

同批还有：

• CVE-2026-105482：dns.resolve 截断含 NUL 的域名；
• CVE-2026-105483：全角数字写法的 IP 可绕过 TLS 主机名校验（仅 26.x/24.x）；
• CVE-2026-106069：主机名宽松解析为 IP 时的证书校验绕过；
• CVE-2026-105481：keep-alive 连接处理“请求尚未发出就到达的响应”；
• CVE-2026-106072：非规范 IPv4 主机名的证书校验问题；
• CVE-2026-106074：crypto.randomUUID()/randomInt() 的熵缓存被写进用户态快照，导致每个进程重复。

修复版本：26.12.1（10 个全修）、24.22.1（8 个）、22.23.4（7 个）。Node.js 20 及更早已停止维护，没有补丁。

3.4 ASP.NET Core / .NET：Patch Tuesday 的 RCE#

10-13 的微软更新里，ASP.NET Core 有两个 8.8 分的 RCE：

• CVE-2026-102870：Microsoft.AspNetCore.Components.WebAssembly.Server 的代码注入。
• CVE-2026-96230：ASP.NET Core 远程代码执行（CWE-79）。

修复版本一致：8.0.32 / 9.0.21 / 10.0.13 / 11.0.0-rc.2。Visual Studio 2022 需 17.14.42，VS 2026 需 18.10.4。

.NET 本身还有两个：

• CVE-2026-70197（8.1）：Windows 上复用 SocketAsyncEventArgs 跨 IPv4/IPv6 datagram socket 时，缓存的地址缓冲区过小，ReceiveFromAsync 越界写，可 RCE。
• CVE-2026-96237（7.5）：CWE-829，从不可信控制域引入功能，可远程执行代码。

这两个也走同一组修复版本。检查：

1
dotnet --list-runtimes
2
# 目标：8.0.32 / 9.0.21 / 10.0.13 / 11.0.0-rc.2 或更高

3.5 Linux：PwnEscape 不是 KVM 的锅#

PwnEscape（CVE-2026-99999，CVSS 9.3）是 guest → host 的虚拟机逃逸，但根因不在 KVM，而在宿主内核的 IPv4 栈：

• guest 可以通过 virtio-net 头或 PACKET_VNET_HDR 控制 csum_start / csum_offset；
• 内核在完成延迟校验和时，没有校验这些偏移是否落在 IPv4 头内；
• 一次写入把 IHL 从 5 改成 15（20 字节 → 60 字节）；
• 分片代码随后把相邻的 32 字节宿主内核内存当作“IP options”拷出去；
• 研究者在 Vercel 的生产 sandbox 上演示了可重复的 32 字节宿主内存泄露、宿主崩溃，以及链式写入到宿主 root（后者只在自有 KVM/Firecracker 环境验证）。

发现者是 Paulos Yibelo（PWNAI / pwn.ai），2026-09-04 私下报告，10-14 修复合入主线，10-15 公开。修复提交是 6785011f8b16（ipv4: validate checksum_start before completing checksum）。

修复版本：

• mainline：7.3-rc7 及以后；
• stable：5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.57、7.2.11。

只有宿主内核需要打补丁，guest 里的内核不用动；也没有可靠的运行期缓解。虚拟机密度高的环境（云厂商、CI runner、多租户 sandbox）优先级最高。

4.1 事件#

10-21，攻击者用窃取的 GitHub CLI OAuth token，从一个仿冒 fork Berri-AI/litellm（注意多了一个连字符）构建并发布了恶意的 litellm==1.107.0：

• PyPI：7 个 wheel，约 11:39–13:23 UTC；
• Docker Hub / GHCR：v1.107.0、latest、main-latest、main-stable，约 11:46–14:20 UTC；
• 官方 GitHub 源码 tag 是干净的，恶意产物来自仿冒 fork；
• 最后一个安全版本是 1.106.2。

4.2 载荷#

恶意包在 site-packages 里放了三个文件：

1
cook.pth
2
cook.py
3
sitecustomize.py

.pth 文件会在 Python 解释器启动时执行，不需要 import litellm；sitecustomize.py 则负责持久化。也就是说，只要这个虚拟环境被激活、解释器跑起来，窃密代码就会执行——virtualenv 并不能隔离这一点。

窃密范围包括：

• SSH/GPG/TLS 私钥；
• AWS/GCP/Azure 凭证与 IMDS/metadata；
• Kubernetes/Docker/Vault/Terraform secret；
• 包管理器 token、浏览器密码/cookie、.env、shell history；
• Claude、Codex、Copilot、Cursor 等 AI 工具凭证；
• LiteLLM 自己的 LiteLLM_CredentialsTable、LiteLLM_ProxyModelTable。

数据用 AES-256-CBC / RSA-4096 加密，通过明文 HTTP 发到仿冒域名 www.litellm[.]dev/healthcheck。sitecustomize.py 还会起一个守护进程，每小时轮询 GitHub 上的 dead-drop 仓库 letters9813/pythonclient-test 执行远程 Python。

4.3 处置#

1
# 1. 先确认版本
2
python -m pip show litellm
3
# 如果是 1.107.0，按下面处理
4

5
# 2. 删除三个文件（只删 litellm 目录不够）
6
SITE=$(python -c "import site; print(site.getsitepackages()[0])")
7
rm -f "$SITE/cook.pth" "$SITE/cook.py" "$SITE/sitecustomize.py"
8

9
# 3. 回退到安全版本
10
python -m pip install --force-reinstall 'litellm==1.106.2'
11

12
# 4. 检查 IoC
13
ls -l /tmp/.pc_once_72129118c59f5636c0bb /tmp/remote_code_loader.lock 2>/dev/null

然后在一台干净主机上轮换所有凭证：SSH key、云 AK/SK、k8s kubeconfig、Vault token、包管理器 token、AI 工具 key、数据库密码。最后审计 CI/CD 日志，确认没有异常外联。

这是 LiteLLM 2026 年的第二次投毒；3 月的 1.82.7/1.82.8 事件据估算影响了约 2500 个组织和 43 万条 CI/CD 流水线。

5.1 Go：CVE-2026-111943#

Go 在 crypto/x509 里加了 denylist，按公钥哈希拒绝 8 张 eMudhra 中间证书。这个过滤不能关闭，自定义根池也会生效；被拒绝的链会返回 x509: no valid chains built。

修复：Go 1.27.3 / 1.26.10。注意 Go 不做运行期吊销检查，所以必须用新工具链重新编译；旧二进制不会因为系统根库更新而获得保护。Go 1.25 及更早已 EOL，没有修复。

5.2 Rust：RUSTSEC-2026-0382#

rustls-webpki 在配置的信任锚允许的情况下，会接受包含被吊销 eMudhra 中间证书的路径。修复：0.103.16 / 0.104.0-alpha.8；webpki-roots / webpki-root-certs 升到 1.0.10；rustup 1.29.2 已同步。Fedora 44 等发行版也已更新。

1
cargo tree -i rustls-webpki
2
cargo update -p rustls-webpki

5.3 Java GraalVM：Oracle 10 月 CPU#

Oracle 2026 年 10 月 Critical Patch Update 覆盖了 GraalVM for JDK 和 GraalVM Enterprise Edition。最紧急的是：

• CVE-2026-91403（JSSE，CVSS 9.1）：远程、未认证、低复杂度，影响机密性和完整性；
• CVE-2026-87294（Security，6.5）；
• CVE-2026-91332 / -91452（Networking，5.3）；
• CVE-2026-91415（2D，7.0）等。

修复走 CPU 对应的 JDK 补丁（GraalVM for JDK 17.0.21 / 21.0.13，EE 21.3.20；以 Oracle 公告为准）。本质上是 JDK/JSSE 的补丁，不是 GraalVM 专属；如果你的服务只用了 native-image 且不碰 JSSE，风险面会小一些，但仍建议跟随 CPU。

5.4 Ruby：net-imap 的 STARTTLS 剥离#

Ruby 这边最值得看的是 net-imap：

• CVE-2026-42246：MITM 可以让 Net::IMAP#starttls 返回“成功”但实际没有启动 TLS（fail-open）。
• CVE-2026-42245：ResponseReader 解析大量字符串字面量时的二次复杂度 DoS。
• CVE-2026-42257：多个 IMAP 命令的 CRLF/命令注入。
• CVE-2026-42258：未校验 Symbol 参数导致的命令注入。
• CVE-2026-80212：resolv 处理恶意 DNS 响应时的内存耗尽。

修复：Ruby 3.4 自带的 net-imap 走 0.5.14；其他分支是 0.3.10 / 0.4.24 / 0.6.4。检查：

1
ruby -v
2
gem list net-imap
3
# 目标：0.5.14（Ruby 3.4）/ 0.4.24 / 0.6.4

这些不是 10-21 当天的新漏洞，但 10 月的发行版更新集中回移了它们。

5.5 Perl：正则引擎的越界读写#

CVE-2026-15534：S_regmatch 的 superlinear cache 存在整数溢出。当 subject 长度与 WHILEM 节点数的乘积超过 signed 32-bit 时，缓存会被分配得过小，随后越界读写，可导致崩溃、内存破坏，Red Hat 将其标记为潜在任意代码执行。影响 Perl 至 5.45.1。

修复：开发版 5.45.2；稳定分支没有单独的 5.42.x/5.44.x 发布，发行版通过回移两个上游提交修复（如 Ubuntu 的 perl 5.40.1-7ubuntu0.2）。另外：

• Text::CSV_XS 的 CVE-2026-110758 / -110753，修复版本 1.65；
• Cpanel::JSON::XS 的 CVE-2026-110674，修复版本 4.80。

遗留 Perl 脚本常见的问题是“装完就不动”，建议至少跑一遍 perl -v 和 cpan -D Text::CSV_XS。

5.6 Vyper：编译器误编译，链上无法打补丁#

Vyper 的问题和运行时漏洞不同：编译器悄悄生成错误的字节码，部署后的合约不会报错，但逻辑已经错了。

• CVE-2026-114115：parse_IfExp 处理嵌套数组三元表达式时，内层数组按更宽类型的布局读取，导致存储错误或 revert。CVSS 4.0 6.3。
• CVE-2026-114117：优化器把 (msg.value | K) 或 (len(msg.data) | K)（K 为非零字面量）在三元分支里编译成常量 1。在默认的 -O gas 或 -O codesize 下，合约会静默使用错误的值，可能记错存款、锁死资金。CVSS 4.0 8.2。
• CVE-2026-114118：create_from_blueprint 用 uint256 减法计算剩余大小，未检查 code_offset 是否小于代码长度，巨大的偏移会回绕成小正数，可能部署出没有运行时代码的合约。CVSS 4.0 6.3。

影响范围：0.3.8–0.5.0b1（114118 从 0.3.4 起）。修复：升级到 0.5.0 正式版之后（0.5.1 或更高，执行时以 GHSA 为准）。已经部署的合约没有字节码级补丁，只能重新编译、迁移、废弃旧地址。临时缓解：用 -O none 编译，或改写表达式，避免直接把 (msg.value | K) 放进三元分支。

5.7 Docker：29 不够，要 29.8.2+#

CVE-2026-92543（CVSS 4.0 7.6）：Docker Engine 在判断 registry 是否属于 insecure registry 时，只要 DNS 返回的任意一个地址落在 127.0.0.0/8 或 ::1/128 就认为整个主机是 insecure；但实际连接时又会重新解析域名。攻击者可以返回“一个 loopback + 一个恶意 IP”的 DNS 响应，让 Docker 跳过 TLS 校验或回退到 HTTP，泄露 X-Registry-Auth，并替换镜像。

修复：29.8.2（containerd ≥ 2.1.5；2.2 已 EOL，建议 2.3.6+）。同批还有：

• CVE-2026-53493：构造 OCI image index 导致 CPU/内存耗尽；
• CVE-2026-92542：Swarm 非特权节点用户向加密 overlay 注入伪造以太帧；
• BuildKit CVE-2026-93315～93326：构建缓存投毒、畸形 LLB 导致 daemon 崩溃等；
• CVE-2026-17106（CopyEscape）：修复于 29.7.2+。

1
docker version
2
containerd --version
3
# 目标：Docker Engine 29.8.2+，containerd 2.1.5+

5.8 Kubernetes：CVE-2026-2270#

CVE-2026-2270（CVSS 5.9）：一个 confused deputy。拥有命名空间内 StatefulSet 和 ControllerRevision 写权限的用户，可以构造 ControllerRevision，让 StatefulSet 控制器在另一个命名空间创建 Pod，并控制 Pod 的完整 metadata/spec。这个 Pod 通常会被立即 GC，除非攻击者能伪造受害命名空间的 StatefulSet OwnerReference（需要知道 UID）。

修复：1.34.12 / 1.35.9 / 1.36.5 / 1.37.1（2026-09-23），只修控制面。Operator 侧也要留意，例如 Strimzi 的 CVE-2026-105312（CVSS 9.9：有 Console CR 创建权限的租户可以把任意镜像塞进绑定了 ClusterRole 的 ServiceAccount）。

5.9 Traefik：mTLS 的 fail-open#

Traefik 的 Ingress NGINX provider 有一组 fail-open 问题，共同模式是：冲突或匹配不上的 TLS option 会回落到 entrypoint 的默认 TLS 配置，而默认配置不请求客户端证书。

建议直接升到 3.7.15+，然后审计所有 Ingress：同一 host 是否有多条规则、是否都带 auth-tls-secret / auth-tls-verify-client: "on"、是否有跨命名空间复用 CA secret。修复前可以先在上游强制校验客户端证书作为止血。

P0：公网 RCE / 凭证泄露#

P1：信任链#

P2：基础设施#

P3：工具链 / 合约#

7.1 c6e50df8 查无此提交#

这是整段话里唯一一处硬伤。我用 GitHub API 查了 torvalds/linux 和 gregkh/linux，两个仓库对 c6e50df8 都返回 422（No commit found for SHA）。PwnEscape 真正的修复合入提交是：

1
6785011f8b16abf40b1e9d8b2e332232b3e68822
2
ipv4: validate checksum_start before completing checksum

所以，如果你在文章或汇报里引用“内核 c6e50df8 之前”，建议改成“PwnEscape 修复提交 6785011f8b16 之前”，或者直接写受影响的内核版本。

7.2 PHP 8.1 没有官方补丁#

8.1 已于 2025-12-31 EOL。官方只给最小源码回移，不发布版本。你看到的 8.1.35、ea-php8.1.34-5 都是厂商或社区重建。把它们当成“官方修复”会误导读者。

7.3 LiteLLM 1.107.0 不是 CVE#

它是 PyPI/Docker 供应链投毒，没有 CVE 编号。处置方式也和打补丁不同：删文件、回退、轮换凭证，缺一不可。

7.4 “Docker 29”不够#

29.x 里只有 29.8.2+ 修了 CVE-2026-92543。只写“Docker 29”会让人以为任意 29.x 都安全。

7.5 “Node.js 24.x”不等于 10 个全修#

24.22.1 只包含适用于 24.x 的 8 个修复；10 个全量修复在 26.12.1。24.x 用户还要确认自己关心的 CVE 是否在覆盖范围内。

7.6 时间线不是同一天#

GraalVM/.NET/ASP.NET 是 10-13；nginx/PwnEscape 是 10-14；eMudhra 浏览器封锁是 10-17～10-20；Go/Rust/Python 是 10-20；PHP/Node/LiteLLM 是 10-21。Ruby/Perl/Vyper/K8s 则是同期或更早。把它们统称为“10 月 21 日漏洞节”是传播上的简化，不是事实。

7.7 eMudhra 不是根证书被攻破#

被攻破的是 8 张中间证书的私钥，不是根证书私钥。但中间证书被根证书信任，所以效果等同于“可伪造任意域名”。这个区别在写事故报告时很重要。