以事件响应速度修补Java：eMudhra CA泄露事件的教训

浏览器在3小时内完成了修补。你的 Java 环境修补了吗？

10月17日周五傍晚，一名研究人员通过用八个 eMudhra 中间证书颁发机构各自的私钥签署同一条短消息——“我们这里有问题。”——证明自己控制了这八个机构的私钥。

Mozilla 于 UTC 20:06 收到报告，到 UTC 22:59，Firefox 已阻止这些证书。Chrome 当天即阻止。Apple 于19日跟进，Microsoft 于20日跟进。

浏览器有一种自动化方式来停止信任某个证书颁发机构，而它们在数小时内就使用了这种方式。但你的数据中心和云中运行的成千上万个 Java 应用呢？

[LOADING...]

2026年10月17日—24日 eMudhra CA 被攻破事件响应时间线

eMudhra 如何影响 Java

默认情况下，Java 既不依赖浏览器的信任决策，也不依赖操作系统的信任决策。每个 JDK 都自带独立的信任库（cacerts），每个打包了 JDK 的容器镜像也都自带一份副本。给操作系统打补丁或重启浏览器都不会改变它们。

在每一个运行时都更新之前，任何能够插入服务与目标之间通信的人，都能诱骗发起出站 TLS 调用（访问支付处理商、合作伙伴 API、SaaS 平台等）的服务去信任伪造证书。

而它恰好发生在10月季度更新的同一周：53个 OpenJDK CVE，这是十多年来单次季度发布中数量最多的一次。

[LOADING...]

浏览器的修复并不会到达你的 JVM

我从客户那里听到的情况

我每周都会与北美各地的企业 Java 团队交流。大多数团队都无法在少于数周的时间内将 JDK 更新投入生产，而最大的原因在于更新里包含的内容。

典型的 JDK 版本会把安全修复与缺陷修复、性能变更和行为变更打包在一起。其中每一项都需要重新测试，因此每次更新都会触发一轮完整的回归测试。团队无法只取急需的修复，而不一并接受随之而来的所有内容。

围绕这一点，同样的缺口反复出现：

• 他们无法有把握地说出每个 JVM 运行在哪里、是什么版本和供应商，以及由谁负责。
• 变更窗口是每月或每季度一次，而“紧急”通道靠的是一通跨团队电话和大量人情。
• 容器镜像只有在应用团队发布功能时才会重建。

结果就是：一个数小时内就存在的修复，要花数周、有时整整一个季度才能到达生产环境。真正的风险正藏在这个缺口之中。

随后，第一个修复被证明还不够

10月24日周六，第二个严重漏洞 CVE-2026-114820（CVSS 9.1）表明，整个行业在周三发布的证书阻止列表——也包括我们发布的——并未完全堵住漏洞。现在的修复会从 Java 信任库中彻底移除受影响的 eMudhra 相关根证书。每个 Java 运行时都需要再次更新，包括那些已经应用了周三更新的运行时。

这是四天内的两次紧急运行时更新，再加上一次创纪录的季度发布。对于一个最快也要数周才能进入生产环境的团队来说，这已经算不上补丁计划，而是一份积压清单。

补丁的类型决定你移动的速度

当一次更新只包含安全修复时，你需要验证的变更很小。测试周期会大幅缩短，补丁可以在几天内而非一个季度内从构建进入生产。

当修复无法等待下一次计划发布时，这一点更加重要。像 eMudhra 这样的事件需要带外的、仅含安全修复的更新，而且你能够确信它不会改变其他任何内容。

这会变得更快，也会更频繁

数据指向同一个方向。Rapid7 的《2026年全球威胁态势报告》发现，被利用的高危和严重漏洞数量同比增长超过一倍（增长105%），从披露到被纳入 CISA 已知被利用漏洞目录的中位时间从8.5天降至5天。而像 CA 被攻破这样的事件不会等待你的下一个维护窗口。

季度修补曾经是计划，现在只是最低要求。

[LOADING...]

补丁窗口正在收缩

建立快速防御方法

那些从容应对这一周的团队，在事件开始之前就已经具备了五项能力：

1. 知悉： 对每个 JVM、版本、供应商和信任库建立实时清单，包括容器内的 JVM。
2. 研判： 一条明确的流程，用于在数小时内判断问题是否影响你以及紧急程度。
3. 最小化： 仅含安全修复的补丁，包括带外修复，使每次更新尽可能少地改变内容，并让测试保持聚焦。
4. 证明： 自动化回归测试，能够在一天内验证一次运行时更新。
5. 交付： 一条流水线，能够将新运行时（及其信任库）滚动部署到整个机群，并支持回滚。

这些都不新奇，但必须在事件发生之前就存在。

[LOADING...]

把数周缩短到数小时的五项能力

这就是我们在 Azul 建立的模式。10月20日，我们仅含安全修复的关键补丁更新修复了全部53个 CVE，且没有无关代码变更。10月21日，我们在披露后不到24小时内发布了带外更新，阻止全部八个 eMudhra 中间证书。10月24日，当 CVE-2026-114820 表明阻止列表还不够时，我们的团队通宵工作：从决定重新构建到仅含安全修复的构建版本交到客户手中，大约用了12小时。由于每次更新只包含安全修复，客户的测试负担只是完整 JDK 升级的一小部分。

其余部分——清单、研判和流水线——正是我现在最想与 Java 团队讨论的话题。

那么，问你一个问题：如果你信任的某个证书颁发机构明天早上被攻破，你需要多久才能让你环境中的每个 Java 服务都不再信任它？

来源

• eMudhra 证书颁发机构被攻破，触发浏览器紧急行动（Cybersecurity News）
• 8个 eMudhra 证书已被攻破。以下是你需要知道的内容（Cloudflare）
• 保护 Chrome 和 Android 用户免受被攻破的 eMudhra 中间 CA 证书影响（Google）
• OpenJDK 漏洞公告：2026/10/20
• Rapid7 2026年全球威胁态势报告
• CVE-2026-114820（CVE.org）
• Azul Core 发布说明## 常见问题

1. 如果浏览器在数小时内就阻止了受入侵的 eMudhra CA，为什么 Java 应用仍面临风险？

Java 不依赖浏览器或操作系统的信任决策。每个 JDK 都自带信任库（cacerts），而每个捆绑 JDK 的容器镜像也各带一份副本。在每一个运行时完成更新之前，向支付处理商、合作伙伴 API 或 SaaS 平台发起出站 TLS 调用的服务，都可能被位于其与目标之间的任何人诱骗，从而信任伪造证书。

2. 为什么 Java 修补需要数周甚至一整个季度，而仅包含安全修复的补丁为什么更快？

典型的 JDK 发行版会将安全修复与缺陷修复、性能变更和行为变更捆绑在一起。其中每一项都需要重新测试，因此每次更新都会触发完整的回归周期。仅包含安全修复的更新只更改安全修复，因此需要验证的变更很小。测试量大幅缩减，补丁可以在几天内而不是一个季度内从构建进入生产环境。这对于像 eMudhra 响应这样的带外修复最为重要，因为你需要一个可以信任、不会更改其他任何内容的更新。

3. 企业需要具备哪些能力，才能在数小时内响应 Java 安全事件？

需要在事件发生前具备五项能力：

• 知悉： 实时掌握每个 JVM、版本、供应商和信任库的清单，包括容器内的实例。
• 分诊： 有明确的流程，在数小时内判断问题是否影响你以及有多紧急。
• 最小化： 使用仅包含安全修复的补丁，包括带外修复，使测试保持聚焦。
• 验证： 通过自动化回归在一天内认证运行时更新。
• 交付： 有一条流水线，可以将新的运行时及其信任库滚动部署到整个机群，并能回滚。

这一点之所以重要，是因为节奏正在加快。Rapid7 的《2026 年全球威胁态势报告》发现，遭到利用的高危和严重漏洞数量上升了 105%，而漏洞被纳入 CISA KEV 的中位时间从 8.5 天降至 5 天。