eMudhra CA 失陷：Chrome 于 10 月 27 日移除 emSign ECC Root CA - G3

要点速览

• 一位署名 Wayne 的研究人员于 2026 年 10 月 17 日证明，任何人都能从公开证书计算出八个 eMudhra 中间 CA 证书的私钥，并用每个恢复出的密钥签名消息作为证据。eMudhra 将原因归于 2025 年 4 月 30 日密钥仪式中有缺陷的密钥封装步骤。八个值都是小于 256 的整数；Scott Helme 在笔记本电脑上不到一秒便恢复了它们。
• 持有中间 CA 密钥的任何人都能为任意域名签发有效证书，对信任它的客户端而言，这意味着无法察觉的网站和服务冒充。Chrome（CRLSets）和 Firefox（OneCRL）于 10 月 17 日阻止了这些中间证书；根据 Apple 公告，Apple 自 10 月 19 日开始阻止，Microsoft 则于 10 月 20 日阻止。六个 TLS 中间 CA 从未有任何证书记录到证书透明度日志，因此没有证书进入强制执行 CT 的浏览器。
• 暴露范围涵盖所有既不强制执行 CT、又不使用吊销信息的客户端：curl 及其他命令行工具、语言运行时及自带 CA 包的应用、基于未修补 Electron 版本构建的 Slack 和 Discord 等 Electron 应用，以及物联网和嵌入式设备。Go、Node.js、Python、certifi、Electron、主要发行版和许多厂商已发布更新或密钥拒绝列表。
• 如果您运营的网站证书链通向 emSign ECC Root CA - G3，Chrome 会在 Root Store 版本 43 中移除该根，预计于太平洋时间 10 月 27 日上午到达设备。Google 要求立即获取并安装来自另一层级的证书。约 30,800 张未过期证书链通向该根，其中百分之 99.9 通过 InCommon 签发。

我是否受影响？

两类群体受影响：仍信任 emSign ECC Root CA - G3 或已失陷中间证书、且不检查 CT 和吊销的客户端，以及证书链通向该根的站点运营者。两方面都应检查。

证书透明度（CT）是一套公开、只能追加的日志系统，用于记录已签发的 TLS 证书。强制执行 CT 的浏览器，仅信任附有证据证明其已被记录的证书。

作为客户端用户（有人能拦截我的连接吗？），如果以下条件全部成立，您就受影响：

• 软件针对系统或内置的信任存储验证 TLS，该存储仍包含 emSign ECC Root CA - G3，或仍接受已失陷的中间证书。
• 软件不强制执行证书透明度，这排除了浏览器（Chrome、Edge、Firefox、Safari），但不排除 curl、大多数语言运行时、大多数 Electron 应用和大多数嵌入式客户端。
• 软件不使用已推送的吊销阻止列表（OneCRL、CRLite、CRLSets），这些机制已经保护浏览器。

使用事件网站公布的检查主机直接测试客户端。证书错误意味着客户端受到保护。成功连接意味着它仍信任已失陷的中间证书，而在“noct”主机上成功连接还意味着它不强制执行 CT。

curl 本身从不检查证书透明度，因此只要信任证书链，就会成功连接“noct”主机。要测试 CT 强制执行情况，请从您要检查的客户端连接这些主机：

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/        # chain without SCTs; curl does not check CT
curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/

作为服务器运营者（我的站点会失效吗？），只要您提供的任意证书链通向 emSign ECC Root CA - G3，就受影响。根据 Chrome 对 CT 日志的统计，截至 10 月 21 日约有 30,800 张未过期证书如此。其中百分之 99.9 通过 InCommon 签发，这是 Internet2 为高等教育运营的证书服务。InCommon 在 2026 年 4 月至 7 月期间迁移到了 eMudhra 的 CertiNext 平台。

其中两个 CVE 有分配机构给出的 CVSS 评分：CVE-2026-115557 为 9.4 严重（CVSS 4.0，Python Software Foundation），CVE-2026-114820 为 9.1 严重（CVSS 3.1，Oracle）。Go 的 CVE-2026-111943 记录没有评分。Mozilla 也未给 CVE-2026-113470（Firefox）评分；CISA 对记录的补充评为 5.4 中危（CVSS 3.1）。

事件网站还跟踪数十个其他项目，包括 Bun 1.4.4、Deno 2.9.8、Docker Desktop 4.96.2、Git for Windows 2.56.0.3、VS Code 1.143.1、GitHub CLI 2.102.1、conda 26.9.4、pip 26.2.2 和 mitmproxy 12.3；截至 10 月 27 日，LibreOffice、Godot、certbot 和 containerd 仍待修复。

自带 Node 的工具只有迁移到已修补运行时，才能继承修复。低于 2.14.0 的 mongosh 针对宿主 Node 运行时的信任存储进行验证，而 2026 年 10 月 23 日发布的 2.14.0 捆绑 Node 24.22.1，其中包含密钥阻止列表。

如何修复？

修补所有浏览器和非浏览器客户端，然后在 10 月 27 日之前替换任何链通向 emSign ECC Root CA - G3 的证书。作为客户端运营者，请按以下顺序更新：

1. 浏览器和操作系统会自动更新；请确认它们已是最新版本，因为阻止项分别通过 Chrome CRLSets（10 月 17 日）、Firefox OneCRL（10 月 17 日）、Android Google Play 服务（10 月 19 日）、Apple 自动信任列表更新（根据其公告，自 10 月 19 日起）和 Microsoft 自动信任列表更新（10 月 20 日）下发。

2. 修补表中的每个非浏览器客户端：

   • Go：使用 1.27.3 或 1.26.10 重新构建二进制文件。
   • Node.js：更新运行时及任何捆绑运行时的应用。
   • Python：更新至 3.15.2、3.14.10、3.13.18、3.12.16 或 3.11.18，这些是 ssl 模块首次包含 CVE-2026-115557 拒绝列表的版本；或固定使用 certifi 2026.10.19 或更高版本。
   • Java：更新至 Azul 的计划外构建，或其他会阻止这些密钥的 JDK。
   • Electron：基于 42.11.16 或更高版本重新构建应用。

   警告：10 月 21 日发布的 Python 3.15.1、3.14.9 和 3.13.17 不包含拒绝列表。它们捆绑的 pip 26.2.2 内置 certifi 2026.10.19，这只保护 pip 自身的操作。

3. 对于发行版，安装更新后的 ca-certificates 包；对于软件包仍待发布的 RHEL 7，应用 Red Hat 文档中的信任存储阻止列表临时措施。

特别是在 macOS 上，命令行 curl、git 和内置 Python 针对 /etc/ssl/cert.pem 进行验证，不检查吊销。Apple 公告 149555 表示，该平台自 10 月 19 日起阻止十二张中间证书，自 10 月 23 日起阻止该根，而这些命令行工具检查的文件 /etc/ssl/cert.pem 的修复“将在未来的软件更新中提供”。

在此之前，使用事件网站发布的移除脚本，从该文件移除 emSign ECC Root CA - G3。第二步还会移除 Sectigo 的 AAA Certificate Services 根，以阻断六个交叉签名副本；脚本警告，移除 AAA 可能使无关站点失效，且 macOS 更新可能恢复该文件。

对于使用 emSign ECC Root CA - G3 下证书的网站运营者，没有临时解决方案：Google Chrome Root Program 要求运营者“必须立即从 Chrome Root Store 中包含的另一个 PKI 层级获取并安装新 TLS 证书”，赶在根移除于太平洋时间 10 月 27 日上午到达设备之前。

Chrome 还警告，标准 ACME 客户端不会在续期窗口之外替换证书，除非支持 ACME Renewal Information（ARI），或有人手动干预；eMudhra 估计约 30,000 张证书需要迁移，其中约百分之 97 通过 ACME 签发。大学用户报告了一条实际可行路径：位于 eMudhra 未受影响 G1 根下的 InCommon RSA 证书目前仍可用，Let's Encrypt 则是常见替代方案。

根本原因是什么？

中间 CA 私钥必须是不可预测的随机数；eMudhra 的密钥仪式在预期的强密钥之外，还生成了第二组密钥，其可预测性如此之高，以至于公开证书本身就暴露了它们。

八个中间 CA 中，六个用于 TLS（G3B 和 G3C 变体的 EM DV、EM OV 和 EM EV TLS CA），两个用于代码签名（EM OV CS CA G3B 和 G3C）。它们在 2025 年 4 月 30 日的密钥生成仪式中，于经过 FIPS 140-2 Level 3 认证的硬件安全模块上，在 emSign ECC Root CA - G3 下创建。

eMudhra 在事件声明中表示，“一个密钥封装/解封装步骤在原始强密钥之外，生成了第二组弱密钥”。密钥封装将密钥打包以便传输，解封装再将其解开。eMudhra 补充说，“发布到浏览器根存储的是弱密钥”。

事件网站明确说明后果：“中间证书的私钥由 CA 错误生成。这意味着任何人都可以从证书中恢复它们。”Scott Helme 实际验证了这一点，在笔记本电脑上不到一秒便从公开证书恢复了全部八个密钥。

八个值之一是数字 4；其余也都是小于 256 的整数。

随后又出现两个加重事件严重性的事实。

2025 年，eMudhra 曾为其中六个中间 CA 发布无效 CRL，并称已通过“使用与每个中间 CA 关联的适当私钥重新生成 CRL”修复。2026 年 10 月 19 日，该公司告知 Mozilla，这些列表实际上是“用有缺陷的密钥重新签名”的，即同一批弱密钥。Chrome 表示，这“引发了对 eMudhra 透明度和事件处理的严重担忧”。

2026 年 10 月 14 日，eMudhra 为 emSign Root TLS CA - G1 发布一份 CRL，其签名无法用该 CA 的密钥验证。Mozilla 缺陷报告的一位参与者判断，它是用 OCSP 证书的密钥签名的，“属于使用错误签名密钥的情况，而非另一把弱密钥的证据”。

截至 10 月 22 日，eMudhra 尚未回答 Chrome 就这些问题提出的十二个问题。

如何利用？

利用过程机械而直接：从公开证书重新计算八个私钥之一，为目标域名伪造叶证书，然后拦截一个跳过 CT 和吊销检查的客户端连接。目前未观察到在野利用。受影响客户端的攻击路径如下：

1. 攻击者从公开中间证书计算出八个私钥之一，这一步在笔记本电脑上耗时不到一秒。
2. 攻击者为想冒充的任意域名签发由该中间 CA 签名的证书，并在能够拦截或响应受害者连接的位置提供它：恶意接入点、BGP 或 DNS 拦截，或恶意内网主机。
3. 受害客户端从伪造叶证书经中间证书构建到可信根的证书链：要么是证书包中的 emSign ECC Root CA - G3，要么经中间 CA 的交叉签名副本到 Sectigo 的 AAA Certificate Services。
4. 如果客户端不强制执行证书透明度，且未收到吊销阻止项或更新证书包，连接便被接受。强制执行 CT 会迫使攻击者公开记录伪造证书，从而可能被发现。浏览器不满足这两个易受攻击条件，因此安全；大多数命令行工具、内置运行时和嵌入式客户端过去则在这两项检查上都缺失，在修补前处于暴露状态。

决定性的缓解事实是，在阻止项生效之前，没有任何链通向六个 TLS 中间 CA 的证书被记录到证书透明度日志。强制执行 CT 的浏览器要求证书已被记录，因此这些中间 CA 的伪造证书没有进入 Chrome、Edge、Firefox 或 Safari。是否有人针对非 CT 客户端使用过这些密钥，无法从 CT 日志得知，事件网站也表示未知。

攻击流程是什么？

流程是线性的：从公开证书计算密钥，为目标域名伪造叶证书，占据连接路径上的位置，然后让非 CT 客户端验证该证书链。

攻击者能做什么？

面对未修补的非 CT 客户端，攻击者可冒充该客户端通过 TLS 连接的任何网站或服务：窃取凭据、将恶意软件作为更新源提供，或重定向 API 流量，且使用的证书完全受客户端信任。条件如下：

• 处于能够拦截或响应受害者流量的网络位置。除连接外，无需受害者采取其他动作。
• 客户端信任某个受影响根或交叉签名，不强制执行 CT，且尚未收到阻止项。这一组合排除了当前浏览器，但包括基于 curl 的工具、自带证书包的运行时和应用、基于修补前版本构建的 Electron 应用，以及物联网设备。
• 没有其他要求。密钥从未被盗，因为根本不需要盗取：它们实际上就发布在证书本身中。

两个代码签名中间 CA 将理论影响面扩展到信任它们的平台上的签名代码，不过 Chrome 的 TLS 验证器不会通过仅限代码签名的中间 CA 构建路径，且没有代码签名滥用报告。证书透明度日志证明没有伪造 TLS 证书进入浏览器，但它只覆盖 TLS 证书，因此无法为签名代码提供同等审计轨迹。

修复为什么有效？

修复之所以有效，是因为它封闭了伪造证书链可能经过的每条路径：密钥拒绝列表拒绝弱密钥本身，证书包移除切断根，推送吊销则在浏览器中阻止中间证书。各机制覆盖范围不同：

• 密钥拒绝列表，最强保护： Go 的 crypto/x509、Node.js 和 Python 的 ssl 模块拒绝任何携带八个密钥之一的证书，包括 Sectigo 交叉签名副本。Python 匹配每张证书 SubjectPublicKeyInfo 的 SHA-256 哈希，不受 SSLContext 策略影响，Go 的拒绝列表则没有关闭开关。
• 证书包移除，覆盖最广： certifi、webpki-roots、Debian、Ubuntu、Fedora、RHEL 及其他发行版软件包完全移除 emSign ECC Root CA - G3，切断该根下的所有证书，无论合法还是伪造。
• 推送吊销，速度最快： CRLSets、OneCRL 和 Microsoft 信任列表更新无需软件更新，就能为浏览器阻止中间证书。

这些机制的局限很重要。拒绝列表只有在软件重新构建或更新后才有帮助；Go 二进制文件必须重新编译。

证书包移除也会切断该根下的合法证书，Mozilla、Canonical 和 Red Hat 都对此发出警告；这也正是 Chrome 于 10 月 27 日移除根本身时，约 30,800 张有效证书会失效的原因。

基于吊销的保护仅覆盖实际使用吊销数据的客户端，而受影响的非浏览器客户端通常不使用。这一缺口正是 Go、Node.js 和 Python 引入密钥拒绝列表模式的原因。正如 Filippo Valsorda 在 Go 问题讨论中所说：

“Linux 根存储的维护过于不一致，吊销信息无法可靠到达应用，因此直接在代码中拒绝这些密钥。”

如何检查是否已遭入侵？

目前没有公开方法能检测过去针对非 CT 客户端滥用这些密钥的行为，事件网站表示，不知道是否有人在 10 月 17 日之前利用过有缺陷的生成过程。您能验证的内容包括：

• 客户端侧，在每个重要环境中运行“我是否受影响？”部分的四个检查主机测试，包括容器内部和构建机器。网站还提供 chains.zip，其中以 PEM 格式包含每条所提供的证书链，可用 OpenSSL 离线验证，并提供按用户代理统计的检查成功数据。
• 服务器侧，使用您选择的 CT 日志监控工具，盘点证书中任何链通向 emSign ECC Root CA - G3 或 emSign Root TLS CA - G3 的项目；发现的证书必须在 10 月 27 日之前替换，而非只是持续观察。
• 证书管理侧，检查 ACME 设置是否支持 ACME Renewal Information（RFC 9773）；没有它，客户端不会在续期窗口之外替换证书，因此一张 11 月才过期的证书仍可能在 10 月 27 日失效。

时间线

• 2025-04-30：eMudhra 密钥生成仪式创建八个中间 CA，在强密钥之外生成弱密钥组。
• 2025：eMudhra 为同一批中的六个中间 CA 发布无效 CRL，后来承认是“用有缺陷的密钥重新签名”。
• 2026-10-17：Wayne 向根计划报告可恢复的密钥，并提供签名证据；Chrome 于 19:45 UTC 前发布 CRLSet 阻止项，Mozilla 于 22:59 UTC 前推送 OneCRL。
• 2026-10-19：下游信任存储收到通知；Android 约在 22:00 UTC 通过 Google Play 服务收到阻止项；根据 Apple 公告，Apple 开始在设备上阻止十二张中间证书；eMudhra 告知 Mozilla，2025 年的 CRL 是用有缺陷的密钥重新签名的。
• 2026-10-20：Mozilla 和 Google 发布说明；Go 发布 1.27.3 和 1.26.10；certifi 发布 2026.10.19；Firefox 158.0.1 和 ESR 携带阻止项；Microsoft 平台阻止项到达；Mozilla 从 NSS 移除该根。
• 2026-10-21：eMudhra 在 BSE 新闻稿中披露仪式缺陷；CERT-In 发布公告 CIAD-2026-0050；Red Hat 发布 RHSB-2026-012；Node.js 发布阻止列表；Azul 发布阻止八个中间 CA 的计划外 Zulu 和 Zing 构建；eMudhra 股价在孟买下跌百分之 20。
• 2026-10-22：eMudhra 董事会决定退出全球 SSL/TLS 业务（约占收入百分之 1）；Chrome 向 eMudhra 提出的十二个问题仍未获得公开回答。
• 2026-10-23：根据其公告，Apple 也开始阻止 emSign ECC Root CA - G3。
• 2026-10-24：Python 宣布 ssl 模块拒绝列表，编号为 CVE-2026-115557，并回移至 3.11 至 3.15 维护分支。
• 2026-10-25：Python 发布 3.15.2、3.14.10、3.13.18、3.12.16 和 3.11.18，这是首批携带拒绝列表的版本；certifi 2026.10.23 成为当前版本。
• 2026-10-27：Chrome Root Store 版本 43 移除 emSign ECC Root CA - G3，预计于太平洋时间 10 月 27 日上午到达设备。截至 10 月 27 日上午，Apple 覆盖命令行工具的 macOS 更新仍未发布，其安全发布索引也没有该事件条目，因此下述手动处理 /etc/ssl/cert.pem 的步骤仍是内置 curl、git 和 Python 的修复办法。

常见问题

我的浏览器现在可以安全使用吗？

可以。Chrome、Edge、Firefox 和 Safari 强制执行证书透明度，六个 TLS 中间 CA 从未有任何证书记录到 CT，因此即使在吊销阻止项到达之前，这些中间 CA 的伪造证书也没有进入浏览器。自 10 月 17 日起的阻止项，进一步封闭了浏览器可能在不检查 CT 时接受证书的路径。

我更新了 macOS，为何 curl 仍易受攻击？

Apple 通过自动证书配置更新，于 10 月 19 日阻止十二张中间证书（每个 TLS 中间 CA 在 eMudhra 根下和由 Sectigo 交叉签名的各一张），并于 10 月 23 日阻止该根。这些措施保护 Safari、Mail 和使用 Apple 网络及安全框架的应用。

内置 curl、git 和 Python 针对 /etc/ssl/cert.pem 验证，不检查吊销。Apple 公告 149555 表示，该处修复“将在未来的软件更新中提供”。在此之前，请手动或使用事件网站脚本从文件中移除该根；macOS 更新可能恢复该文件。

我的网站真的会在 10 月 27 日失效吗？

只有证书链通向 emSign ECC Root CA - G3 才会；截至 10 月 21 日，约有 30,800 张未过期证书如此。对这些证书，答案是会：Root Store 版本 43 一旦到达 Chrome 用户，证书链就不再能通过验证。Google 要求运营者立即替换证书，不要等待移除发生，并记住没有 ARI 支持的 ACME 客户端不会提前续期。

eMudhra 被黑了吗？

没有系统被攻破，也没有密钥被盗，这正是事件的特殊之处。密钥生成不当，而生成不当的密钥实际上等于公开：任何拥有证书的人都能计算它，无需入侵。eMudhra 表示，八个中间 CA 中七个从未在生产环境使用，而全部八个，包括被使用过的那个，都未签发终端实体证书。

我还需要移除 Sectigo 根吗？

仅针对您无法用其他方法修复的客户端。八个中间 CA 中的六个还存在 Sectigo AAA Certificate Services 根下的交叉签名版本，因此仅移除 emSign ECC Root CA - G3 会留下这些路径。但移除 AAA 也会切断其下每张合法证书，这就是同时移除两者的发行版更新会警告服务中断的原因，也解释了为何有密钥拒绝列表修复时，它是更好的选择。

这与我在 10 月 20 日安装的 Go 紧急更新是同一件事吗？

是。Go 当天发布 1.27.3 和 1.26.10，没有指明 CA 名称，而是通过 URGENT 流程在 crypto/x509 中阻止八个密钥哈希；这八个哈希与这八张证书一致。Go 安全团队表示，发布说明保持模糊，是因为漏洞极易利用，且预计详情会在当天公开。

找出会在 10 月 27 日失效的证书

使用 Ostorlab Attack Surface Discovery 盘点您拥有的面向互联网的域名和主机。随后检查每个服务提供的证书链是否包含 emSign ECC Root CA - G3，并在 Chrome 于 10 月 27 日移除该根之前替换所有匹配项。

参考资料

• 事件网站，包含证据、检查主机、离线证书链包及已修补项目表，自 2026 年 10 月 20 日起维护：https://emudhra.we-have-a-problem.com/ （核查于 2026 年 10 月 27 日）
• Apple 关于 eMudhra 中间 CA 失陷的公告 149555：自 10 月 19 日开始阻止中间证书，自 10 月 23 日阻止根，/etc/ssl/cert.pem 修复将在未来更新提供，含手动移除步骤；Apple 安全发布索引，2026 年 10 月 27 日上午检查是否有该事件条目：https://support.apple.com/en-us/149555 和 https://support.apple.com/en-us/100100 （核查于 2026 年 10 月 27 日）
• Azul 关于 eMudhra 中间 CA 失陷的声明，2026 年 10 月 22 日，说明 10 月 21 日计划外 Zulu 和 Zing 构建阻止八个中间 CA：https://www.azul.com/newsroom/azul-statement-on-the-emudhra-intermediate-ca-certificates-compromise/ （核查于 2026 年 10 月 26 日）
• Google 关于保护 Chrome 和 Android 用户免受已失陷 eMudhra 中间 CA 证书影响的说明，2026 年 10 月 20 日：https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/ （核查于 2026 年 10 月 25 日）
• Mozilla 关于保护 Firefox 用户的说明，2026 年 10 月 20 日：https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/ （核查于 2026 年 10 月 25 日）
• 报道引用的 Chrome Root Program 和 Mozilla 策略列表讨论：https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/Kp1v6CPuAAAJ （核查于 2026 年 10 月 25 日）
• eMudhra 向 BSE 证券交易所提交的新闻稿，涉及 2025 年 4 月 30 日仪式缺陷：https://www.bseindia.com/xml-data/corpfiling/AttachLive/6be0c423-b335-494b-86f3-54c561c3a5f9.pdf （核查于 2026 年 10 月 25 日）
• eMudhra 的证书安全事件声明：https://emudhra.com/en/post/certificate-security-incident （核查于 2026 年 10 月 25 日）
• Scott Helme 独立恢复密钥，在不到一秒内恢复八个密钥，其中一个为数字 4：https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/ （核查于 2026 年 10 月 25 日）
• The Hacker News 关于八个 CA 密钥失陷及生态系统紧急修复的报道，2026 年 10 月 20 日发布，10 月 21 日更新：https://thehackernews.com/2026/10/eight-emudhra-ca-keys-compromised.html （核查于 2026 年 10 月 25 日）
• The Hacker News 关于 eMudhra 退出全球 SSL/TLS 业务、约 30,800 张未过期证书、InCommon 高度集中及 Chrome 10 月 27 日移除计划的报道，2026 年 10 月 22 日：https://thehackernews.com/2026/10/emudhra-to-exit-global-ssltls-business.html （核查于 2026 年 10 月 25 日）
• Go 阻止八个密钥的紧急发布，CVE-2026-111943：https://groups.google.com/g/golang-announce/c/66pojueaQek 和 https://cveawg.mitre.org/api/cve/CVE-2026-111943 （核查于 2026 年 10 月 25 日）
• Python 的 ssl 模块拒绝列表公告，CVE-2026-115557，2026 年 10 月 24 日：https://www.openwall.com/lists/oss-security/2026/10/24/5 和 https://cveawg.mitre.org/api/cve/CVE-2026-115557 （核查于 2026 年 10 月 25 日）
• Firefox CVE-2026-113470 记录，Mozilla 未评分，CISA 补充评分为 5.4 中危：https://cveawg.mitre.org/api/cve/CVE-2026-113470 （核查于 2026 年 10 月 27 日）
• CPython 发布变更日志，确认拒绝列表首次随 10 月 25 日的 3.15.2、3.14.10、3.13.18 和 3.12.16 发布；CPython 对比视图确认同日打标签的 v3.11.18 包含回移补丁：https://docs.python.org/3.15/whatsnew/changelog.html 和 https://github.com/python/cpython/compare/af52b41afa4330fb38583db553631baa2f122f90...v3.11.18 （核查于 2026 年 10 月 26 日）
• Oracle 移除 eMudhra 根的带外 Java 警报，CVE-2026-114820：https://www.oracle.com/security-alerts/alert-cve-2026-114820.html （核查于 2026 年 10 月 25 日）
• certifi 公告 GHSA-6q48-6c7w-9gw2，移除 emSign 根：https://github.com/certifi/python-certifi/security/advisories/GHSA-6q48-6c7w-9gw2 （核查于 2026 年 10 月 25 日）
• uv 公告 GHSA-hq85-5cpj-mr62，移除 emSign 根：https://github.com/astral-sh/uv/security/advisories/GHSA-hq85-5cpj-mr62 （核查于 2026 年 10 月 25 日）
• Red Hat 安全通告 RHSB-2026-012，含 RHEL 信任存储临时措施：https://access.redhat.com/security/vulnerabilities/RHSB-2026-012 （核查于 2026 年 10 月 25 日）
• CERT-In 公告 CIAD-2026-0050，2026 年 10 月 21 日：https://www.cert-in.org.in/s2cMainServlet?pageid=PUBVLNOTES02&VLCODE=CIAD-2026-0050 （核查于 2026 年 10 月 25 日）
• Cloudflare 已修复的 WARP、1.1.1.1 客户端和 cloudflared 2026.10.2：https://blog.cloudflare.com/emudhra-certificate-compromise （核查于 2026 年 10 月 25 日）
• mongosh 2.14.0 发布，2026 年 10 月 23 日，捆绑带有密钥阻止列表的 Node 24.22.1，而早期版本针对宿主 Node 运行时信任存储验证：https://github.com/mongodb-js/mongosh/releases/tag/v2.14.0 （核查于 2026 年 10 月 27 日）