适用对象：使用pip、uv、conda或pixi安装软件包的任何人，运行使用requests等库进行HTTPS调用的程序的任何人，以及维护Python Docker镜像或CI的任何人。
本文基于Python项目（CPython和pip开发者）、certifi、uv和conda项目、Mozilla、Google、eMudhra以及Linux发行版的官方声明。本文不涉及任何攻击方法，也不涉及密钥如何被还原。社交媒体将此事件称为“Python安全紧急事件”，但在Python本身中并未发现代码执行漏洞。
続報待ち：この記事は公式発表に合わせて更新します
2026年10月24日（日本时间）まだ分かっていないこと
- CPython的ssl模块是否会拒绝受损中间密钥（该变更正在审查中，尚未合并）
- Python 3.11和3.12及其Docker官方镜像将如何处理旧版pip（发布负责人计划回移ssl模块变更以拦截受损中间证书，而不是升级pip；截至10月24日尚未合并）
- eMudhra的最终根本原因报告
- Chrome的根证书移除，计划于10月27日（太平洋时间）进行
Python项目于10月20日发布了通知，并于10月21日发布了Python 3.15.1、3.14.9和3.13.17。Chrome和Firefox于10月17日拦截了受影响的中间证书。目前尚无利用此漏洞的公告。一旦确认关于3.11和3.12的决定以及任何进一步的CPython变更，我们将予以补充。
我是否受影响？按环境快速查看表
是否受影响取决于您的Python环境中哪一部分包含CA列表。一台机器上可能同时存在针对每个Python版本、每种Python安装方式以及每个虚拟环境的独立列表。
| 环境 | 携带旧列表的部分 | 需要做什么 |
|---|---|---|
| 任何使用pip的环境 | pip内置的certifi（操作系统修复后仍然存在） | 将pip升级到26.2.2+ |
| 配置为使用独立certifi的程序，如requests | 独立的certifi软件包 | 将certifi升级到2026.10.19+ |
| 使用uv的环境 | uv内置的CA列表 | 将uv升级到0.13.4+ |
| conda、Mamba、pixi | 各工具以及certifi和ca-certificates软件包 | 升级到conda 26.9.4+和pixi 0.82.1+，并在环境中升级certifi和ca-certificates |
| 来自python.org macOS安装程序的Python | 安装程序自带的certifi | 按照官方公告升级pip和certifi；在3.13+上切换到修复后的Python |
| Docker镜像和CI | 构建时存在的pip、certifi和操作系统证书包 | 不使用缓存重建 |
| 通过Linux软件包（apt、dnf）安装的pip或certifi | 操作系统的ca-certificates（Debian会修补pip以使用它） | 将ca-certificates更新到修复版本 |
直接使用urllib3时，默认使用系统CA存储。请更新该存储；如果您的配置明确使用certifi或其他证书包，也请更新该证书包（urllib3证书验证指南 ）。
发生了什么（来自官方声明）
- 报告
- 2026年10月17日，一名安全研究人员向Apple、Google、Microsoft和Mozilla的根证书计划以及eMudhra报告，八个eMudhra中间证书的私钥可以被还原
- 范围
- 八个中间证书。其中六个用于TLS（HTTPS），并被Chrome、Mozilla、Microsoft和Apple信任；两个用于代码签名。所有证书均于2025年4月30日的密钥生成仪式中创建。六个TLS中间证书链接到根证书emSign ECC Root CA - G3（两个代码签名证书位于另一根证书之下）
- 原因
- Google表示，私钥是在随机性不足的情况下生成的。Mozilla表示其已独立还原了这些密钥，并确认密钥生成存在缺陷。eMudhra表示，仪式中的某一步骤在强密钥之外又产生了一组弱密钥，而实际使用的正是这些弱密钥。完整的根本原因仍在调查中
- 密钥可用于
- Mozilla表示，这些密钥可用于为持有者不控制的网站签发欺诈性HTTPS证书。能够拦截用户连接的攻击者可借此冒充网站，并可能读取或修改流量
- eMudhra的回应
- 10月18日吊销了全部八个证书。其表示，其中七个从未用于生产环境，而被用于生产的那一个并未签发任何证书。10月20日，其停止了该根证书下的签发，并于10月22日宣布将退出全球SSL/TLS证书业务
- 浏览器
- Chrome于10月17日通过CRLSet拦截了这些密钥。Firefox同日通过OneCRL将其拦截，并于10月20日发布了Firefox 158.0.1及ESR更新。10月20日，Mozilla决定紧急移除该根证书，并已将其从NSS 3.131.1中移除。Chrome将于10月27日（太平洋时间）移除该证书
- Python项目
- 他们于10月20日发布通知（10月22日更新），要求用户至少升级到certifi 2026.10.19、pip 26.2.2、uv 0.13.4、sigstore 4.5.1、conda 26.9.4和pixi 0.82.1，并在禁用层缓存的情况下重建容器镜像。10月21日，他们发布了捆绑pip 26.2.2的Python 3.15.1、3.14.9和3.13.17
certifi是广泛使用的Python软件包，其中保存了受信任证书颁发机构的列表。该列表源自Mozilla的列表，requests和pip使用它来判断服务器证书是否真实。certifi 2026.10.18（2026年10月18日发布，UTC时间）移除了所有emSign根证书，而2026.10.19（2026年10月20日发布，UTC时间）恢复了未受影响的emSign根证书。certifi官方公告将2026.10.18列为已修复版本，但GitHub Advisory Database条目和Python项目建议使用2026.10.19或更高版本，以兼容未受影响的emSign根证书。certifi 2026.10.23随后按照Mozilla的做法又移除了两个emSign根证书（eMudhra表示，该移除早前已计划，与本事件无关）。
问题有多严重？
Chrome、Firefox
10月17日已拦截。同时拒绝未出现在公共CT日志中的证书
26.2.2之前的pip
即使操作系统已修复，仍始终读取其内置certifi
requests及其他基于certifi的客户端
使用2026.10.19之前的独立certifi
0.13.4之前的uv、Docker镜像
保留构建时的列表
浏览器受到两方面的保护：它们会自动接收证书拦截信息，并且会拒绝不在公共证书透明度（CT）日志中的证书。Google表示，在其拦截之前，没有链接到受影响中间证书的TLS证书被记录到CT中，因此没有任何伪造证书可被用于对强制执行CT的客户端进行攻击。
pip和requests两种机制都不使用。它们仅依据自身携带的CA列表进行判断，因此如果该列表过旧，它们就会将伪造证书视为真实证书予以接受。
可能发生的情况
- 位于网络路径上的攻击者将访问PyPI、python.org等站点的连接重定向到伪造服务器
- pip install安装了被篡改的软件包
- 通过requests发送的API密钥或密码被读取
攻击者需要什么，以及我们所知的情况
- 攻击者必须能够位于您的网络路径上（同一Wi-Fi、被入侵的路由器、企业代理等）
- Python本身不存在代码执行漏洞
- 截至10月24日，尚无利用此漏洞的公告
请不要掉以轻心。Mozilla于10月20日表示，多人已独立还原了这些密钥，其中一些人已公开披露，因此制作伪造证书并不困难。请避免在任何有人可能进入网络路径的地方运行旧版pip，例如公共Wi-Fi、共享网络或CI运行器周围的网络。我们关于公共Wi-Fi风险的指南涵盖了这方面的内容。
首先，检查您的版本
检查pip版本
使用您要检查的Python运行以下命令（如果使用虚拟环境，则在虚拟环境内运行）。版本26.2.2或更高版本即为已修复。
python -m pip --version单独运行pip可能会指向另一个Python的pip。请使用python -m pip，以确保您检查的是正确的Python。
检查certifi版本
这将显示requests及类似库所使用的独立certifi。版本2026.10.19或更高版本即为已修复。如果未安装，pip会打印“未找到”警告。
python -m pip show certifipip内置的certifi是一个独立副本。运行python -m pip debug，并在“vendored library versions”下查找certifi==行。升级到pip 26.2.2后，该行应显示2026.10.19。
检查uv和conda
运行uv --version（0.13.4+为已修复）、conda --version（26.9.4+）和pixi --version（0.82.1+）。
列出Python的所有安装位置
一台机器上通常同时存在操作系统自带的Python、python.org安装的Python、来自Homebrew或pyenv的Python，以及各项目的虚拟环境（如.venv）。虚拟环境是任何包含pyvenv.cfg文件的目录。先把完整清单写下来，可以大大降低遗漏的可能。
按安全顺序升级
顺序很重要。旧版pip会信任受影响的证书，因此如果它直接下载新版pip，而该下载被拦截，就可能安装一个伪造的pip。Python项目建议使用带固定文件哈希（文件内容的指纹）的方式安装pip，然后用该pip完成其他所有操作。
使用固定哈希将pip升级到26.2.2
官方公告和Python博客提供了包含pip 26.2.2文件URL及其SHA-256哈希的命令。其格式如下。请从官方公告中准确复制URL和哈希（我们有意不在此处重复它们）。
python -m pip install "pip @ <官方公告中的URL>#sha256=<官方公告中的哈希>"使用固定哈希后，若文件内容不同，pip会拒绝安装，因此被拦截的下载无法安装伪造的pip。官方公告表示，浏览器应已更新其证书存储，可用于核对。例如，您可以打开PyPI上的pip 26.2.2文件页面，确认其中显示的哈希与之相符。
使用新版pip升级certifi和uv
pip升级到26.2.2后，用它来升级certifi。如果您是通过pip安装的uv，也请在此一并升级。
python -m pip install --upgrade certifi
python -m pip install --upgrade uv如果您是通过uv的独立安装程序安装的uv，请遵循uv的公告，升级到0.13.4或更高版本。公告指出，如果您将uv切换为使用系统证书，必须先确认操作系统已移除受影响的根证书或中间证书。
在每个虚拟环境中重复操作
pip和certifi位于每个虚拟环境内部。Python项目要求用户在系统上所有现有虚拟环境中升级pip和uv。对于您不再使用的旧环境，重新创建或删除它们可能更快。
将3.13至3.15迁移到修复版本；在3.11和3.12上，每次创建新venv时升级pip
Python 3.15.1、3.14.9和3.13.17捆绑了pip 26.2.2，因此使用python -m venv创建的新环境也会获得修复版pip。
Python项目表示，由于兼容性风险，不会再发布捆绑更新版pip的3.11或3.12版本。每次创建虚拟环境时，请首先升级pip。pip 26.2.2支持Python 3.10及更高版本。在3.9及更早版本上无法使用修复版pip，因此请升级Python本身（3.10也已达到生命周期终点）。
对于python.org的macOS版Python，使用该解释器进行升级
来自python.org macOS安装程序的Python自带certifi。博客列出了3.13、3.14和3.15（官方公告以3.15为例）的命令，直接调用该解释器，例如/Library/Frameworks/Python.framework/Versions/3.15/bin/python3.15，以升级pip和certifi。自由线程构建版本（如python3.15t）需要单独升级。如果pip install --upgrade certifi在安装程序自带的certifi上失败，官方公告建议使用--ignore-installed --no-deps certifi重新安装。
Docker、CI和锁文件
这是最常被遗漏修复的环节。修复笔记本电脑对镜像和CI运行器毫无作用，因为它们保留的是构建时的旧列表。
不使用缓存重建Docker镜像
Python项目要求您在禁用层缓存的情况下重建容器镜像，以便获取最新的操作系统证书。同时请重新拉取基础镜像，例如使用docker build --pull --no-cache。重建后，在容器内运行python -m pip --version进行确认。
10月21日，Docker官方镜像已将其3.13及更高版本的定义更新为修复版Python（3.15.1、3.14.9和3.13.17）。镜像维护者表示，除非Python发布新版本，否则他们不会在3.11和3.12标签中升级pip。如果您使用3.11或3.12镜像，请在Dockerfile中使用固定哈希将pip升级到26.2.2。
提高requirements和锁文件中的certifi版本固定值
在requirements.txt或constraints.txt中固定的certifi==2025.x.x会直接把旧版certifi重新引入。uv.lock、poetry.lock、pylock.toml和Pipfile.lock中的情况同样如此。请将certifi提高到2026.10.19或更高版本，重新生成锁文件，并将其部署到您的镜像和CI中。
将certifi和pip从依赖冷却期中豁免
如果您使用的设置会在接受新发布版本前等待一段固定时间（依赖冷却期），修复版本将要等到该期限结束后才会生效。一位Python打包维护者警告，使用冷却期的用户在更新之前会一直处于风险之中。请将certifi、pip和uv从该设置中豁免。
升级CI使用的操作和工具
用于向PyPI发布的pypa/gh-action-pypi-publish GitHub Action已有修复版本v1.14.3。对于cibuildwheel，请升级到v4.3.4或更高版本（v4.3.3带来了修复；v4.3.4还覆盖了Python 3.9及其他目标上的pip）。请检查您的CI配置是否固定了较旧的版本。
注意由其他CA交叉签名的副本
部分受影响的中间证书还存在由另一证书颁发机构交叉签名的副本。交叉签名使同一中间密钥可在另一根证书之下被信任。一位CPython核心开发者表示，用于该交叉签名的根证书存在于2025年4月之前发布的certifi版本中，以及捆绑这些版本的旧版pip中（例如，附带certifi 2024.8.30的pip 25.0.1）。据交叉签名CA称，该根证书已从Chrome和Mozilla的证书存储中移除，但截至10月18日仍被Microsoft和Apple信任（Mozilla记录）。Debian以及Ubuntu 14.04至20.04（USN-8944-2）也与emSign根证书一同移除了该交叉签名根证书。该交叉签名CA表示已于10月19日吊销了交叉签名副本，但浏览器之外的大多数客户端并不检查吊销状态。仅从旧证书包中删除emSign根证书是不够的，因为交叉签名根证书仍会保留。请升级到certifi 2026.10.19或更高版本（2025年4月以后发布的certifi版本已不再包含该交叉签名根证书）。
更新操作系统证书（ca-certificates）
在Linux上，ca-certificates软件包保存着系统CA列表。curl以及通过操作系统软件包安装的Python都会使用它。
| 发行版 | 官方通告 | 修复版本 |
|---|---|---|
| Debian 13（trixie） | DSA-6572-1（10月20日） | ca-certificates 20250419+deb13u1 |
| Debian 12（bookworm） | DLA-4845-1 | ca-certificates 20250419~deb12u2 |
| Ubuntu 26.10、26.04、24.04、22.04 | USN-8944-1（10月20日） | ca-certificates 20260816ubuntu0.(release) |
| Ubuntu 20.04、18.04、16.04、14.04 | USN-8944-2（10月20日） | 通过Ubuntu Pro（ESM）提供 |
Debian的修复移除了emSign ECC Root CA - G3和交叉签名根证书。Ubuntu的USN-8944-1移除了emSign ECC Root CA - G3，并在22.04至26.04上将列表刷新为Mozilla证书包2.90版；USN-8944-2则在14.04至20.04上移除了这两个根证书。从Debian自有软件包（python3-pip）安装的pip已被修补，改为读取操作系统列表而非内置certifi，因此更新ca-certificates即可修复。在Windows和macOS上，请安装操作系统更新。
如何确认已完成
在所有位置检查三个版本
在您的电脑、每个虚拟环境、每个Docker镜像以及CI中，确认pip 26.2.2+、certifi 2026.10.19+和uv 0.13.4+。只要还剩下任何一个旧副本，就说明尚未完成。
确认certifi列表中已不含受影响的根证书
python -m certifi会输出certifi证书包文件的路径。如果该文件中已不再出现“emSign ECC Root CA - G3”这一名称，则列表已修复。
grep -c "emSign ECC Root CA - G3" "$(python -m certifi)"输出0表示该证书已移除。对于Debian或Ubuntu打包的certifi，该文件中没有证书名称，因此0并不能证明任何问题；请改为检查ca-certificates版本。一旦pip为26.2.2或更高版本，其内置列表即已修复。
检查版本固定和操作系统
搜索您的requirements文件和锁文件中的certifi，确保没有固定低于2026.10.19的版本。在Linux上，请确认ca-certificates的版本不低于上表中的修复版本，例如使用apt policy ca-certificates进行检查。
本站观点：保护浏览器并不能保护其他一切
浏览器用户无需任何操作，便在数小时内得到了保护，因为浏览器会自动接收拦截信息，并拒绝不在CT日志中的证书。pip、requests和CI镜像两者都不具备这些机制。它们各自保存着一份CA列表副本，所有者必须逐一更新每一份副本。副本的数量与虚拟环境和镜像的数量相同。
养成一个习惯，也有助于应对下一次类似事件：在requirements中保留软件包哈希（--require-hashes）。如果哈希保存在您自己的文件中，被拦截的下载就无法替换为内容不同的软件包。关于依赖项的固定和检查，请参阅使用OSV-Scanner审计依赖项；关于分发渠道本身遭到攻击的案例，请参阅LiteLLM 1.107.0恶意软件事件。
致网站运营者
Chrome将于10月27日（太平洋时间）停止信任emSign ECC Root CA - G3。Google要求证书链接到该根证书的运营者立即从Chrome根证书存储中的其他层级（不同根证书之下）获取新的TLS证书。如果您使用eMudhra证书，请查阅颁发机构的指导。
时间线
2025年4月30日
eMudhra在一次密钥生成仪式中创建了包括八个受影响证书在内的中间证书。2026年10月17日
一名安全研究人员报告这八个密钥可被还原。Chrome（CRLSet）和Firefox（OneCRL）当日将其拦截。10月18日
eMudhra吊销了八个中间证书。certifi 2026.10.18移除了所有emSign根证书。10月19日
交叉签名CA吊销了其交叉签名副本。10月20日
Mozilla决定紧急移除该根证书。certifi 2026.10.19、pip 26.2.2和uv 0.13.4发布，Python项目发布通知。Debian和Ubuntu更新了ca-certificates。Google宣布Chrome将于10月27日移除该根证书。10月21日
Python 3.15.1、3.14.9和3.13.17以及conda 26.9.4发布。Docker官方镜像将其3.13+定义更新为修复版Python。10月22日
eMudhra宣布将退出全球SSL/TLS证书业务。10月23日
certifi 2026.10.23按照Mozilla的做法又移除了两个emSign根证书。
来源（公开记录）
本文的事实来自以下公开来源。我们不转载密钥如何被还原的方法，也不提供任何可用于攻击的内容。
- Python项目，《Information for Python users regarding eMudhra / emSign CA certificate security incident》（2026年10月20日；后续帖子检查至10月24日）— discuss.python.org
- Python，《Python 3.15.1、3.14.9和3.13.17已发布》（2026年10月21日）— blog.python.org
- certifi安全公告（GHSA-6q48-6c7w-9gw2）— github.com / GitHub Advisory Database github.com
- certifi，《Remove emsign》（#437，2026年10月18日）— github.com / certifi发布历史 pypi.org
- pip更新日志（26.2.2：将certifi升级到2026.10.19）— pip.pypa.io
- uv安全公告（GHSA-hq85-5cpj-mr62）及0.13.4 — github.com
- conda，《Security updates for conda, Mamba, and Pixi》（2026年10月21日）— conda.org
- Google，《Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates》（2026年10月20日）— blog.google
- Mozilla，《Protecting Firefox users following the compromise of eMudhra intermediate certificates》（2026年10月20日）— blog.mozilla.org
- Mozilla事件记录（Bug 2083449：八个中间证书、吊销时间、根证书移除、交叉签名副本）— bugzilla.mozilla.org
- eMudhra，《eMudhra Statement on Recent Certificate Security Incident》（2026年10月20日首次发布，10月22日更新）— emudhra.com
- eMudhra，《eMudhra to exit global SSL/TLS certificate business》（2026年10月22日）— emudhra.com
- 关于eMudhra退出业务的报道（The Record，2026年10月22日）— therecord.media
- Debian，《DSA-6572-1 ca-certificates》（2026年10月20日）— lists.debian.org /《DLA-4845-1 ca-certificates》lists.debian.org
- Ubuntu，《USN-8944-1》和《USN-8944-2》ca-certificates（2026年10月20日）— ubuntu.com / ubuntu.com
- Docker官方镜像（python）问题，《These images ship vulnerable pip》（3.13+的修复，以及3.11和3.12的处理）— github.com
- CPython，《Distrust compromised eMudhra intermediate CA keys》（额外的ssl模块防御，截至10月24日尚未合并）— github.com
- Python版本状态 — devguide.python.org
更新记录
2026-10-24：首个版本，基于Python项目10月20日的通知及至10月23日的帖子、Python 3.15.1、3.14.9和3.13.17的发布、certifi、pip和uv的公告、Google、Mozilla和eMudhra的声明，以及Debian和Ubuntu的ca-certificates更新。待关于3.11和3.12的处理及任何进一步的CPython变更确定后，我们将更新本页面。
延伸阅读
- 依赖项审计：使用OSV-Scanner审计依赖项
- 针对分发渠道的攻击：LiteLLM 1.107.0恶意软件事件 / Trivy供应链入侵事件
- 漏洞公布时：CVE修复手册
- 网络路径上的冒充：公共Wi-Fi风险
- 术语：什么是公钥密码学？ / 什么是Let's Encrypt？