CVE-2026-111943：中间证书颁发机构遭入侵
eMudhra 运营的一个被攻破的中间证书颁发机构被发现使用了灾难性地弱的椭圆曲线密钥，攻击者可由公钥证书推导出私钥，并为任何域名伪造“有效”的 TLS 证书。操作系统、语言和工具正在争相吊销或加入黑名单来处理受影响的中间证书，尤其要关注那些软件自带信任存储的场景（如 Go 的 crypto/x509、Python 的 certifi、uv、容器和嵌入式设备），而不是完全依赖操作系统更新。评论者既讨论了如何测试客户端是否仍信任这些坏 CA，也指出了分散的信任存储管理和多层包管理如何让及时、全面的修复变得出人意料地困难。
事件性质
- eMudhra 生成了八个中间 CA 密钥，强度弱到可以从公钥证书推导出私钥。
- 任何持有这些密钥的人都可以为任意域名签发“有效”的 TLS 证书（银行、PyPI 等），从而实现中间人攻击。
- 多位发帖者链接到同一个说明网站和之前的 HN 线程；这个以 Go 为重点的 CVE 只是更大范围、仍在持续中的 eMudhra 事件的一部分。
Go 相关角度与信任存储
- 讨论集中在 Go 的
crypto/x509使用系统信任存储以及内部黑名单（denylist）。 - 这个 CVE 本质上是：某些 Go 版本缺少针对这些被入侵中间证书的更新黑名单条目。
- 已澄清：如果操作系统已经移除了这些证书，或者 Go 的黑名单已更新，Go 都会拒绝这些证书。
- 重要细节：二进制文件会静态嵌入 Go 的信任逻辑，因此必须使用更新的 Go 工具链重新构建/重新部署应用，才能受益。
操作系统与发行版响应
- 据称 Gentoo 和 Slackware 已更新；有人分享了具体的 Gentoo
emerge命令。 - macOS 看起来会在操作系统层面不信任这些证书，不过某些工具看到的信任视图不同。
- 对 Red Hat 的响应有批评，认为不完整且缓慢；目前只提到一种删除两个 Comodo 根证书的临时方案，并标记为“ongoing”。
- 有人进行对比：一些人更偏好 Debian，因为安全更新更快；另一些人仍然喜欢 RHEL 的整体补丁质量，但指出其长期存在延迟。
其他生态系统与工具
- Python、certifi、uv、bun、Java（AWS Corretto）以及其他栈可能内置自己的 CA 证书包，并需要显式更新。
- 文中引用了面向 Python 用户的单独指南；还指出 uv 自身有自己的信任存储。
- 浏览器通常有独立的 CRL，因此即使 CLI 工具（curl、wget）不安全，浏览器也可能仍然安全。
测试与本地缓解
- 共享了几个测试端点；正确结果应是 TLS 失败，并显示 “unable to get local issuer certificate”。
- 人们使用 curl 和 Python
urllib访问这些主机，以验证信任行为。 - 临时方案包括在 macOS 上将 curl 指向更新后的 Homebrew CA 证书包；也有人分享了在 Debian 上管理 CA 证书的脚本。
运维与元主题
- 许多人对多层包管理、容器以及分散的信任存储表示沮丧。
- 有人主张使用容器；也有人认为应更简单地采用基于主机的部署和 systemd 加固。
- 关于依赖 LLM/agent 自动打补丁存在争论：它们有助于扩大覆盖面，但也可能让操作员产生 complacency。
- 还简短讨论了术语（“monster-in-the-middle” vs “man-in-the-middle”）以及这件事传播得有多快，已经变成了“旧闻”。