ONCALL://19
INC-17 · 根证书库

根证书库:Go x509、webpki-roots、certifi 的 eMudhra 修复

eMudhra 事件不是 crypto/x509 的路径构建漏洞,而是 CA 错误生成密钥后的信任撤销缺口。Go、webpki-roots 和 certifi 都已发布修复,没有更新的独立证书包仍会信任坏链。

INC-17严重直接命中证书信任P1今天披露 2026-10-19
段子原句“根证书库用 Go crypto/x509 + Rust webpki-roots + Python certifi”
编号
CVE-2026-111943GHSA-6q48-6c7w-9gw2
严重度
certifi 的 GHSA 评为 Critical;CVE-2026-111943 无 CVSS
利用状态
未见利用未见利用:未发现在野利用。风险来自没有更新的独立证书包仍然信任坏链。
对段子公司
段子列出的三个根证书库都需要更新。旧版 pip 会额外加载内置的旧 certifi,所以只更新系统证书不够。
影响范围
CVE-2026-111943 只覆盖 Go crypto/x509 的 Certificate.Verify;RustSec 把它列为 webpki-roots 的别名。受影响用户数和下载量未找到。
修复版本
  • →Go 1.26.10 / 1.27.3
  • →webpki-roots 1.0.10、rustls-webpki 0.103.16
  • →certifi 2026.10.19、pip 26.2.2
同一事件:INC-05、INC-12、INC-17 是同一个事件,分别从 CA 本身、Sectigo 交叉签名和根证书库三个角度调查。 INC-05 印度 CA 泄漏、INC-12 Sectigo DV
处置清单见处置顺序 · P1

结论

2026 年 10 月,8 个 eMudhra 中间 CA 私钥可被恢复。这些证书可伪造网站或代码签名证书。 [1] [2]

该事件不是 crypto/x509 的路径构建漏洞。它是 CA 错误生成密钥后的信任撤销缺口。 [3] [4]

webpki-roots、certifi 和 Go 已发布修复。未更新的独立证书包仍可能信任坏链。 [3] [5] [7]

事件经过

研究者在 2026 年 10 月 17 日披露了 8 把私钥。Google 在同日完成复核并封禁其 SPKI 哈希。 [1]

8 个 P-384 私钥的标量 d 都小于 256。攻击者可枚举 256 个候选值恢复私钥。 [2]

eMudhra 表示密钥在 2025 年 4 月 30 日生成。该公司称密钥生成仪式使用 Utimaco HSM。 [2]

受影响证书有 6 个 TLS 中间 CA。另有 2 个代码签名中间 CA。 [2]

这些中间 CA 可经 emSign ECC Root CA - G3 建链。部分证书还可经 Sectigo 的 AAA Certificate Services 交叉签名建链。 [9]

Mozilla、Chrome 等系统可分发中间 CA 撤销信息。独立根证书包通常必须发布新软件包。 [1] [10]

技术细节

根证书包将信任锚随程序或依赖发布。旧包保留受信任根时可继续构建坏链。

攻击者掌握中间 CA 私钥后,可签发任意域名证书。未执行 CT 或撤销检查的客户端风险最高。 [1] [2]

Google 称 6 个 TLS 中间 CA 在封禁前没有 CT 日志。因此,强制 CT 的 Chrome 客户端不能使用伪证书。 [1]

这不证明非浏览器客户端未被攻击。事件网站明确表示该部分利用情况未知。 [10]

Go 通常读取操作系统信任库。部分狭窄场景不会自动取得系统库更新。 [3] [4]

Go 在 Certificate.Verify 增加中间证书拒绝列表。命中已知坏中间 CA 时,该函数返回验证错误。 [3] [4]

webpki-roots 1.0.10 删除了 emSign ECC Root CA - G3。该版本于 2026 年 10 月 19 日发布。 [5] [6]

webpki-roots 的旧 0.26.10 已在 2025 年删除 AAA 根。因此,旧兼容分支仍须检查实际解析的 1.x 依赖。 [5] [11]

certifi 的安全公告称它删除了 emSign 根证书。公告将 2026.10.18 标为首个补丁版本。 [7]

Python 核心开发者建议使用 certifi 2026.10.19。该版本兼容未受影响的 emSign 根。 [8]

CVE 项目将问题归为 CWE-299。该分类表示证书撤销检查不当。 [4]

此 CVE 不是名称约束或路径选择缺陷。根因是外部 CA 私钥泄露。 [1] [2] [4]

影响范围

组件受影响范围修复版本处置机制
Go crypto/x509早于 1.26.10;1.27.0 至 1.27.21.26.10、1.27.3Verify 拒绝已知坏中间 CA
webpki-roots含受影响 G3 根的旧包;1.x 的 1.0.0 至 1.0.91.0.10删除 emSign ECC Root CA - G3
webpki-roots 0.26.11无独立根库父依赖须为 1.0.10 或更新重导出 1.x 根库
Python certifiGHSA 列为 2019.03.09 或更新2026.10.18;建议 2026.10.19删除 emSign 根

CVE-2026-111943 的受影响代码限于 Go crypto/x509。其范围是 Certificate.Verify。 [3] [4]

RustSec 将同一 CVE 列为 webpki-roots 别名。其公告将 1.0.10 或更新版本列为已修复。 [5]

Certifi 的 GHSA 标为 Critical。该 GHSA 发布时仍写作“无已知 CVE”。 [7]

CVE 记录没有提供 CVSS 向量或分数。NVD 在 2026 年 10 月 22 日仍未收录该条目。 [4] [12]

事件涉及 8 把可恢复私钥。交叉签名后,Windows 缓解脚本会封禁 16 张证书。 [2] [10]

受影响的 8 张原始中间 CA 中,6 张用于 TLS。其余 2 张用于代码签名。 [2]

eMudhra 称这些中间 CA 未签发最终实体证书。其中只有 1 个 TLS 中间 CA 曾投入生产。 [2]

Google 仍警告根删除会影响其他合法订户。它要求受 G3 根影响的网站立即换证。 [1]

截至调研时,未找到受影响用户数。未找到下载量、资金损失或已确认受害者数字。

时间线

  1. 2025-04-30 UTC
    eMudhra 生成受影响密钥。[2]
  2. 2026-10-17 18:05 UTC
    Chrome 收到私钥泄露报告。[1]
  3. 2026-10-17 19:45 UTC
    Chrome 下发 CRLSet 的 SPKI 封禁。[1]
  4. 2026-10-18 09:24 至 09:38 UTC
    eMudhra 撤销 8 个原始中间 CA。[2]
  5. 2026-10-19 10:35 UTC
    Sectigo 撤销已列出的交叉签名证书。[9]
  6. 2026-10-19 20:12 UTC
    webpki-roots 1.0.10 发布至 crates.io。[6]
  7. 2026-10-20 02:11 UTC
    certifi 2026.10.19 发布标签建立。[13]
  8. 2026-10-20,时区未公布
    Certifi GHSA 发布。[7]
  9. 2026-10-20,时区未公布
    Go 发布 1.26.10 与 1.27.3。[14]
  10. 2026-10-21 00:52 UTC
    Go CNA 发布 CVE-2026-111943。[4]
  11. 2026-10-27 PDT计划
    Chrome 计划向稳定根库发布 G3 根删除。 此项尚未验证已完成。[1]

修复与缓解

  1. 将 Go 升级到 go1.26.10 或 go1.27.3。重新构建所有静态 Go 二进制文件。 [3] [14]

  2. 将 webpki-roots 锁定到 1.0.10 或更新版本。检查 Cargo.lock 的实际解析版本。 [5] [6]

  3. 将 certifi 升级到 2026.10.19。重建 Python 虚拟环境和容器镜像。 [8]

  4. 将 pip 升级到 26.2.2 或更新版本。旧 pip 会额外加载内置的旧 certifi。 [8]

  5. 更新 Linux 的 ca-certificates 软件包。仅更新操作系统不能修复旧 pip。 [8] [10]

  6. 在更新前,使用官方哈希校验获取工具包。不要在旧信任链上直接信任下载结果。 [8]

  7. 排查所有自定义 CA 包和离线镜像。这些副本不会随操作系统自动更新。 [3] [10]

  8. 不要关闭 TLS 验证来绕过换根失败。应改用未受影响层级签发的新证书。 [1]

对段子中公司的影响

该公司的 Go 网络沙箱可能调用 crypto/x509。旧 Go 版本可接受含坏中间 CA 的验证链。 [3] [4]

该公司服务器在 Linux 上运行并不能保证安全。Go 的狭窄场景不会自动使用系统根库更新。 [3]

Python 的 LiteLLM Harness 风险更直接。CI 刚从 PyPI 拉包并推到生产环境。旧 certifi 或旧 pip 可被伪造的 TLS 站点中间人攻击。 [7] [8]

这会危及依赖下载与内部 API 调用。是否已发生下载替换,尚未验证。

如果 Rust 服务使用 webpki-roots,旧锁文件会保留 G3 根。它可能接受攻击者伪造的公网服务证书。 [5] [6]

公司使用 emSign 签名时也应核查签名链。事件包括 2 个代码签名中间 CA。 [2]

已知受影响代码签名中间 CA 没有最终实体证书。但旧客户端仍应安装撤销或根库更新。 [2] [10]

公司的 Sectigo DV 证书没有证据直接受影响。事件确有 Sectigo AAA 交叉签名路径。 [9]

运维人员应导出该 DV 证书完整链再判断。不可仅凭 CA 品牌推断是否受影响。

根删除也可能造成可用性事故。若任何内部服务使用 G3 链,更新后会出现 TLS 验证失败。 [1]

存疑与未验证

  • eMudhra 尚未公开最终密钥生成脚本根因。
  • Utimaco HSM 是否在批准模式运行,未验证。
  • 非 CT 客户端是否已被在野利用,未知。
  • 受影响用户数、下载量和资金损失,未找到可靠数字。
  • CVE-2026-111943 的 CVSS 分数,未评分。
  • Chrome 计划于 10 月 27 日的根库发布,尚未验证完成。
  • 该公司是否锁定旧 webpki-roots,未验证。
  • 该公司的 Go 二进制版本和根库来源,未验证。
  • 该公司 Sectigo DV 的完整证书链,未验证。
  • emSign Root CA - C1 与 C3 的退休不等同于本次 G3 事故。

参考资料

调研截止 2026-10-22 UTC+8 · 未验证的内容已在正文中标注 · 数字以原始来源为准

本页目录