対象：Pythonでpip・uv・conda・pixiを使ってパッケージを入れる人、requestsなどでHTTPSの通信をするプログラムを動かしている人、PythonのDockerイメージやCIを管理している人。
本記事は、Pythonのプロジェクト（CPythonとpipの開発者）、certifi・uv・condaの各プロジェクト、Mozilla、Google、eMudhra、Linuxの配布元の公式の発表にもとづく解説です。攻撃の手順や、鍵の割り出し方は扱いません。SNSでは「Pythonのセキュリティの緊急事態」と広まっていますが、Python本体にコードを実行される欠陥が見つかったわけではありません。
続報待ち：この記事は公式発表に合わせて更新します
2026年10月24日（日本時間）時点まだ分かっていないこと
- CPythonのsslモジュールに、問題の中間証明書の鍵を拒否する変更を入れるか（変更は準備中で、まだ取り込まれていない）
- Python 3.11・3.12とそのDocker公式イメージで、pipの問題をどう扱うか（リリースの担当者は、pipを上げる代わりに、問題の中間証明書を拒否するsslモジュールの変更を3.11・3.12にも取り込む方針。変更は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のどの部分が証明書の一覧を持っているか」で決まります。1台のPCでも、PythonのバージョンやPythonの入れ方、仮想環境ごとに別の一覧を持っています。
| 環境 | 何が古い一覧を持っているか | やること |
|---|---|---|
| pipを使うすべての環境 | pipに同梱されたcertifi（OSの証明書を直しても残る） | pipを26.2.2以上に上げる |
| requestsなど、単体のcertifiを証明書の一覧として使うプログラム | 単体で入れたcertifi | certifiを2026.10.19以上に上げる |
| uvを使う環境 | uvに組み込まれた証明書の一覧 | 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・OSの証明書 | キャッシュを使わずに作り直す |
| Linuxのパッケージ（apt・dnfなど）で入れたpip・certifi | OSのca-certificates（Debianはこれを使うよう変更している） | ca-certificatesを修正版に更新する |
urllib3を直接使う場合、既定ではOSの証明書の一覧を使います。OS側を更新し、certifiなど別の一覧を明示的に指定している場合は、その一覧も更新してください（urllib3公式の証明書検証の説明）。
何が起きたか（公式の発表より）
- 報告
- 2026年10月17日、あるセキュリティ研究者が、eMudhraの中間証明書8件の秘密鍵を割り出せると、Apple・Google・Microsoft・Mozillaのルート証明書の管理担当とeMudhraに報告した
- 対象
- 中間証明書8件。6件はTLS（HTTPS）用で、Chrome・Mozilla・Microsoft・Appleが信頼していた。2件はコード署名用。どれも2025年4月30日の鍵の生成の作業で作られた。TLS用の6件は、ルート証明書「emSign ECC Root CA - G3」につながる（コード署名用の2件は別のルート証明書の下）
- 原因
- Googleによれば、秘密鍵が十分な乱数を使わずに作られていた。Mozillaは独自に鍵を割り出せたとし、鍵の生成に欠陥があったと確認した。eMudhraは、鍵の生成の手順の1つで、本来の強い鍵とは別に弱い鍵ができ、その弱い鍵が使われたと説明している。根本の原因は調査中
- 何ができてしまうか
- Mozillaによれば、この鍵があれば、自分が管理していないWebサイトの名前で偽の証明書を作れる。利用者の通信の途中に入れる攻撃者は、それを使ってWebサイトになりすまし、通信を読んだり書き換えたりできるおそれがある
- eMudhraの対応
- 10月18日に8件を失効させた。うち7件は実際の発行に使っておらず、使っていた1件も証明書を発行していなかったとしている。10月20日にはこのルート証明書の下からの発行を止めた。10月22日、世界向けのSSL/TLS証明書の事業から撤退すると発表した
- ブラウザ
- Chromeは10月17日、配信の仕組み（CRLSet）で問題の鍵を遮断した。Firefoxも同日、失効の一覧（OneCRL）で遮断し、10月20日にFirefox 158.0.1などを出した。Mozillaは10月20日、ルート証明書の信頼を緊急で外すと決め、証明書の一覧（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は10月18日（UTC）公開の2026.10.18でemSignのルート証明書をすべて外し、10月20日（UTC）公開の2026.10.19で、問題のないemSignのルート証明書を戻しました。certifi自身の勧告は2026.10.18を修正版としていますが、GitHubの勧告データベースとPythonのプロジェクトは、問題のないemSignのルート証明書との互換性のため2026.10.19以上を推奨しています。10月23日の2026.10.23では、Mozillaにあわせて、さらにemSignのルート証明書2件を外しています（eMudhraは、この2件の削除は今回の件と関係なく、以前から予定していたものだとしています）。
どのくらい危ないか
Chrome・Firefox
10月17日に遮断済み。公開の記録に載らない証明書も受け付けない
pip（26.2.2より前）
同梱のcertifiを常に読む。OSを直しても残る
requestsなどcertifiを使う構成
単体のcertifi（2026.10.19より前）を使う
uv（0.13.4より前）・Dockerイメージ
作った時点の一覧のまま
ブラウザは、証明書の遮断を自動で受け取る仕組みと、公開の記録（証明書の透明性ログ）に載っていない証明書を受け付けない仕組みで守られています。Googleは、遮断より前に問題の中間証明書から出たTLSの証明書はこの記録に載っていなかったので、記録を確かめる相手には偽の証明書を使えなかったとしています。
pipやrequestsは、そのどちらの仕組みも使っていません。自分が持っている証明書の一覧だけで判断するので、一覧が古ければ偽の証明書を本物として受け入れます。
起こりうること
- 通信の途中に入れる攻撃者が、PyPIやpython.orgなどへの通信を偽のサーバーにつなぎ替える
- pip install で、改ざんしたパッケージを入れられる
- requestsなどで送ったAPIキーやパスワードを読まれる
攻撃に必要な条件・分かっていること
- 攻撃者は、あなたの通信の途中に入れる立場（同じWi-Fi、乗っ取られたルーター、社内のプロキシなど）にいる必要がある
- Python本体にコードを実行される欠陥があるわけではない
- 悪用が確認されたという発表は、10月24日時点で見当たらない
楽観はできません。Mozillaは10月20日、複数の人が独自に鍵を割り出し、一部の人はそのことを公表したとしています。つまり、偽の証明書を作ること自体は難しくない状態です。通信の途中に入る機会がある場所（公共のWi-Fi、共有のネットワーク、CIの実行環境の外側）で、古いpipを使い続けるのは避けてください。公共のWi-Fiの注意点は 公共Wi-Fiの危険性 で解説しています。
まず確かめる：バージョンの見方
pipのバージョンを確かめる
使っているPython（仮想環境に入っているならその環境）で、次のコマンドを実行します。26.2.2 以上なら修正版です。
python -m pip --versionpip コマンドを直接使うと、別のPythonのpipを見ていることがあります。python -m pip の形で、確かめたいPythonを指定してください。
certifiのバージョンを確かめる
単体で入れたcertifi（requestsなどが使うもの）のバージョンを見ます。2026.10.19 以上なら修正版です。入っていなければ「not found」という警告が出ます。
python -m pip show certifipipに同梱されたcertifiは、これとは別物です。python -m pip debug を実行すると、「vendored library versions」の欄に certifi== の行が出ます。pipを26.2.2に上げると、この欄は2026.10.19になります。
uvやcondaのバージョンを確かめる
uvは uv --version で、0.13.4以上なら修正版です。condaは conda --version で26.9.4以上、pixiは pixi --version で0.82.1以上かを見ます。
Pythonが何か所に入っているかを書き出す
1台のPCに、OSのPython、python.orgのPython、Homebrewやpyenvで入れたPython、プロジェクトごとの仮想環境（.venv など）が並んでいることはよくあります。仮想環境は pyvenv.cfg というファイルがある場所です。全部を書き出してから更新すると、漏れが出にくくなります。
更新の手順（安全な順番）
順番に意味があります。古いpipは問題の証明書を信頼しているので、その古いpipでpip自身を普通に取り直すと、取得の通信を横取りされたときに偽のpipが入るおそれがあります。Pythonのプロジェクトは、取得するファイルのハッシュ（中身の指紋）を指定してpipを入れ、そのpipで残りを更新する方法を案内しています。
pipを、ハッシュを指定して26.2.2に上げる
Pythonのプロジェクトの 公式の投稿 と 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になったら、そのpipでcertifiを上げます。uvをpipで入れている場合は、uvもここで上げます。
python -m pip install --upgrade certifi
python -m pip install --upgrade uvuvを単体のインストーラーで入れている場合は、uvのセキュリティ勧告にしたがって0.13.4以上に上げます。勧告は、OSの証明書を使う設定にする場合は、OSの側で問題のルート証明書が外れていることを確かめるよう求めています。
すべての仮想環境で同じことをする
pipとcertifiは仮想環境ごとに入っています。Pythonのプロジェクトは、システムにあるすべての既存の仮想環境で、pipとuvを最新に上げるよう求めています。使っていない古い仮想環境は、作り直すか削除するほうが早いこともあります。
Python 3.13〜3.15は修正版に、3.11・3.12は仮想環境を作るたびにpipを上げる
Python 3.15.1・3.14.9・3.13.17は、pip 26.2.2を同梱しています。これらに上げると、python -m venv で作る新しい仮想環境にも修正版のpipが入ります。
3.11と3.12には、新しいpipを同梱した版は出ないとPythonのプロジェクトは説明しています（互換性を壊すおそれがあるため）。仮想環境を作るたびに、最初にpipを上げてください。pip 26.2.2はPython 3.10以降に対応しています。3.9以前はpipの修正版が使えないので、Python自体を新しくしてください（3.10もサポートが終わっています）。
python.org のmacOS用Pythonは、そのPythonを指定して上げる
python.orgのmacOS用インストーラーのPythonにはcertifiが入っています。/Library/Frameworks/Python.framework/Versions/3.15/bin/python3.15 のように、そのPythonを直接指定してpipとcertifiを上げる手順を、ブログは3.13〜3.15ごとに、公式の投稿は3.15を例に載せています。フリースレッド版（python3.15t など）も別に上げます。インストーラーに入っているcertifiは pip install --upgrade certifi で上げられないことがあり、その場合、公式の投稿では --ignore-installed --no-deps certifi を付けて入れ直す方法が示されています。
Docker・CI・ロックファイル
ここが最も漏れやすいところです。手元のPCを直しても、イメージやCIは作った時点の古い一覧のまま動き続けます。
Dockerイメージはキャッシュを使わずに作り直す
Pythonのプロジェクトは、レイヤーのキャッシュを無効にしてイメージを作り直し、最新のOSの証明書を取り込むよう求めています。docker build --pull --no-cache のように、ベースイメージも取り直します。作り直したら、コンテナの中で python -m pip --version を実行して確かめます。
Docker公式イメージは10月21日、3.13以降の定義を修正版のPython（3.15.1・3.14.9・3.13.17）に更新しました。一方、Docker公式イメージの管理者は、3.11と3.12のタグはPythonのプロジェクトが新しい版を出さない限り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への公開に使うGitHub Actionsの pypa/gh-action-pypi-publish には、修正を入れたv1.14.3が出ています。ホイールのビルドに使うcibuildwheelは、v4.3.4以上に上げてください（v4.3.3で修正が入り、v4.3.4でPython 3.9のpipなども対象になった）。CIの設定でこれらを古い版に固定していないかを確かめてください。
別の認証局による「相互署名」の写しにも注意
問題の中間証明書の一部には、別の認証局が相互署名した写しがありました。相互署名とは、別のルート証明書の下からも同じ鍵の中間証明書を信頼させる仕組みです。Pythonのプロジェクトの開発者によれば、相互署名に使われたルート証明書は2025年4月より前のcertifiの一覧と、それを同梱した古いpip（例：pip 25.0.1に同梱のcertifi 2024.8.30）に入っています。相互署名した認証局によれば、このルート証明書はChromeとMozillaの一覧からは以前に外れていますが、MicrosoftとAppleの一覧では信頼が続いていました（10月18日時点、Mozillaの記録）。Debianと、Ubuntuの古い版（14.04〜20.04、USN-8944-2）は、今回の更新でemSignのルート証明書とあわせてこの相互署名のルート証明書も外しました。相互署名した認証局は、10月19日に写しの証明書を失効させたとしています。ただし、ブラウザ以外のプログラムの多くは失効の情報を確かめません。古い一覧からemSignのルート証明書だけを手で消しても、相互署名のルート証明書が残るので不十分です。certifi 2026.10.19以上に上げてください（2025年4月以降のcertifiには相互署名のルート証明書は入っていません）。
OSの証明書（ca-certificates）を更新する
Linuxでは、OSのca-certificatesのパッケージが証明書の一覧を持っています。curlやOSのパッケージで入れた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.（各版） |
| Ubuntu 20.04・18.04・16.04・14.04 | USN-8944-2（10月20日） | 拡張サポート（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のOSのパッケージで入れたpip（python3-pip）は、同梱のcertifiの代わりにOSの一覧を読むよう変更されているので、ca-certificatesの更新で直ります。WindowsとmacOSは、OSの更新を当ててください。
終わったかの確かめ方
すべての環境で、3つのバージョンを確かめる
PC、各仮想環境、各Dockerイメージ（コンテナの中）、CIで、pipが26.2.2以上、certifiが2026.10.19以上、uvが0.13.4以上かを確かめます。ひとつでも古いものが残っていれば、終わりではありません。
certifiの一覧から問題のルート証明書が消えたかを見る
certifiの一覧のファイルの場所は python -m certifi で分かります。そのファイルに「emSign ECC Root CA - G3」という名前が残っていなければ、修正版の一覧です。
grep -c "emSign ECC Root CA - G3" "$(python -m certifi)"0 と出れば消えています。Debian・UbuntuのOSのパッケージで入れたcertifiでは、このファイルに証明書の名前が書かれていないため0になります。ca-certificatesのバージョンで確かめてください。pipに同梱された一覧は、pipを26.2.2以上にしてあれば修正版です。
固定とOSを確かめる
requirements やロックファイルを certifi で検索し、2026.10.19より古い固定が残っていないかを見ます。LinuxではOSのca-certificatesが上の表の修正版以上かを、apt policy ca-certificates などで確かめます。
当サイトの視点：ブラウザが守られても、ブラウザ以外は守られない
今回、ブラウザの利用者は何もしなくても数時間で守られました。遮断の情報を自動で受け取り、公開の記録に載らない証明書を拒否する仕組みがあるからです。pipやrequests、CIのイメージにはそのどちらもなく、それぞれが持つ証明書の一覧の写しを、持ち主が1つずつ更新するしかありません。写しは仮想環境やイメージの数だけあります。
もう1つ、次の同種の事故に効く備えがあります。requirements にパッケージのハッシュを書いておく方法（--require-hashes）です。ハッシュが手元のファイルにあれば、取得の通信を横取りされても、中身の違うパッケージは入りません。依存の固定と点検の進め方は OSV-Scannerで依存関係を点検する、配布の仕組みが狙われた事案は LiteLLM 1.107.0のマルウェア混入 で解説しています。
Webサイトの運営者へ
Chromeは10月27日（米太平洋時間）に「emSign ECC Root CA - G3」の信頼を外します。Googleは、このルート証明書につながる証明書を使っているWebサイトの運営者に、Chromeが信頼する別の階層（別のルート証明書の下）の証明書に、すぐ取り替えるよう求めています。eMudhraの証明書を使っている場合は、発行元の案内を確かめてください。
これまでの経緯
2025年4月30日
eMudhraが、問題の8件を含む中間証明書を作る（鍵の生成の作業）。2026年10月17日
セキュリティ研究者が、8件の秘密鍵を割り出せると各社に報告。Chromeは配信の仕組みで、Firefoxは失効の一覧で、同日のうちに遮断した。10月18日
eMudhraが8件を失効させる。certifi 2026.10.18がemSignのルート証明書をすべて外す。10月19日
相互署名した認証局が、写しの証明書を失効させる。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証明書の事業からの撤退を発表（報道は日本時間23日）。10月23日
certifi 2026.10.23が、MozillaにあわせてさらにemSignのルート証明書2件を外す。
出典（公開記録）
本記事の事実関係は、以下の公開情報にもとづきます。鍵の割り出し方や、攻撃に使える情報は転載していません。
- 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の勧告データベース 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：対象の8件、失効の時刻、ルート証明書の信頼の削除、相互署名の扱い） — 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日〈日本時間23日〉） — 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）のissue「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のサプライチェーン侵害
- 脆弱性が公表されたとき：脆弱性が公表されたときの対応手順
- 通信の途中のなりすまし：公共Wi-Fiの危険性
- 用語：公開鍵暗号とは ／ Let's Encryptとは