python.org のリリース管理 API に認証バイパス脆弱性が12年間存在|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年07月01日更新日時: 2026年07月01日

Python Software Foundation（PSF）は2026年6月23日、python.org のリリース管理 API に2014年から存在していた認証バイパス脆弱性について、修正完了と第三者監査結果の最終報告書を公開しました。

この脆弱性は2026年2月23日に DEVCORE リサーチチームの Splitline Ng が発見し、PSRT（Python セキュリティレスポンスチーム）に報告後48時間以内にパッチが適用されています。悪用の痕跡はログ・データベースバックアップ・成果物署名のすべてで確認されませんでしたが、もし悪用されていれば python.org/downloads のダウンロード URL を攻撃者が差し替えることが可能であり、全世界の Python ユーザーを対象とした大規模なサプライチェーン攻撃に発展しうる脆弱性でした。

サマリー

python.org のリリース管理 API に 2014年から12年間存在していた認証バイパス脆弱性が発見・修正された（発見者：DEVCORE の Splitline Ng、発見日：2026年2月23日）
任意の API キーを管理者ユーザー名と組み合わせて送ると、リクエストが管理者権限で処理される設計上の欠陥。パッチは24時間以内に本番適用済み
悪用された場合、python.org/downloads に表示されるダウンロード URL や Sigstore 署名・PGP 鍵の検証 URL を攻撃者が書き換え可能だった。リリースバイナリの改ざんは不可能
ログ・データベースバックアップ・Sigstore/PGP 署名の総点検（Python 2.5〜3.13）を実施し、悪用の事実はゼロと確認
OpenAI の資金提供による Trail of Bits の第三者監査（6月1〜5日）も完了し、追加の認証・認可の問題はなかったと確認
今回の事案は PSF の「Security Developer-in-Residence」制度と Alpha-Omega プロジェクトによるセキュリティ専任体制があって初めて実現した迅速対応事例

日付	対応内容
2026年2月23日	DEVCORE Splitline Ng が PSRT に報告。当日中に確認・受理
2026年2月24日	パッチ（PR#2946）を本番適用。DEVCORE が PoC 無効化を確認
2026年2月25日	ログ・DB バックアップ・Sigstore・PGP 全件監査完了。悪用なし
2026年4月23日	LLM セキュリティ監査ツールをコードベースに適用。追加問題なし
2026年6月1〜5日	Trail of Bits による第三者監査（OpenAI 資金提供）実施
2026年6月23日	PSF が最終報告書を公開

1 12年間気づかれなかった認証バイパスの仕組み
2 悪用された場合のサプライチェーン攻撃への転化リスク
3 実施された4つのハードニング措置
4 情報システム部門が取るべき対応
5 出典

12年間気づかれなかった認証バイパスの仕組み

python.org のリリース管理 API は、python.org の管理者がリリース情報やファイルメタデータを更新するために使用する内部APIです。今回の脆弱性の本質は、このAPIの認証処理における「ゲスト認証モード」と「API キー認証モード」の実装上の混在にあります。

PSF 公式ブログの説明によると、攻撃者が管理者ユーザーの名前を知っていれば、任意の文字列を API キーとして組み合わせて送信するだけでリクエストが管理者権限として処理されていました。API キーの値自体の正当性が検証されずに認証が通過してしまう、典型的な認証バイパスです。パッチ（PR#2946）ではゲスト認証モードと API キー認証モードの分岐ロジックが明確に切り分けられ、二つの挙動が混在していた根本原因が修正されています。

この脆弱性が 2014年のコミット（0be429f0）以来12年間存在し続けた背景には、リリース管理 API の利用が PSF の管理者に限定されており、通常のユーザーがアクセスする経路がなかったことがあります。内部 API の認証ロジックは外部公開の認証経路ほど頻繁にテストされず、ネガティブケース（認証失敗のテスト）が不足していたことも長期間見逃された要因として報告書に記録されています。

悪用された場合のサプライチェーン攻撃への転化リスク

この脆弱性が悪用された場合に何が起きたかを具体的に整理します。

攻撃者は python.org のリリースメタデータを書き換え、python.org/downloads に表示されるダウンロード URL を攻撃者管理のサーバーに置き換えることができました。これにより、Python の公式インストーラーをダウンロードしようとするユーザーに対してマルウェアを配布するか、改ざんされた Python バイナリを提供することが可能でした。

さらに重要なのが署名材料 URL の改ざんです。Python のリリースには Sigstore 署名（Python 3.14以降はこれのみ、PEP 761 参照）と PGP 鍵による署名検証材料が含まれており、これらの URL も書き換え可能でした。ダウンロード URL と署名検証 URL を同時に攻撃者管理のものに置き換えれば、署名検証を行うユーザーや自動ビルドシステムに対しても整合性の取れた形で悪意あるバイナリを配布できた可能性があります。

ただし PSF は重要な留意点も示しています。実際の被害が生じていたとしても「静かな攻撃」にはなりにくかった理由として、多くの Python の再配布者・ディストリビューターが Sigstore または PGP 署名を独自に検証しており、URL の改ざんだけで全ての検証をすり抜けることは困難だったと説明しています。とはいえ、直接 python.org からダウンロードする個人ユーザーへの攻撃は成立しうるシナリオでした。

Python の依存パッケージエコシステムのサプライチェーンリスクや北朝鮮系ハッカーによる axios npm パッケージへのサプライチェーン攻撃でも示されているように、OSSの配布プラットフォームを標的にした攻撃は、ダウンロード数の多いパッケージほど被害が連鎖的に拡大します。Python はスクリプトから AI/ML インフラまで幅広く使用されており、公式配布サイトへの攻撃が成功した場合の影響範囲は極めて広大です。

実施された4つのハードニング措置

修正は認証バイパスのパッチだけにとどまらず、複数の追加強化措置が実施されています。

まず認証ロジックの修正（PR#2946）で、ゲスト認証モードと API キー認証モードの実装上の混在が解消されました。さらに Trail of Bits の監査を経た追加措置（PR#3014）として、新しいリリースに対して HTTPS URL を必須とするカスタムバリデーターが追加されています。

URL バリデーション強化（PR#2947）として、データベースと API が https://www.python.org/ から始まらない URL を拒否するようになりました。仮に将来的に認証・認可を迂回する手段が発見されても、攻撃者が管理するサーバーへの URL を登録できなくなっています。

認証テストカバレッジとして、すべての認証失敗パターン（ネガティブケース）のテストコードが追加されました。長期間発見されなかった原因の一つが認証失敗テストの不足だったことを踏まえた直接的な対策です。

ログ保存期間は3日から30日に延長され、今後のインシデント調査能力が改善されています。

情報システム部門が取るべき対応

本件は python.org 側での修正が既に完了しており、Python ユーザーがシステム側で行うべき特別な対応は基本的にはありません。Python 3.14 以降のリリースは Sigstore 署名のみで検証されており、ダウンロードした Python バイナリの整合性検証は公式の署名材料を使って実施することが推奨されます。

より重要な視点はこの脆弱性が示す構造的な教訓です。Python のように世界中で使われる基盤 OSS の公式配布インフラであっても、内部 API の認証ロジックの実装不備が12年間見逃されうるという現実があります。自社の開発環境で依存している言語ランタイム・パッケージマネージャー・ビルドツールの配布元がどのようなセキュリティ体制を持っているかを評価する視点は、ソフトウェアサプライチェーンリスク管理の一環として持っておく価値があります。

また、自組織が内部 API や管理者向け API を運用している場合、今回の事案は「ゲスト認証モードと API キー認証モードの実装が混在していないか」「認証失敗のネガティブテストケースが存在するか」という点を見直す機会となります。

今回の迅速な対応（48時間以内の修正）は、PSF が Alpha-Omega プロジェクトの支援により Security Developer-in-Residence（専任セキュリティエンジニア）を配置していたことが大きく寄与しています。OSSプロジェクトのセキュリティ体制の持続可能性への支援も、ソフトウェアサプライチェーンセキュリティの観点から重要です。