Pythonが漏えいしたCA鍵を遮断｜pip更新と仮想環境の点検手順

Python開発チームは2026年10月26日、漏えいしたeMudhraの中間CA鍵を拒否する緊急セキュリティリリースを5系列向けに案内しました。PythonでWebアプリを動かす担当者だけでなく、pipで依存関係を取得するCI・ビルド環境の管理者も対象です。Python本体、仮想環境ごとのpip、証明書バンドルを分けて更新し、実際の実行経路に対策が届いたか確認してください。

新しい点は、証明書バンドル側の信頼削除に加え、Pythonのsslモジュールが問題の鍵を遮断する防御が提供されたことです。Python開発チーム：5系列の緊急セキュリティリリースは、通常のpip利用ではpip自身が未更新でも、この鍵を利用する攻撃から保護されると説明しています。ただし、pipやOSの更新を不要とする案内ではありません。

本稿は10月28日に一次資料を確認した更新情報と実践手順です。Python 3.15.2の個別配布ページのリリース日は10月25日、5系列をまとめた告知は26日であり、確認日とは区別します。以下の点検・更新手順は本サイトの提案で、実環境で攻撃や動作を再現した結果ではありません。

なりすましが問題になるのは外向きのTLS接続

Python公式：eMudhra／emSign問題に関する利用者向け案内は、影響する信頼情報が残るTLSクライアントでは、python.orgやpypi.orgへの接続も中間者攻撃の対象になり得ると注意しています。攻撃者が偽の証明書を利用し、通信経路へ介入できる条件が問題です。Pythonを使うだけで侵害が成立する、という意味ではありません。

Web運用では、利用者から自社サイトへのHTTPSと、サーバーやビルド環境から外部へ出るHTTPSを分けます。自社サイトの証明書が別のCA発行だから安全、と判断すると、パッケージ取得や外部API接続を見落とします。逆に、今回の発表だけで自社サイトの秘密鍵が漏れたと結論付けることもできません。

優先して確認したいのは、外部から依存パッケージを取得するCI、コンテナのビルダー、開発端末、定期バッチです。外部接続のある本番アプリも対象に加えます。公開資料は対策の必要性を説明するもので、本稿が読者環境の盗聴やパッケージ改変を観測したわけではありません。

利用系列を維持して修正版へ進む

公式告知が案内する更新先は下表です。3.15.2と3.14.10にはバイナリーインストーラーがあり、3.13.18、3.12.16、3.11.18はソースのみのセキュリティリリースです。Python公式：Python 3.15.2の配布と修正内容も、CVE-2026-115557を修正内容として掲載しています。

利用系列	今回案内された修正版	上流の提供形態
3.15	3.15.2	バイナリーとソース
3.14	3.14.10	バイナリーとソース
3.13	3.13.18	ソースのみ
3.12	3.12.16	ソースのみ
3.11	3.11.18	ソースのみ

CVE Program：CVE-2026-115557では、Python Software FoundationがCVSS 4.0を9.4（Critical）と評価しています。これは本稿の主題であるCPythonのCVEの値で、certifiやCA侵害全体へ流用する評価ではありません。レコードの初回公開日は10月24日、更新日は27日で、修正リリースや事案の発生日とは区別します。

OSやホスティングの配布物は、提供元の修正取り込み状況を確認して更新します。上流の版番号と一致しなくても修正が取り込まれる場合があるため、版だけで判定せず配布元の変更履歴も残します。システムが使うPythonを独断で別系列へ置き換える作業と、今回のセキュリティ更新は分けてください。

公式利用者向け案内は、Python 3.10以前をサポート終了として、セキュリティ修正の対象外としています。古い環境を使う場合は、更新可能な系列への移行を計画します。新しいpipだけを入れれば古いランタイムの保守問題も解消する、という扱いにはしません。

Python本体とcertifiの二つの防御を区別する

CPython：CVE-2026-115557の修正PRは、証明書チェーンに含まれる公開鍵の情報であるSPKIを照合し、問題の鍵を使うチェーンを拒否すると説明しています。同じ鍵を再利用するクロス署名証明書も対象にする設計です。証明書ファイルの名前だけを見て拒否対象を探す対策とは異なります。

これは信頼ストア更新の遅れを補う多層防御です。OSのCAストア、アプリに同梱されたcertifi、Pythonのssl実装は別々の管理対象です。ランタイム側の遮断が入っても、別のTLS実装を使うツールへ自動的に同じ対策が届くとは限りません。uvなどを併用する環境は、その提供元の案内に沿って別に確認します。

certifi：emSignルート証明書の信頼削除は、鍵の侵害を受けてemSignルート証明書の信頼を削除する修正を案内しています。一方、Pythonの利用者向け案内は、影響のないemSignルートとの互換性を考慮してcertifi 2026.10.19以降を推奨しています。古い勧告の最初の修正版だけを固定せず、現在の推奨を確認します。

pipの同梱バンドルを見落とさない

pip公式：26.2.2の変更履歴には、10月20日の26.2.2で同梱certifiを2026.10.19へ更新したと記されています。アプリが通常の依存関係として持つcertifiと、pipに同梱されたcertifiは同じ更新単位とは限りません。環境でcertifiを更新した記録だけで、pipの対応まで完了したと判断しないでください。

pip公式：HTTPS証明書の検証と信頼ストアは、既定ではシステムの証明書をcertifiに追加して利用すると説明しています。OSの信頼ストアだけを直す作業が、古いpipの同梱バンドルの更新を必ず代替するわけではありません。配布元による変更もあるため、対象のpipの配布形態と実行中の版を対応させて確認します。

まず、更新対象のアプリやCIが実際に呼ぶPythonを指定して点検します。次は対象環境のPythonで実行する読み取り例です。シェルで最初に見つかるpythonと、サービスの起動コマンドが使う実行ファイルが一致するとは限りません。

python -c "import sys, ssl; print(sys.executable); print(sys.version); print(ssl.OPENSSL_VERSION); print(ssl.get_default_verify_paths())"
python -m pip --version
python -m pip show certifi

sys.executableで実行ファイル、pipの出力でインストール先と版を記録します。certifiが見つからなくても、pipに同梱物がない証拠にはなりません。また、sslの既定パスは独自SSLContextやライブラリーが選ぶバンドルをすべて示すものではありません。アプリの接続設定と照合する入口として使います。

既存の仮想環境も更新対象に含める

Python公式：venvによる仮想環境によると、仮想環境は基になるPythonの上に作られ、独立したパッケージ群を持ちます。そのため、端末全体でpipを一回更新しただけでは、各プロジェクトの仮想環境を確認したことになりません。CIキャッシュ、常駐バッチ、開発用ツールが持つ環境も一覧にします。

本サイトの推奨は、基になるPythonを修正済みに更新し、依存関係を記録したうえで新しい仮想環境を作り、業務試験後に切り替える方法です。既存環境を無条件に削除せず、アプリのソースや設定を仮想環境の中に置いていないことも確認します。次は修正済みPython 3.15を選択できる環境での作成例です。

python3.15 -m venv .venv-ca-refresh
.venv-ca-refresh/bin/python -m pip install --upgrade "pip>=26.2.2"
.venv-ca-refresh/bin/python -m pip install --upgrade "certifi>=2026.10.19"
.venv-ca-refresh/bin/python -m pip --version

この例はアプリ依存関係の復元までを含むものではありません。以後の依存関係の導入で古いcertifiを固定し直さないよう、requirementsやロックファイルを確認します。Windowsでは仮想環境の実行ファイルがScripts配下になるため、同じパスをそのまま使わず、選択した環境を明示します。

未更新の環境から更新する場合の信頼を確保する

上の更新コマンドは、修正済みPythonの通常の証明書検証を使うことが前提です。未更新のPythonと古いpipを使ったまま、外部から更新物を取得する場合は、その取得経路自体の信頼を確認する必要があります。証明書のエラーを消す目的で検証を無効にしてはいけません。

Python公式の利用者向け案内には、pipのwheelの配布URLとSHA-256を指定して導入する手順があります。Python本体を先に更新できない場合は、その原文にあるURLとハッシュを照合して利用してください。別経路から取得した任意のwheelを同じものとして扱ったり、ハッシュを省いたコマンドへ書き換えたりしないことが重要です。

社内ミラーやオフライン配布を使う場合も、更新物の出所、ハッシュ、配布先を記録します。ミラーへ登録しただけで終わらず、各環境が修正済み成果物を取得したか確認します。OS管理のPythonには、その配布元が許す更新方法を選び、管理外のpipで一律に上書きする手順にしません。

接続成功だけでは遮断を確認したことにならない

Python公式：sslモジュールが説明する証明書検証を維持したうえで、通常使うパッケージ取得と外部API接続の回帰試験を行います。正常なHTTPS接続が成功しても、問題の鍵を拒否できることを直接証明する試験ではありません。修正取り込みの記録と、実行中のPython・pipの確認を組み合わせて完了判定します。

証明書エラーが出た場合は、接続先名、プロキシ、時刻、実際に使うCAバンドルを切り分けます。企業プロキシ用のCAが必要な構成でも、問題の信頼を戻すことと混同しないでください。独自の検証無効化が残っていないかも調べ、成功させるための例外を恒久設定へ持ち込まないようにします。

コンテナやCIイメージは、修正済みのPythonと依存関係を含む成果物を作成し、実際のジョブへ切り替えます。ノードの更新やレジストリーへの登録だけで完了にせず、ジョブ内で実行パスと版を確認します。詳細なコンテナ更新の考え方は関連記事へ譲り、今回はPython環境ごとの確認を完了条件にします。

変更記録には、環境名、Pythonの配布元と修正根拠、実行ファイルのパス、pipの版、アプリ用certifiの版、業務試験の結果を一組で残します。取得済みの依存関係に不審な差分がある場合は、更新作業とは別にビルド記録と成果物を調べます。今回の更新だけから過去の侵害の有無を判断することはできません。

関連記事

GKEのCA失効対応とコンテナ・Webhookの確認は、ノードとアプリ用イメージを分けた更新を説明しています。Pythonの対策とは管理対象を区別して利用してください。