8 张 eMudhra 证书已被攻破，以下是需要了解的情况

2026 年 10 月 19 日约 17:00 UTC，Cloudflare 发现与八张 eMudhra 中间证书关联的私钥已遭泄露。这些证书被浏览器和操作系统广泛信任，Cloudflare 内部同样信任它们。由于密钥本身强度不足，攻击者可以为任意域名伪造证书，再用它冒充服务器，拦截或篡改流量。这是一起影响遍及整个互联网的严重安全事件。关于 SSL 证书的工作原理，以及它为何对互联网的运转如此关键，这里有更多信息。

我们第一时间优先修补 Cloudflare 内部的关键服务，以便在漏洞公开披露之前保护好客户。安全审查未发现该问题在 Cloudflare 服务上被实际利用。

我们已发布 Cloudflare One Clients（即 WARP 或 1.1.1.1 app）和 Cloudflare Tunnel（即 cloudflared）的更新，并在 CDN、Developer 和 Zero Trust 产品线部署了缓解措施。如果你通过 Gateway 使用 Cloudflare Zero Trust，且客户端为最新版本（见下文），你将自动受到保护。

我们的应对

我们优先更新了那些使用公开证书来认证远程端点的服务，包括连接源站的代理，以及调用外部 API 的应用。与此同时，我们更新了共享信任库、基础镜像和其他共享基础设施，为那些从这些来源继承证书信任的服务提供统一的缓解路径。更新之后，我们通过重新加载、重启和镜像部署使其生效。对于自带信任库或使用自定义信任库的应用，我们单独做了评估和更新。这些工作针对的是基于证书的认证，而非 TLS 加密算法本身的弱点。

Cloudflare 各团队目前正在推进进一步的修复。已有进展，但仍有大量工作要做。部分客户需要对自己运维的软件或信任配置采取行动，尤其是源站服务器上的配置。 建议采取的措施汇总如下。

客户应采取的措施

这些软件或服务的用户	客户应采取的操作
Cloudflare One/WARP	Cloudflare One Client：升级至 v2.5.6（Android）、v1.12.16（iOS）、Windows 桌面版（2026.8.2115.0）、macOS（2026.8.2115.0）、Linux（2026.8.2115.0）；1.1.1.1 应用：升级至 v6.38.10（Android）、v6.31.7（iOS）、Windows 桌面版（2026.8.2115.0）、macOS（2026.8.2115.0）、Linux（2026.8.2115.0）
Cloudflare Tunnel（cloudflared）	升级至 2026.10.2。容器部署需更新并重新部署修复后的镜像
客户自行配置的 TLS 客户端认证	检查并更新用于验证客户端证书的双向 TLS 信任存储或已上传的 CA
客户源站 TLS 服务器配置	如果你使用 Full (strict) 或 Strict 加密模式，请检查自定义源站证书和服务器配置。我们正在更新 Automatic SSL/TLS，以便在你仍在使用这些不受信任的证书时自动通知你——这类证书会导致服务中断。
Cloudflare Containers	使用 Cloudflare Containers（包括 Sandboxes）的客户，应检查容器镜像和应用依赖中受影响的证书信任存储，并根据所部署的镜像进行更新。客户也可以启用 HTTPS 出站拦截，让出站 HTTPS 请求经由 Cloudflare 转发，从而把远程服务器证书的验证从应用转移到 Cloudflare 托管的基础设施上。这样，Cloudflare 的信任存储缓解措施就能保护被拦截的连接。已启用该功能的容器已受到保护。

开发者指引

对开发者来说，要往 SDK 下面看。

API 客户端可能把证书验证交给 HTTP 库、语言运行时、操作系统，或一套自定义的信任配置。只更新 SDK 未必能改变底层策略。

打上补丁后，你可能会在仪表盘里看到证书错误。关键是，不要通过关闭验证来解决这些错误。 那样会移除这些更新本要恢复的认证保护。

这次事件波及许多依赖 WebPKI 做身份验证的软件栈。Mozilla 的 Dennis Jackson 众包整理了一份常用软件包清单，这些包都已修复。建议读者尽快升级。（注意，其中一些可能是你软件栈的间接依赖，所以要查看依赖树。）更新相关依赖、重新构建受影响的镜像，并确认应用是否需要重新加载、重启或重新部署。

Dennis Jackson 的测试站点提供浏览器检测、非浏览器环境的测试说明以及软件包更新信息。结果只对被测的那条验证路径成立，不代表设备上的每个应用都没问题。要通过应用实际的 TLS 路径来验证。浏览器测试通过，并不能证明后台服务也受到了保护；如果应用用的是另一个验证器，curl 测试同样说明不了问题。

时间线

截至目前的事件时间线如下。

日期与时间	事件
10 月 19 日约 17:00 UTC	Cloudflare 察觉入侵并开始评估。
10 月 20 日 02:00 UTC	Cloudflare One Client 与 WARP 应用的安全更新在各平台发布（iOS 上的 Cloudflare One Agent 除外，其应用审核仍在进行中）。
10 月 20 日 09:15 UTC	Cloudflare Tunnel（cloudflared）安全更新发布。
10 月 20 日 19:20 UTC	CDN 与服务端 Zero Trust 缓解措施全面部署完成。

展望

这次事件的影响并不均等。浏览器厂商只需拨一下开关就能修复问题。他们当然只有一个应用要更新，而不是几百个，但他们手里有一招好用的技巧：大多数浏览器都采用快速吊销机制（比如 Chrome CRLSets）。在 Cloudflare，我们的一些产品也用了这类机制。为了让 Cloudflare 内部和整个行业更多系统用上它，我们对 upki 这类项目很期待——它们明白，信任存储不能是一份静态的根证书颁发机构列表，而必须能快速更新吊销信息、证书透明度密钥等内容。