Python Package Index(PyPI)は、公開から14日以上経過したリリースへのファイルアップロードを拒否する新しいセキュリティ制限を導入しました。
Seth Larson氏が発表したこの変更は、公開用の認証情報やCI/CDワークフローが侵害された場合に、攻撃者が安定版として既に公開済みのリリースを汚染できてしまうという、長年存在してきた抜け穴を塞ぐことを目的としています。
これまでPyPIでは、メンテナーが最初の公開から何年経った後でも、リリースに新しいファイルを無期限に追加できる仕組みになっていました。
この「無期限」モデルでは、トークンやワークフローが一つ侵害されただけで、ユーザーが既に信頼してインストール済みのリリースに悪意のあるファイルを注入することが可能でした。しかも新しいバージョン番号が発行されないため、変更に気づかれることもありませんでした。
PyPIによれば、この特定の攻撃手法が実際に悪用された事例はまだ確認されていないとのことですが、担当者は「攻撃者がこの手口の存在に気づいていなかっただけで、技術的にはそれを妨げる要因は何もなかった」と指摘しています。
14日という締め切りを設けることで、この残存していた攻撃対象領域が取り除かれます。リリースが公開から2週間を経過すると、そのファイル一覧は事実上凍結され、気づかれないまま遡って改ざんされる隙がなくなります。
この制限を求める動きは、2024年1月のPEP 740(デジタル認証)に関する議論にまで遡りますが、その後停滞していました。しかし2026年3月に発生したサプライチェーン侵害事案をきっかけに、改めて緊急性が高まりました。
人気パッケージであるLiteLLMとTelnyxは、Trivy GitHub Actionの利用における「ミュータブル参照(mutable reference)」の脆弱性を通じて侵害されており、これはまさに今回のポリシーが対処しようとしている「遡及的な汚染」のリスクそのものでした。
この変更を実装する前に、PyPIは正当なワークフロー、特に新しいバージョンのリリースを公開する代わりに既存のリリースに新しいPythonバージョン向けのwheelファイルを追加しているメンテナーの作業を壊さないことを確認する必要がありました。同チームは利用パターンの分析を行いました。
この分析結果は、PyCon US 2026のPackaging SummitでPyPIのSafety & Security担当エンジニアであるMike Fiedler氏によって発表されました。参加者の間では、新しいPythonバージョンへの対応にバージョン番号の更新を必須とすることは、セキュリティ上の利点を得るための妥当な代償であるとの、大まかな合意が形成されました。
データとコミュニティの合意を踏まえ、Larson氏は2026年7月8日にこのパッチをマージしました。なお、PyPIは、リリースが「クローズ」状態にあることを確認するための正式なAPIや定義済みの仕様がまだ存在しないため、この挙動をプログラム的に依存すべきではないと注意を促しています。
この点の明確化は、PEP 694の「Upload 2.0 API」および「Staged Previews」機能によってもたらされる見込みです。
リリースが公開から14日を経過して内容がロックされることで、PyPIの管理者にとってはインシデント対応の境界がより明確になり、ユーザーにとっては既にインストール済みのパッケージに対する信頼性が一段と高まります。
SOC調査の死角を減らし、脅威をより早期に封じ込めることで、ANY.RUNにより対応コストと業務への影響を削減できます。
翻訳元: https://cyberpress.org/pypi-blocks-files-14-day-old-releases-package-poisoning/
