pip をいますぐ26.2.2へ更新｜認証局eMudhraの弱い鍵と、OSの証明書を直しても pip が直らない理由

pip アップデートを急ぐニュースが2026年10月に流れました。きっかけは、インドの認証局 eMudhra（ブランド名 emSign）が、HTTPSの正しさを保証するための中間CAを、当て推量で復元できるほど弱い秘密鍵で署名していたことです。SNSでは「Python が侵害された」「pip install が侵害された」と広がりましたが、それは正確ではありません。PyPI も pip も乗っ取られていません。 弱い鍵で偽の証明書を作れる状態だったために、通信に割り込める位置にいる第三者が偽の pypi.org を掴ませうる、という話です。何が本当で、なぜ pip を上げる必要があるのかを、pip の変更履歴と各社の失効告知で裏を取って整理します。依存パッケージの取得経路そのものが攻撃の入口になる全体像は、サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめています。

eMudhra（emSign）の弱い鍵で何が起きたか

HTTPSは、アクセス先が本物であることを「証明書」で確かめる仕組みです。その証明書に署名して本物だと保証するのが認証局（CA）で、ブラウザやOSは少数のCAのルートをあらかじめ信頼しています。eMudhra はそのひとつで、emSign というブランドでルートが各トラストストアに入っていました。

報じられた内容を、確認できた事実と、研究者・報道の指摘に分けて並べます。

弱い鍵で偽の証明書を作れると何が起きるか。秘密鍵を復元した人は、任意のドメイン向けに「本物に見える」証明書を自分で発行できます。これを使えるのは、被害者とサーバーの間に割り込める位置（公衆Wi-Fi、ISP、国家レベルの経路）にいる相手です。そこで偽の pypi.org を立て、本物の証明書として見せれば、警告なしに偽サイトへ繋がせられます。言い換えると、必要なのは「あなたの機械に侵入すること」ではなく「あなたの通信経路に座ること」です。鍵の強さは本来、ここで総当たりを不可能にして経路上の相手を止める最後の壁ですが、秘密値が256通りに収まっていたため、その壁がほぼ無くなっていました。

8つのうち2つはコード署名を発行できる中間CAでした。コード署名は、配布される実行ファイルやパッケージが「確かにその発行者のものだ」と示す仕組みです。復元した鍵でこの署名を作れれば、署名を信頼して動くソフトに偽物を本物として受け入れさせる余地も、理屈のうえでは生まれます。

だからこそ各社は急いで失効・ブロックへ動きました。eMudhra は10月18日に8つの中間CAを失効し、クロス署名していた Sectigo も10月19日までに失効、Mozilla・Google・Apple・Microsoft も中間CAをブロックしました。Chrome は10月27日に emSign のルートそのものを削除する予定で、これに連なる正規の証明書も一部が切れます。CAの信頼は、鍵を正しく作って守り切れて初めて成り立つもので、生成の手順が一度ゆるむと、こうして一斉に失効と入れ替えが要る騒ぎになります。

なぜ OS の証明書を直しても pip は直らないのか

ここが今回のいちばんの急所で、SNSの短いアラートでは伝わりにくい点です。多くのソフトはOSのトラストストア（ca-certificates）を見ます。しかし pip は違います。

pip の変更履歴（NEWS）によると、pip は24.2 から システムの証明書「と」同梱 certifi の両方でHTTPS接続を検証します（Python 3.10 以降）。両方を足して信頼するため、どちらか一方でも emSign を信頼していれば、その証明書は通ってしまいます。 OS 側で ca-certificates を更新して emSign を外しても、pip に同梱された certifi が古いままなら、pip はまだ emSign を信頼します。そしてこの同梱 certifi を無効にする正式な方法はありません。

pip 26.2.2（2026年10月20日）は、この同梱 certifi を 2026.10.19 に差し替えるだけのリリースです。だから直し方は「OSを更新する」ではなく「pip 自体を上げる」になります。紛らわしいのは、プロジェクトに入れている standalone の certifi パッケージをいくら上げても、pip が内部に抱える同梱分は変わらない点です。pip を更新できるのは pip 自身だけ、と覚えておくと間違えません。

自分の環境が影響を受けるか確認する

各環境で版を確かめます。仮想環境・コンテナはそれぞれ別の pip と certifi を持つので、環境の数だけ確認します。

# 各 venv を有効化した状態で、pip の版を見る（26.2.2 以上なら同梱 certifi は対応済み）
python -m pip --version

# certifi を使うアプリの実行環境では、certifi の版も見る（2026.10.19 以上）
python -c "import certifi; print(certifi.__version__)"

システムのトラストストアに、失効対象の emSign が残っていないかも探せます。

# 信頼ストアの中に emSign のルート/中間CAが残っていないか
grep -rli 'emSign' /etc/ssl/certs 2>/dev/null

手元で確かめると、emSign を含む証明書が置かれた環境ではパスが出て、置かれていない環境では何も出ません。これは判定ではなく構成の確認で、この結果だけでは安全とは言えません。版が新しくても、更新する前に偽の証明書を受け入れていなかったか、までは分かりません。確実なのは、各環境で版を上げ切ることです。

いますぐやる pip アップデートと周辺の更新

やることは「環境ごとに上げる」の一点です。見落としやすい順に挙げます。

・pip を各 venv で 26.2.2 以上に：python -m pip install --upgrade pip。プロジェクトごとの仮想環境は別々に
・certifi を使うアプリは 2026.10.19 以上に：requests・httpx などの実行環境。pip 同梱とは別枠
・ensurepip で pip を入れている場合は処理系ごと更新：python -m ensurepip --upgrade は処理系に同梱された古い pip を入れ直すだけなので、更新版の処理系（例 Python 3.15.1 / 3.14.9 / 3.13.17）が要る
・OS とコンテナ：apt／dnf で ca-certificates を更新。Docker イメージは再ビルドし、ベースイメージの pip・certifi・OS証明書を新しくする
・CI/CD：ランナーやジョブのコンテナも同じ対象。1か所直して終わりにしない

便乗した偽の注意喚起にも気をつけてください。更新は PyPI と OS の正規の配布経路から行い、メールやSNSのリンク先で勧められた手順をそのまま実行しないことです。緊急の更新を本番やコンテナへ素早く当てる基盤づくりは、PHP 緊急アップデートを数分で本番に当てる基盤の作り方でも扱っています（PHP の例ですが、環境ごとに版を上げ切る考え方は同じです）。

どれくらい危ないのか：誇張と実像、pip アップデートで塞げる余地

最後に、出回っているアラートとの温度差を整理します。「Python が侵害」「pip install が侵害」という表現は言い過ぎです。PyPI も pip も破られていません。起きたのは、信頼の土台であるCAの鍵が弱く、偽の証明書を作れる余地ができたことです。

一方で、軽く見てよい話でもありません。この余地を突けるのは通信経路に割り込める相手に限られますが、pip はまさに「失効を見ず、OSとは別の証明書ストアを足して信頼する」種類のソフトで、更新が遅れた分だけ余地が残ります。影響の範囲は、pip でパッケージを取得するすべての環境（開発機・本番コンテナ・CI）と、同梱 certifi を参照する処理です。コード署名を発行できる中間CAも2つ含まれていたため、署名を信頼する仕組みにも理屈のうえでは影響しえます。

現時点で実際の悪用は報告されていません。やることは派手ではなく、環境の数だけ版を上げ切ること。それで今回の余地は塞げます。依存を取り込む経路を日頃から監視して更新を自動で回す考え方は、RenovateとDependabotで依存の供給経路を守るにまとめています。

参照ソース

・pip NEWS（pypa/pip） — 26.2.2（2026-10-20）で同梱 certifi を 2026.10.19 に更新。24.2 でシステム証明書と certifi の両方を使用（2026-10-23 確認）
・pypa/pip NEWS.rst（GitHub 原文） — 上記の記載を一次情報で確認した原本
・Mozilla, Google, Apple block compromised eMudhra CA certificates（BleepingComputer） — 失効と各社のブロック
・Indian certification authority eMudhra’s private keys compromised（The Register, 2026-10-20） — 秘密値が256未満・1つは「4」
・eMudhra Intermediate CA Private Key Compromise（Kudelski Security） — 鍵生成の欠陥と範囲の技術解説