eMudhra：八个 CA 私钥，计算器按几下就猜出来了

CA 的私钥，是“这真的是你的银行”这句话能成立的根本。eMudhra 有八张中间证书，P-384 私钥都是小于 256 的整数。据研究人员 Scott Helme 说，其中一个就是数字 4。谁要是注意到了，就能给任意域名签证书，而所有信任这条链的客户端都会照单全收。

这些中间证书挂在 emSign ECC Root CA - G3 下面，还带着 Sectigo 的交叉签名，信任它们的范围因此更大。六张是 TLS CA，两张是受微软信任的代码签名 CA。eMudhra 称问题出在密钥封装/解封装的一个缺陷上，导致生成了一批弱密钥。

为什么是 L4 而不是 L5

信任锚被攻破，一般都够得上 L5“屎无前例”。复核之后，我们把它降了一级：

• 没有迹象表明有人滥用过。证书透明度（CT）日志里没有这些中间证书签发的终端实体证书。
• 浏览器在收到报告几小时内就拦截了它们，各大平台三天内全部跟进。

真正的风险在长尾：各语言运行时、Java cacerts、各类设备，以及还带着旧证书包的老容器。

10月22日更正： 此前我们认为，约 3 万张证书需要迁移，与八张弱密钥中间证书未签发终端实体证书的说法矛盾。Google 解释，移除父级根证书也会影响其他中间证书下的合法证书。两者属于不同群体，迁移数量不能证明被攻破的密钥签发过证书。

10月22日更新： Docker 已记录使用更新后的 CA 证书重建 Sandboxes 模板。更新 CLI 或缓存模板不会更新现有沙箱。重建前先保存本地文件和未推送的提交，再拉取新镜像重新创建。这次更新改变处置步骤，L4 评级不变。

10月22日进一步更新： eMudhra 董事会决定退出全球 SSL/TLS 证书业务。公司承诺通过合作伙伴免费提供替换证书，并持续提供吊销及状态服务，直到所有已签发证书过期或被替换。退出日期和合作伙伴未明确。Chrome 仍在审查其余 RSA 层级，不能把厂商的过渡计划当作未来浏览器信任的保证。请及时更换受影响的网站证书；Chrome 预计于 10月27日 PDT 移除根证书。

10月23日更新： 此前的指南漏列了自带根证书的包管理工具。即使系统证书或独立 certifi 已更新，也要逐个环境更新 pip，使用 Python 安全公告中带固定哈希的引导升级方式。pip 26.2.2 需要 Python 3.10 或更新版本；旧解释器需要兼容的处置方案，不能假定其 CA 证书包安全。上表新增最低版本来自 Python 及工具维护者，不能替代运行时更新或 10月27日的证书迁移期限。使用 conda 时，base 之外环境的 CA 软件包也要更新。Mamba 重建可能沿用相同版本号，因此还要检查软件包构建号。

应用内嵌证书包与 Java 缓解缺口

10月24日更新： Dart 公告 涉及网络路径上的攻击者拦截 Android、Windows，以及保留受影响根证书的 Linux 环境中的 dart:io HTTPS。公告排除 Web 和 Apple 验证路径，不代表使用独立内嵌 TLS 库的 Firestore 也不受影响。

Firebase 为原生 Apple 应用、iOS/macOS/Windows 上的 FlutterFire，以及 iOS/Linux/macOS/Windows 上的 Unity 或 C++ 列出 Firestore 修复。这些客户端 SDK 的影响范围与上面的 Dart 公告不同。须发布重建后的应用并让用户安装。Cloud Firestore 和 App Distribution 后端不受影响。

Sonatype 发现，使用 ECDSA 或 RSA 签名的中间证书经替代编码后，可在其测试中绕过 Java 指纹阻止。移除相关根证书可拒绝这两条证书链，但可能中断合法连接。请按厂商指南核验每个已部署运行时及信任库；这是实验室复现的缓解绕过，并非在野攻击证据，也不能推广到所有 JDK。

10月25日更新： Oracle 在 10月21日发布中间证书取消信任公告 CVE-2026-91403 后，于 10月24日通过 CVE-2026-114820 提供移除根证书的补丁。两者属于同一事件。公开版本表列出的是受影响构建，并非安全版本；应通过 Oracle 的补丁可用性文档获取对应补丁。仍须完成上面其他运行时和应用的更新。这些公告没有证实在野利用。

未修补的 Oracle 运行时可采用操作指南中的替代办法：备份 cacerts，移除 emsignrootcag1 [jdk]、emsignrootcag2 [jdk]、emsigneccrootcag3 [jdk] 和 comodoaaaca [jdk]，然后重启每个已安装的运行时。JDK 8 使用 $JDK_HOME/jre/lib/security/cacerts；JDK 11+ 使用 $JDK_HOME/lib/security/cacerts。移除前测试合法证书链，之后监控失败，并单独检查应用专用信任库。指南也列出吊销检查选项和验证工具。

10 月 28 日更新： Google 的 10 月 27 日公告区分托管服务更新与客户控制的信任库、自定义镜像及内置客户端。按服务核对具体指导；受影响产品清单不能证明 Cloud 后端遭入侵。既有运行时、SDK 及证书替换措施仍然适用。

10 月 29 日更新： eMudhra 在 10 月 28 日更新中称，受影响 G3 层级下约 30,800 张证书属于一个美国客户生态，现已使用其 G1 RSA 签发路径。公司计划在该生态完成迁移后停止经 G1 签发 TLS 证书，但没有确定日期。该厂商迁移数量不能证明八张弱密钥中间证书签发过证书，也不能证明在野利用。G1 不能保证未来继续受浏览器信任；上文的证书替换和信任库更新仍须完成。

10 月 29 日进一步更新： Checkmk 为同一 CA 信任事件分配 CVE-2026-117611（CVSS 4.0 为 7.1）。HTTP 检查始终使用内置根证书，系统 CA 开关不能绕过这一暴露。内置 Python 信任库影响 Pro/Ultimate/Cloud 版 Linux Agent 更新器、Windows Python 插件，以及从站点环境之外启动且 SSL_CERT_FILE 和 REQUESTS_CA_BUNDLE 均未设置的进程。通过 omd start 或站点 Shell 启动的进程则使用站点 CA 文件。分别更新相关证书包及系统、站点信任库。在当时的10月29日更新中，2.5.0p18 尚未发布，不能将已公布目标视为已安装的修复。这次补充产品处置措施，不代表已发现利用。

11 月 1 日补充： PyPA 的 10 月 21 日公告属于同一信任库事件，不是 PyPI 发布渠道另遭入侵。元数据将 1.14.2 列为受影响，而正文说早于 1.14.2；两者均指向 1.14.3。应更新 Action 本身，不能假定运行器的 CA 更新已经足够。该公告没有证实发布凭据遭窃。

11月2日更新： 厂商下载归档现已列出11月2日的 Checkmk 2.5.0p18，并提供各版本、平台的软件包元数据。Werk 22169 和 22623 将该版本列为内置 CA 信任库修复，不再带有此前的尚未发布标记。这取代先前的可用性警告，但仍须更新受影响站点和 Agent 组件，以及单独的系统、站点信任库；不是新的利用证据。

11月3日补充，追踪 11月2日官方更新： Google 的 GCP-2026-075 明确，Google Cloud SDK Libraries 通常不自带 CA，信任来自传输依赖、运行时或系统；Java google-api-client 2.9.2 之前是例外。对于 GoogleNetHttpTransport.newTrustedTransport()，2.9.0 之前使用内置信任库，2.9.0 与 2.9.1 在无法加载 JDK 信任库时回退使用它。直接调用传输构造器使用 JDK 信任库，需安装其厂商更新。不能只升级 Cloud SDK 就认定所有应用已修复。Python grpcio、Ruby grpc 和 PHP grpc/grpc 的内置库不读取系统根证书；已弃用的 Node grpc 和 .NET Grpc.Core 需要迁移。按新增清单更新实际依赖、核验三张根证书已移除，并重建、重新分发或部署。Google 再次表示 Cloud 基础设施未被入侵，遥测未发现针对 Cloud 工作负载的利用；这是同一 CA 事件的下游修复补充。

11 月 2 日网格处置指南： Google 的 GCP-2026-076 补充了上列三条集群内 Cloud Service Mesh 修补版本，托管部署无需客户操作。所链接的 Istio 公告区分了公有根证书信任与网格自行签发的 mTLS。较旧 1.29 分支更新了 CA 镜像，但 Go 1.25 没有密钥拒信修复回移。这仍是既有 CA 证书被攻破事件，并非网格签发密钥发生新的泄露。

11 月 4 日跟进 11 月 3 日发布的 GCP-2026-077： Apigee 出站 TLS 仍可能通过默认或客户自定义信任库接受被攻破的证书链。攻击者需要网络拦截位置及被信任的伪造链；公告不是 Apigee 遭入侵或已被利用的证据。X 和 Edge SaaS 默认库仍在滚动更新，各产品客户均须核查自定义 TrustStore。Hybrid 须在修补镜像发布后更新容器，仅更新宿主机 CA 不够；OPDK 须处置系统及 JVM 信任并重启服务。移除信任前先安排后端证书替换，避免中断合法目标连接。上列运行时、SDK、网格及证书替换措施仍须完成。

11 月 4 日 Chrome 策略： Root Program 对 emSign Root CA - G1 增加独立限制。最早 SCT 晚于 2026 年 11 月 16 日 23:59:59 UTC 的 TLS 服务器证书，将在 Chrome 153 及更高版本失去默认信任。截止点或之前的证书不受本项变更影响，这不是对其他信任检查的全面保证。计划配合 11 月 17 日 Chrome 158 Stable 实施，项目可能调整日期或提前收紧限制。平台、用户或企业显式信任可覆盖这些 SCT 限制。G1 策略决定不能证明另有密钥被盗、新伪造证书或实际拦截，也不取代现有 ECC G3 移除及运行时、SDK 更新。

11 月 5 日 gRPC 补充： Python 和 Ruby 公告现明确 1.82.3／1.83.2／1.84.1 三条补丁路径；先前只写 1.84.1 的描述应按发布线理解，PHP Composer 公告仍仅列 1.84.1。另补入 10 月 28 日的 Objective-C 公告，涵盖 gRPC CocoaPod 及通过 gRPC-ProtoRPC 引入的副本，须升级并重建、分发应用；它明确排除独立 Core／C++ CocoaPod 和 grpc-ios SPM 包，且不支持上述环境变量变通。没有新增 CA 失陷或在野攻击证据。

11 月 5 日颁发机构更新： eMudhra 报告，美国以外客户已迁往其他供应商，美国客户仍在迁移。其报告 Chrome／Mozilla 的 SCT 限制日期为 11 月 16 日，Apple 将于 11 月 30 日移除全部 G1 证书信任，包括较早签发的证书。这是颁发机构对时间表的说明；独立核阅的 Chrome 精确规则仍见上文。不能据此认定美国已迁移完成或较早证书仍普遍受信任。

11 月 6 日旧线覆盖修正： 11 月 5 日发布的 1.78.2 和 1.80.1 也修复了内置根证书库。Python 和 Ruby 公告现列出五条补丁路径。选择安装发布线对应的补丁，或迁移至 1.84.1 及更高版本；1.81.x 须使用 1.82.3 路径。这是对先前三版本指引的扩充，不改变 PHP Composer 或 Objective-C 的最低版本。仍须核验显式、自定义根证书，并重建或重启受影响应用。这不代表又发生 CA 失陷或新增在野利用。

SonicOS 信任库跟进： 11 月发布说明确认 Gen7 7.3.4-7015（GEN7-59578）和 Gen8 8.2.3-8015（GEN8-19795）均从信任库移除 eMudhra 链。这是具体产品的处置，不是新的 CA 事件，也不能证明所有 SonicWall 版本均已移除该链。两份发布说明都只给出月份，不推断准确发布日期。原有浏览器、运行时期限及证书更换要求仍适用。

Rundeck 部署补充： 厂商 10 月 23 日公告说明了 10 月 22 日发布的 6.3.0 官方 Docker 镜像对同一 CA 事件的修复。这里补上此前遗漏的下游处置路径，不是新的 CA 事件。SaaS 不受影响，主机管理的系统及 Java 信任库、容器化 Runner 则须按实际部署分别处理。curl 拒绝证书不能证明 Java 的独立信任库也已更新。

11 月 6 日 New Relic 下游公告： NR26-12 要求手动拉取并重新部署上方四项 Private location 镜像，随后重启容器；Private location 镜像不会自动更新。Public location 使用 Node 22 的 Scripted API、浏览器运行时及 ping 监测，其基础设施镜像已修补，针对本 CA 问题无需操作；固定在 Node 16.10 的监测属于例外，两种位置均须迁移。所列 22.23.0 是 New Relic 的 Synthetics 迁移运行时，不替代另一篇 10 月 Node 发布事件中的独立 Node 安全版本下限。应在 11 月 18 日停止支持及计划 Public 自动迁移前测试。New Relic 称未发现合成监测镜像篡改证据，仅在有具体理由怀疑网络或基础设施失陷时要求轮换 secure credentials。