結論から書きます。Python を使っていて pip install をする人、あるいは Python から外部 API に接続している人は、pip を 26.2.2 以上、certifi を 2026.10.19 以上に上げてください。uv・conda・pixi・sigstore を使っているなら、それぞれの修正版も必要です。この記事は 2026年10月23日時点の一次情報（Python 公式フォーラム、certifi・uv の公式勧告、Google Security Blog）をもとに、初心者でも手順を追えるように整理した注意喚起です。仕組みの解説 → 影響判定 → 確認コマンド → 安全な更新手順 → Claude Code に丸ごと監査させるプロンプト、の順に進みます。

• 0枚
  秘密鍵が弱かった中間CA証明書
• 0種
  修正版が出た Python 系ツール
• 0年〜
  影響を受ける certifi の範囲

user@sinyblog:~/security ❯ 01_tldr.md90秒でわかる：何が起きて、何をすればいいか

2026年10月、インドの認証局 eMudhra（ブランド名 emSign）が発行した 8つの中間CA証明書の秘密鍵が、極端に弱い乱数で生成されていたことが報告されました^[5]。秘密鍵が推測できるということは、第三者がその認証局になりすまして「本物そっくりの HTTPS 証明書」を発行できるということです。

ブラウザ（Chrome / Android）は Google がすでに遮断しています。問題は Python 側です。Python 公式フォーラムの告知によると、pip は自分に同梱した certifi の証明書を、OS の証明書ストアに加えて必ず読み込みます。これを無効にする正式な方法はありません^[1]。つまり OS 側で問題の認証局を不信任にしても、古い pip は守られません。

user@sinyblog:~/security ❯ 02_timeline.md時系列で追う：発覚から各社の対応まで

公開情報を日付順に並べます。時刻は各情報源の表記どおりです。

1. 2026-10-17（土） 18:05 UTCセキュリティ研究者が Chrome Root Program に報告。eMudhra の中間CA 8 枚の秘密鍵が弱い乱数で生成されていたという内容^[5]。
2. 2026-10-17 19:45 UTCChrome が内容を確認し、CRLSet（Chrome が配信する失効リスト）で該当中間CAの公開鍵ハッシュをブロック。ブラウザの更新や再起動なしで保護が効く^[5]。
3. 2026-10-19（月） 22:00 UTC 頃Android 端末にも Google Play 開発者サービス経由で同等の更新を配信^[5]。
4. 2026-10-20certifi が重大度 Critical の勧告を公開（emSign ルートを削除した修正版は 2026.10.18、推奨は 2026.10.19）^[2]。同日 pip 26.2.2 がリリース。uv も 0.13.4 で修正。Python 公式フォーラムに Python 利用者向けの告知が掲載^[1][4][6]。
5. 2026-10-21フォーラム上で、公式 Docker の python イメージがまだ pip 26.2.1 を同梱していると報告される（この時点の情報）。CPython の ensurepip 修正もマージ済みで、セキュリティリリース待ち^[1]。
6. 2026-10-27（火・PDT）予定Chrome Root Store から、問題の中間CAを署名した emSign ECC Root CA - G3 を削除する更新が届く見込み^[5]。

Google の発表では、ブロック前に Certificate Transparency（証明書の公開ログ）に記録された、問題の中間CAにつながる証明書はなかったとされています^[5]。ただしこれは CT を強制するクライアント（Chrome など）にとっての話です。Python の標準的な TLS 検証は CT ログを確認しないので、同じ理屈で「Python も安全だった」とは言えません。

user@sinyblog:~/security ❯ 03_what_is_ca.mdそもそも認証局・中間CAとは何か

HTTPS で pypi.org に接続するとき、サーバーは「私は本物の pypi.org です」という証明書を出してきます。この証明書が本物かどうかを保証するのが認証局（CA）です。仕組みは三段構えになっています。

クライアント（ブラウザや pip）は、サーバー証明書 → 中間CA → ルートとたどり、最後のルートが自分の信頼リストに入っていれば「本物」と判断します。ここで大事なのは、中間CAの秘密鍵を持っている人は、どのドメイン名の証明書でも署名できてしまうという点です。pypi.org でも api.example.com でも、です。

今回は、その秘密鍵が推測できるほど弱く作られていました。Google は「弱い乱数（weak randomness）」と説明しており^[5]、Python フォーラムにも 8 つすべての鍵が極端に小さい値だったという指摘が投稿されています^[1]。鍵を盗む必要すらなく、計算で求められる状態だったということです。

user@sinyblog:~/security ❯ 04_attack_flow.md攻撃はどう成立する？中間者攻撃の流れ

攻撃の名前は中間者攻撃（MITM: Man-in-the-Middle）です。あなたの PC とサーバーの間に攻撃者が割り込み、両方に対して「本物」のふりをします。

偽証明書が受け入れられた場合、起こりうることは次の 3 つです。

1. 送ったものが盗まれる：API キー、Bearer トークン、パスワード、送信したデータ本体。
2. 返ってきたものが書き換えられる：API の応答、ダウンロードしたファイル。
3. インストールするものが汚染される：pip install で取得するパッケージやビルド処理が差し替えられるリスク。開発者の PC や CI が丸ごと狙われる入口になり得ます。

例えば Python の requests で外部 API に接続しているコードは、使っている CA バンドル次第で偽証明書を拒否できない可能性があります。ただし「requests を使っている＝攻撃された」ではありません。第2段階の「経路への割り込み」が成立して初めて、この攻撃は意味を持ちます。

user@sinyblog:~/security ❯ 05_why_pip.mdなぜ Windows Update だけでは pip が守られないのか

ここがこの記事でいちばん伝えたいところです。証明書の信頼リストは、PC の中に1 つではなく複数あります。

pip は内部に certifi を「ベンダー化（丸ごと同梱）」しています。Python 公式フォーラムの告知は、pip は同梱 certifi の CA を常に読み込み、システムの信頼ストアはそれに加える形で使うこと、そしてこの動作を無効化するサポートされた方法がないことを明記しています^[1]。

そのため、OS 側で emSign を不信任にしても、pip 26.2.2 未満は emSign を信頼し続けます。pip show certifi で certifi が見つからなくても、それは「その環境に certifi パッケージが入っていない」だけで、pip の中の certifi とは別物です。

user@sinyblog:~/security ❯ 06_who_is_affected.mdあなたは対象？影響する人・しない人

使い方ごとの判定の目安です。「要確認」は「被害が出た」ではなく「バージョンを見てください」という意味です。

user@sinyblog:~/security ❯ 07_fixed_versions.md修正版バージョン早見表

Python 公式フォーラムで案内された最低限の修正版です^[1]。これ以上であれば、問題の emSign ルートを信頼リストから外した状態になっています。

user@sinyblog:~/security ❯ 08_check_windows.ps1自分の環境を確認する（Windows 編）

ここからは読み取りだけのコマンドです。何も変更されないので安心して実行してください。PowerShell を開いて、まず PC に入っている Python を一覧します。

# インストール済みの Python を一覧（py ランチャーがある場合）
py -0p

# 既定の Python と pip / certifi のバージョン
py --version
py -m pip --version
py -m pip show certifi

# 使っているものだけ実行
uv --version
conda --version
pixi --version
sigstore --version

py -0p で複数の Python が出てきたら、それぞれ別の pip を持っています。py -3.12 -m pip --version のようにバージョンを指定して全部確認してください。py が無い環境では Get-Command python, python3, py -ErrorAction SilentlyContinue で実体を探します。python が動かないだけで「Python は入っていない」と判断しないでください。

次に、プロジェクトの仮想環境（.venv）を確認します。仮想環境ごとに pip は別物です。

# プロジェクト直下の .venv
.\.venv\Scripts\python.exe --version
.\.venv\Scripts\python.exe -m pip --version
.\.venv\Scripts\python.exe -m pip show certifi

# 作業フォルダ配下の仮想環境をまとめて探して pip のバージョンを表示
Get-ChildItem -Path . -Recurse -Filter pyvenv.cfg -ErrorAction SilentlyContinue |
  ForEach-Object {
    $py = Join-Path $_.DirectoryName "Scripts\python.exe"
    if (Test-Path $py) { "{0}  ->  {1}" -f $_.DirectoryName, (& $py -m pip --version) }
  }

user@sinyblog:~/security ❯ 09_check_unix.sh自分の環境を確認する（macOS / Linux 編）

macOS と Linux はターミナルで次を実行します。こちらも読み取り専用です。

command -v python3 || true
python3 --version
python3 -m pip --version
python3 -m pip show certifi

# 使っているものだけ
command -v uv && uv --version
command -v conda && conda --version
command -v pixi && pixi --version
command -v sigstore && sigstore --version

# プロジェクトに .venv がある場合
./.venv/bin/python --version
./.venv/bin/python -m pip --version
./.venv/bin/python -m pip show certifi

macOS では Python の入り方が複数あります。Homebrew 版、pyenv 版、Conda 版、そして python.org の公式インストーラー版です。公式インストーラー版は certifi を独自に同梱しており、Python 公式フォーラムには 3.11〜3.15 向けの更新手順（フリースレッド版 python3.15t を含む）が個別に掲載されています^[1]。which -a python3 でどれが動いているかを確かめ、公式インストーラー版ならフォーラムの該当手順に従ってください。

Linux はディストリビューションによって pip の CA の扱いが違います。OS のパッケージマネージャーで入れた Python（PEP 668 で「外部管理」とされている環境）は、システム側を直接 pip で書き換えず、OS の更新か仮想環境で対応するのが安全です。

user@sinyblog:~/security ❯ 10_upgrade_pip.mdpip を安全に更新する：SHA-256 固定 URL を使う

ここで一つジレンマがあります。古い pip の TLS 検証が信用できないのに、その古い pip で新しい pip をダウンロードすることになるからです。いつもの pip install --upgrade pip では、取得経路が改ざんされていないことを保証できません。

そこで Python 公式フォーラムは、wheel ファイルの URL と SHA-256 ハッシュを固定してインストールする方法を案内しています^[1]。ダウンロードしたファイルがハッシュと一致しなければインストールは失敗するので、仮に通信が改ざんされても偽物は入りません。

python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"

1. 対象の Python を決める：先頭の python を、実際に更新したい環境に置き換えます。Windows なら py や .\.venv\Scripts\python.exe、macOS / Linux なら python3 や ./.venv/bin/python。
2. Python 3.10 以上か確かめる：3.9 以下では動きません（第7章）。
3. 実行して、結果を確認：-m pip --version で pip 26.2.2 と表示されれば成功です。
4. 仮想環境ごとに繰り返す：システムの Python を更新しても、既存の .venv の pip は古いままです^[1]。

user@sinyblog:~/security ❯ 11_upgrade_others.mdcertifi・uv・conda・pixi・sigstore の更新

pip を 26.2.2 にしたら、その新しい pip を使って他を更新します。順番が大事です。古い pip のまま certifi を更新すると、第10章のジレンマがそのまま残ります。

# 対象の Python 環境ごとに
python -m pip install --upgrade certifi
python -m pip --version
python -m pip show certifi

uv は自己更新で 0.13.4 以上にします。古い uv は同梱 CA を使うため、Python 公式フォーラムでは OS の証明書ストアを使わせたうえで自己更新する方法が案内されています^[1]。macOS と Windows は OS 側の証明書が更新済みという前提です（Linux はディストリビューション次第）。

# macOS / Linux
UV_SYSTEM_CERTS=true uv self update

# Windows PowerShell
$env:UV_SYSTEM_CERTS = "true"; uv self update

# 確認
uv --version

conda / pixi / sigstore は、使っている人だけ対象です。どうやって入れたか（自己更新、pip、OS パッケージ、conda 経由など）を確認し、それぞれの公式の更新手順で第7章のバージョン以上にしてください。更新後は必ずもう一度 --version で確かめます。

user@sinyblog:~/security ❯ 12_venv_docker_ci.md仮想環境・Docker・CI に残る落とし穴

手元の PC を直しても、古い pip は思わぬ場所に残っています。見落としやすいのは次の 5 か所です。

1. 既存の仮想環境：.venv を作ったときの pip がそのまま残っています。Python 本体を更新しても自動では直りません。プロジェクトごとに第10章の手順を実行します。
2. これから作る仮想環境：python -m venv は Python 本体に同梱された pip（ensurepip）を入れます。CPython 側の修正はマージ済みでセキュリティリリース待ちとされています^[1]。それまでは新しい venv を作ったら最初に pip を更新する習慣をつけてください。
3. Docker イメージ：2026年10月21日時点で、公式 python イメージはまだ pip 26.2.1 を同梱していたと報告されています^[1]。Dockerfile の中で pip を更新し、Python 公式の案内どおりレイヤーキャッシュを無効にして再ビルドします。
4. CI・ロックファイル：requirements*.txt、pyproject.toml、poetry.lock、uv.lock、Pipfile.lock、environment.yml で certifi や pip のバージョンを古いまま固定していないか確認します。
5. 独自の CA 設定：REQUESTS_CA_BUNDLE、SSL_CERT_FILE、SSL_CERT_DIR、コード内の独自 SSLContext、アプリに埋め込んだ CA ファイル。これらは certifi を更新しても変わりません。中身に emSign のルートが入っていないかを確認します^[6]。

# ベースイメージも取り直し、キャッシュを使わずにビルド
docker build --pull --no-cache -t myapp:latest .

# ビルド後に中身を確認
docker run --rm myapp:latest python -m pip --version
docker run --rm myapp:latest python -m pip show certifi

user@sinyblog:~/security ❯ 13_dont.mdやってはいけない誤対応 7 つ

慌てたときほどやりがちな誤りです。特に最後の 1 つは、問題を悪化させます。

user@sinyblog:~/security ❯ 14_claude_code_audit.mdClaude Code に環境を監査させるプロンプト

Python 環境が多い人ほど、手作業で全部を確認するのは大変です。Claude Code のようなコーディングエージェントに読み取り専用の監査を任せると、仮想環境やロックファイル、Dockerfile まで一気に洗い出せます。ポイントは「最初は何も変更させない」「秘密情報を表示させない」を明示することです。

プロジェクトのフォルダで Claude Code を起動し、次のプロンプトを貼り付けてください。

2026年10月の eMudhra / emSign 認証局インシデントについて、このPCとプロジェクトのPython環境を監査してください。
修正版の目安: pip 26.2.2 / certifi 2026.10.19 / uv 0.13.4 / conda 26.9.4 / pixi 0.82.1 / sigstore 4.5.1
最新情報は https://discuss.python.org/t/information-for-python-users-regarding-emudhra-emsign-ca-certificate-security-incident/109576 で確認してください（アクセス前に許可を取ること）。

【目的】
1. Python の実行ファイル、各仮想環境（.venv / venv / conda / pyenv 等）、pip・certifi・uv・sigstore・conda・pixi の有無とバージョンを調べる。仮想環境ごとに pip は別物として扱う。
2. requests / urllib3 / API 接続、Python 製ツール、MCP サーバー、Dockerfile、CI 設定、requirements*.txt・pyproject.toml・各種ロックファイル・environment.yml を確認する。
3. REQUESTS_CA_BUNDLE / SSL_CERT_FILE / 独自 SSLContext / 埋め込み CA の使用箇所を探す（値は表示しない）。
4. 問題あり・問題なし・未確認を区別し、根拠と安全な修正案を示す。

【厳守】
- 第1段階は完全に読み取り専用。インストール、更新、ファイル編集、Docker 再ビルドはしない。
- APIキー・トークン・パスワード・環境変数の値は表示・記録・送信しない。.env 等の機密ファイルは開かない。
- 影響の有無を推測で断定しない。確認した実行ファイルのパスとバージョンを根拠にする。
- 存在しないコマンドや権限不足で読めない環境は「未確認」とする。
- 修正は私の明示的な承認後。pip の更新は公式の SHA-256 固定 URL を使い、verify=False や --trusted-host などの検証無効化は提案しない。

【出力】
A. 総合判定（要対応 / 対応不要 / 追加調査）
B. 環境一覧（Python・仮想環境のパス、pip、certifi 等のバージョン）
C. 影響候補一覧（該当ファイル・箇所・根拠）
D. 優先度付きの対策案（実行せず提示のみ）
E. 更新後の確認方法
F. 未確認事項

user@sinyblog:~/security ❯ 15_priority_summary.md優先度の付け方と、今日やる3つのこと

環境が多い場合は、次の順で手を付けると効率的です。優先度はこの記事での実務上の目安で、公式の深刻度評価ではありません。

最後に、今日やることを 3 つに絞ります。

1. pip を 26.2.2 以上にする。システムの Python だけでなく、仮想環境ごとに。手順は SHA-256 固定 URL で。
2. 新しい pip で certifi を 2026.10.19 以上にする。uv・conda・pixi・sigstore を使っていればそれぞれも更新。
3. Docker・CI・ロックファイルを見直す。キャッシュなしで再ビルドし、古いバージョンの固定を外す。

証明書の問題は目に見えないぶん、後回しにされがちです。ですが今回は、ブラウザ・OS・Python がそれぞれ別々に対応しなければならない珍しいケースです。「ブラウザが直ったから大丈夫」ではなく、Python は Python で直す。これだけ覚えて帰ってください。