在大多数平台上，Go 语言（Go）会使用给定的系统根证书。但在某些较窄的场景下，系统信任库若未进一步操作可能不会更新。为防护仍可能受影响的少数情况，crypto/x509 中新增了一份拒绝名单：当调用 Verify 并传入任何已知且已不再被视为可信的中间证书时，将返回错误。
正文
CVE-2026-111943 详情
描述
在大多数平台上，Go 会使用给定的系统根证书。但在某些较特殊的情况下，如果不采取进一步措施，系统信任库可能不会更新。为了防范那些可能仍受影响的少数情况，crypto/x509 中增加了一个 denylist（拒绝列表），在调用 Verify 时若传入任何已知不再被视为可信的中间证书，就会返回错误。
NVD 的补充工作会参考公开信息来关联 CVSS 向量字符串。其他来源提供的 CVSS 信息也会一并显示。
CVSS 3.x 严重性和向量字符串：
NIST： NVD
Base Score： N/A（NVD 评估尚未提供）
公告、解决方案和工具参考
| URL | 来源 | | --- | --- | | http://www.openwall.com/lists/oss-security/2026/10/20/29 | CVE | | https://go.dev/cl/851047 | Go Project | | https://go.dev/issue/82345 | Go Project | | https://groups.google.com/g/golang-announce/c/66pojueaQek | Go Project | | https://pkg.go.dev/vuln/GO-2026-6809 | Go Project |
弱点枚举
| CWE-ID | CWE 名称 | 来源 | | --- | --- | --- |
受影响产品
来源：Go Project
| 供应商 | 产品 | 版本 | | --- | --- | --- | | Go standard library | crypto/x509 | 受影响：0 < 1.26.10 (semver)；受影响：1.27.0-0 < 1.27.3 (semver) |
变更历史
找到 2 条变更记录。
快速信息
CVE 字典条目：
CVE-2026-111943
NVD 发布日期：
2026 年 10 月 21 日
NVD 最后修改日期：
2026 年 10 月 22 日
来源：
Go Project
评论
社区普遍将 eMudhra 事件视为一次严重的 CA 信任事故，并围绕各系统、语言与打包二进制如何紧急剔除或屏蔽受影响证书展开讨论；主要分歧在于 Go 主动拦截坏证书是否必要，以及操作系统信任库已更新后为何仍有工具继续信任这些 CA。
认为 eMudhra 中间 CA 的私钥可被公开恢复，能伪造任意站点证书
- eMudhra 把八个中间签名密钥生成得极其糟糕，任何人都能从公开证书中反推出私钥，从而给银行、GitHub 或 PyPI 等任意站点签发看似有效的 HTTPS 证书并冒充。（高赞）
- 需要引用时，只用一句中文意译： > eMudhra 生成的八个中间签名密钥差到任何人都能从公开证书里恢复私钥，意味着可以为你的银行、GitHub 或 PyPI 铸造“合法”HTTPS 证书并冒充它。（@stikit）
认为 Go 更新只是主动拦截系统信任库中的坏证书，并非所有场景都靠它
- Go 会拒绝系统信任库中仍存在的受影响中间证书；若操作系统已移除或不信任这些 CA，这种拦截严格说并非必需，而本页主题正是 Go 的这一更新。（较多人）
- 需要引用时，只用一句中文意译： > 这个页面讲的是 Go 的更新，它会拒绝系统信任库中已经存在的坏证书。（@mort96）
认为把证书打进二进制的应用必须升级自身才能移除坏 CA
- uv、certifi 等把受影响的证书打包进了自己的二进制，因此紧急发版并升级是删除它们的唯一办法；Python 用户也需要单独跟进各自生态的步骤。（高赞）
- 需要引用时，只用一句中文意译： > uv、certifi 等之所以紧急发版，是因为它们把受影响的证书打进了二进制，只有升级才能移除。（@colinmarc）
认为多数 Linux 发行版只需更新 ca-certificates，并可用 curl 测试验证
- Gentoo、Slackware 等已通过更新 ca-certificates 包来移除或不信任这些 CA；更新后访问 eMudhra 的问题域名应出现证书验证失败，而不是成功连接，macOS 用户也可改用 Homebrew 证书包修复 curl。（较多人）
- 需要引用时，只用一句中文意译： > Gentoo 用户应升级 ca-certificates，用 curl 测试时应返回无法取得本地签发者证书的验证失败。（@keks24）
认为 RedHat 用户仍未拿到正式修复，只有临时变通
- RedHat 目前只提供了禁用两个用于签署 eMudhra 证书的 Comodo 根证书的变通方法，状态仍是进行中，尚未收到完整更新。（少数人）
- 需要引用时，只用一句中文意译： > RedHat 只给出禁用两个 Comodo 根证书的临时办法，正式更新仍在进行中。（@pelzatessa）
认为这是旧闻，且 NIST 页面和标题没说清影响范围
- eMudhra 事故此前已讨论，昨天已有相关 HN 帖子，因此对 NIST 是新闻、整体是旧闻；有人惊讶过了约 1.5 天才上 HN，也有人从 NIST 页面猜测似乎只影响 Go，因为标题完全没提。（较多人）
- 需要引用时，只用一句中文意译： > 这对 NIST 来说是新闻，但整体而言是早已发生的 eMudhra 事故。（@darkwater）
有价值的补充
- 系统“已修复”并不等于所有依赖库都同步：在 macOS 上，系统虽已移除或不信任这些 CA，但 rustls-platform-verifier 会遵守系统设置，而 rustls-webpki 仍会从系统信任库加载坏 CA，说明不同 TLS 实现读取信任状态的方式不一致。
- 验证结果具有反直觉的一面：更新并清理证书库后，再用 curl 访问 eMudhra 的问题测试域名时应当失败并返回证书验证错误；若仍能成功建立安全连接，反而说明坏 CA 还没被清干净。
- 除证书事故外，讨论中还提到 eMudhra 自身存在单因素 OTP 登录绕过问题，显示其整体安全实践受质疑。（@freakynit）
- 精巧类比： > 这就像池塘里的鱼造出了一条把自己的同类都吃掉的鲨鱼，却还自豪地宣布这条鲨鱼是鱼类进化的前沿成果。（@zkmon）