適用對象：使用 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 版本、多種安裝方式與多個虛擬環境，各自都有獨立的清單。
| 環境 | 攜帶舊清單的部分 | 應採取的措施 |
|---|---|---|
| 任何使用 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 的安全公告升級至 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）需另外升級。若在安裝程式附帶的 certifi 上執行 pip install --upgrade 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 所使用的 actions 與工具
用於發布至 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 中（例如 pip 25.0.1 搭配 certifi 2024.8.30）。根據交叉簽署的 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 內建的清單在 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 Root Store 中的其他憑證階層（不同根憑證之下）取得新的 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 and 3.13.17 are out〉（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〉（首次發布於 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？