ONCALL://19
INC-05 · 印度 CA 泄漏

eMudhra 8 个中间 CA 私钥可被恢复

印度 CA eMudhra 在 2025-04-30 生成的 8 个中间 CA 密钥有缺陷,私钥可从公开证书恢复。拿到私钥的人可以伪造网站证书和代码签名。这不是根私钥或客户数据泄漏。

INC-05严重直接命中证书信任P1今天披露 2026-10-20
段子原句“公司的软件和外发机密文件通过 emSign 代码签名”
编号
CVE-2026-111943GHSA-6q48-6c7w-9gw2
严重度
certifi 的 GHSA 评为 Critical;CVE-2026-111943 无 CVSS
利用状态
未见利用未见利用:8 把 P-384 私钥可从公开证书瞬时恢复。未发现在野滥用。
对段子公司
受影响的 8 张中间 CA 里有 2 张用于代码签名,属于 emSign 体系。段子里的三个根证书库在修复前都信任这条链。
影响范围
8 张弱中间 CA 中 6 张用于 TLS,2 张用于代码签名。eMudhra 称它们没有签发终端证书,只有 1 张投入生产。Sectigo 为这 8 张做过交叉签名,同钥证书共 16 张。
修复版本
  • →Firefox OneCRL、Chrome CRLSet 已阻断
  • →Go 1.26.10 / 1.27.3、certifi 2026.10.19、pip 26.2.2、webpki-roots 1.0.10、Node.js 24.22.1
  • →Chrome 计划 10-27 移除 emSign ECC Root CA - G3
同一事件:INC-05、INC-12、INC-17 是同一个事件,分别从 CA 本身、Sectigo 交叉签名和根证书库三个角度调查。 INC-12 Sectigo DV、INC-17 根证书库
处置清单见处置顺序 · P1

结论

本案确认是中间 CA 私钥失效事故。[1] [2]它不是 eMudhra 根私钥或客户数据泄漏。[6] [7]8 把 P-384 私钥可从公开证书瞬时恢复。[2]截至 2026-10-22 UTC+8,未见在野滥用证据。[6] [8]

事件经过

研究员 Wayne 发现 8 张 eMudhra 中间 CA 的异常密钥。[2]他在 2026-10-17 同时通知四个根计划和 eMudhra。[2]Mozilla 独立复现了私钥恢复。[2]

受影响者不是客户终端证书。它们是 8 个可签发的中间 CA。[1] [2]其中 6 个用于 TLS。另 2 个用于代码签名。[1] [3]

eMudhra 称 7 个未投产。第 8 个投产后也未签发终端证书。[6]因此,现有 emSign 代码签名私钥泄漏未获证实。客户 KYC 数据、已签文件和资金损失均未找到证据。

eMudhra 称其基础设施未被入侵。eMudhra 称未发生数据泄漏。[6] [7]这与通常的入侵型 CA 泄漏不同。这是错误生成的 CA 私钥等同公开。

技术细节

2025-04-30 的仪式一次生成 24 个中间 CA。[2]这批证书覆盖 A、B、C 三个系列。[2]它们覆盖 RSA-4096 与 P-384 两种算法。[2]它们覆盖 DV、OV、EV、代码签名四类用途。[2]

失效者是 B、C 系列的 8 把 P-384 密钥。[2]每把私钥标量小于 256。[2]正常 P-384 私钥应为接近曲线阶的随机整数。[2]攻击者可枚举前 256 个私钥并比对公钥。[2]Mozilla 称该恢复过程近乎即时完成。[2]

受影响中间 CA用途状态
EM DV TLS CA - G3BTLS已撤销
EM OV TLS CA - G3BTLS已撤销
EM EV TLS CA - G3BTLS已撤销
EM DV TLS CA - G3CTLS已撤销
EM OV TLS CA - G3CTLS已撤销
EM EV TLS CA - G3CTLS已撤销
EM OV CS CA - G3B代码签名已撤销
EM OV CS CA - G3C代码签名已撤销

证书清单确认以上 8 张均已撤销。[10]这些证书还存在 Sectigo AAA Certificate Services 交叉签名链。[10]相关根包括 emSign ECC Root CA - G3。[4] [10]相关根还包括 Comodo AAA Services。[4] [10]

eMudhra 使用了 FIPS 140-2 Level 3 HSM。[6] [7]HSM 的使用没有阻止这次故障。仪式的 wrap/unwrap 步骤产生了第二组弱密钥。[6] [7]工作人员发布了这组弱密钥而非原强密钥。[6]截至报告日,具体代码缺陷仍未最终确认。[6]

私钥持有者可伪造任意域名的 TLS 证书。[1] [2]攻击者需处于 TLS 网络中间位置。[4]攻击者可借此读取或修改流量。[1] [4]未更新的客户端是主要风险。[4] [8]

Chrome 的 CT 强制会拒绝未记录的公共 TLS 证书。[9]发现前,6 个 TLS 中间 CA 没有 CT 条目。[1]所以 Chrome 等 CT 强制客户端无已知可用伪证书。[1] [9]服务器、SDK 和私有根库常不强制 CT。[8]这些客户端仍可能接受伪造链。

两张代码签名 CA 当时受 Microsoft 信任。[1]攻击者理论上可伪造其签发的代码签名证书。但 eMudhra 称这两张 CA 未投产且零签发。[3] [6]这不证明任何既有软件签名已被伪造。

影响范围

范围已核实数量或状态
弱中间 CA8 张
TLS 中间 CA6 张
代码签名中间 CA2 张
同批生成中间 CA24 张
弱 CA 所签终端证书0 张,按 eMudhra 声明
已投产的弱 CA1 张,按 eMudhra 声明
受根移除影响的生态美国 1 个客户生态,按 eMudhra 声明
受影响业务收入约占 eMudhra 收入 1%,按 eMudhra 声明
已确认在野利用未找到
已确认数据泄漏0,按 eMudhra 声明

8 张 CA 的有效期原可至 2040 年。[10]Sectigo 交叉签名证书的有效期原可至 2028 年。[10]这扩大了未更新信任库的风险窗口。

eMudhra 正为受根移除影响者更换证书。[6]eMudhra 未公开受影响用户数。eMudhra 未公开受影响下载量或资金数额。媒体所称约 30,000 张更换证书未获官方确认。[21]

时间线

  1. 2025-04-30 UTC
    eMudhra 举行密钥生成仪式。[2][6]
  2. 2026-10-17 18:05 UTC
    研究员向四个根计划及 eMudhra 报告。[2][9]
  3. 2026-10-17 19:45 UTC
    Chrome 下发 TLS CA 的 CRLSet 阻断。[1]
  4. 2026-10-17 20:06 UTC
    Mozilla 收到并确认报告。[1][2]
  5. 2026-10-17 21:48 UTC
    Mozilla 独立恢复这些私钥。[2]
  6. 2026-10-17 22:59 UTC
    Firefox OneCRL 覆盖标准配置用户。[1]
  7. 2026-10-18 09:24 至 09:39 UTC
    eMudhra 逐张撤销 8 个 CA。[2][10]
  8. 2026-10-19 10:35 UTC
    Sectigo 交叉签名链完成撤销。[10]
  9. 2026-10-19 UTC
    Apple 设备开始阻断,机制未公开。[8]
  10. 2026-10-20 02:13 UTC
    Go 发布 1.27.3 与 1.26.10。[11]
  11. 2026-10-20 UTC
    Mozilla 公开事件并发布 Firefox 更新。[1]
  12. 2026-10-20 UTC
    Microsoft 平台开始通过自动 CTL 阻断。[8][14]
  13. 2026-10-21 UTC
    NVD 收录 CVE-2026-111943,未给 CVSS。[12]
  14. 2026-10-21 UTC
    Firefox Android 发布 158.0.2。[15]
  15. 2026-10-27 PDT,计划计划
    Chrome 根库移除 emSign ECC Root CA - G3。[4][9]

修复与缓解

根计划与平台处置

计划或平台已采取处置截至 2026-10-22 UTC+8 状态
MozillaOneCRL 阻断 8 张 CA已完成
MozillaNSS 3.131.1 移除相关根已发布
Firefox158.0.1、ESR 115.43.1、ESR 153.5.1已发布
Firefox Android158.0.2 修复启动时 OneCRL 安装已发布
ChromeCRLSet 按 SPKI 阻断 6 张 TLS CA已完成
ChromeGoogle Play Services 更新 Android已推送
Chrome移除 emSign ECC Root CA - G3计划 2026-10-27 PDT
Apple设备阻断受影响证书2026-10-19 起,细节未公开
Microsoft自动 Untrusted CTL 阻断2026-10-20 起,具体 KB 未验证

Mozilla 的 OneCRL 无需重启 Firefox。[1]Chrome 的 CRLSet 无需浏览器更新或重启。[4]Windows 默认每日更新信任与不信任 CTL。[14]离线设备或禁用更新设备需要管理员处置。[8] [14]

依赖与根库更新

组件受影响范围固定版本或措施
Go crypto/x509低于 1.26.10升级 1.26.10
Go crypto/x5091.27.0-0 至 1.27.3 前升级 1.27.3
Python certifi2019.03.09 及以后使用 2026.10.19
pip低于 26.2.2升级 26.2.2
Rust webpki-roots含旧 emSign 根的版本升级 1.0.10
Rust rustls-webpki低于 0.103.16升级 0.103.16
Node.js 24 LTS24.22.1 前升级 24.22.1
RHEL ca-certificates6 至 10 及其派生容器更新包或临时拒绝相关根

CVE-2026-111943 只覆盖 Go 的缓解改动。[12] [13]它不是 eMudhra CA 本身的 CVE。NVD 尚未给此 CVE 的 CVSS 指标。[12]

GHSA-6q48-6c7w-9gw2 将 certifi 评为 Critical。[5]该 GHSA 未分配 CVE 或 CWE。[5]GHSA-hq85-5cpj-mr62 将 uv 评为 High。[16]该 GHSA 也未分配 CVE 或 CWE。[16]

pip 会同时加载其内置 certifi。[3]因此,仅更新系统根库不足以修复旧 pip。[3]团队应先升级 pip 26.2.2。团队随后应重建虚拟环境与容器镜像。[3]

管理员应盘点自带 CA 包的程序。管理员应盘点自定义 CA 文件和静态容器。管理员不应以关闭 TLS 验证来绕过报错。[4]紧急情况下,可拒绝两个相关根。[4]这会导致仍依赖这些链的服务失败。

对段子中公司的影响

段子中的 Python + LiteLLM CI 是高风险路径。它昨晚从 PyPI 拉包并推入生产。若环境的 certifi 或 pip 未更新,风险存在。[3] [5]网络中间人可伪造 pypi.org 的 TLS 身份。攻击者随后可尝试替换下载的依赖包。这需要攻击者控制或拦截该网络路径。目前未找到 LiteLLM 或 PyPI 被本案实际篡改的证据。

段子中的 Go 网络沙箱也可能受影响。其 crypto/x509 低于固定版本时仍可能信任伪链。[12] [13]它应升级到 1.26.10 或 1.27.3。

段子列出的 Rust webpki-roots 也直接相关。其根包应升级到 1.0.10。[17]rustls-webpki 应升级到 0.103.16。[18]段子列出的 Node.js 24 应升级至 24.22.1。[19]该版本更新了 NSS 3.131.1 根证书。[19]

段子所称 emSign 代码签名不等于已泄漏。公司应先检查签名证书的完整颁发链。这两张弱代码签名 CA 按厂商称零签发。[3] [6]若公司证书不经它们签发,现有私钥未受本案影响。

不过,未更新 Windows 主机仍可能接受伪造签名链。攻击者可用弱 CA 私钥签发冒充性代码签名证书。这会削弱软件与外发文件的来源鉴别。公司应强制 Windows CTL 更新。公司应隔离离线签名验签主机。公司应对外发制品附加哈希和独立签名验证。

存疑与未验证

  • eMudhra 尚未公开最终代码根因。[6]
  • 未找到独立在野利用证据。[6] [8]
  • 未找到客户 KYC 数据外泄证据。[6] [7]
  • 未找到已签文档外泄证据。
  • 未找到既有代码签名私钥外泄证据。
  • 未找到 Apple 的专门公开技术公告。
  • Apple 阻断时间来自事件追踪页。[8]
  • 未找到 Microsoft 的专门 KB 或 CTL 编号。
  • Microsoft 处置时间来自事件追踪页。[8]
  • 约 30,000 张替换证书仅见媒体报道。
  • eMudhra 官方页未确认该数字。[6] [7]
  • 段子公司的实际证书链和版本未知。
  • 因此,具体受害状态未验证。

参考资料

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

本页目录