PyPIセキュリティチーム公式サプライチェーン攻撃インシデント報告: LiteLLM・Telnyx悪性パッケージ事件と防御策

 (blog.pypi.org)
5 ポイント 投稿者 darjeeling 26 일 전 | 1件のコメント | WhatsAppで共有

🔑 主要ポイント

Trivy依存関係の脆弱性を通じてAPIトークンが窃取され、それを足がかりにPyPI上でlitellmとtelnyxパッケージの悪性バージョンが配布された。悪性コードはインストール直後に実行され、機密性の高い認証情報やファイルを収集した後、外部サーバーへ流出させた。

⚠️ 今回のマルウェアが特別な理由

従来のPyPI悪性パッケージの多くは新たに作成されたパッケージ（タイポスクワッティングなど）だった。今回の攻撃は異なる。すでに広く使われているオープンソースパッケージに悪性コードを注入する方式だ。

注入経路は2つある:

  • セキュリティの弱いリポジトリ・リリースワークフロー・認証を持つオープンソースプロジェクトを直接狙う
  • 最新バージョンをインストールする開発者マシンからAPIトークン・キーを窃取する

窃取したPyPIまたはGitHub APIトークンを使って、別のオープンソースパッケージをさらに侵害する連鎖攻撃の構造だ。

📅 事件のタイムライン

LiteLLM

悪性バージョンの露出期間中に119,000回以上ダウンロードされた。
PyPIは13件の通報を「マルウェア報告」機能を通じて受け付けた。

段階 所要時間
アップロード → 最初の通報 1時間19分
最初の通報 → 隔離 1時間12分
総露出時間 2時間32分

LiteLLMは週あたり約1,500万〜2,000万回インストールされ、分あたり約1,700件インストールされる。このうち約40〜50%はバージョン固定なしの状態で最新バージョンを自動取得していた。

Telnyx

telnyxパッケージはPyPIのtrusted reporters poolのおかげで自動隔離が行われた。

段階 所要時間
アップロード → 最初の通報 1時間45分
最初の通報 → 隔離 1時間57分
総露出時間 3時間42分

🛡️ 開発者向けセキュリティ勧告

1. 依存関係クールダウン（Dependency Cooldowns）

最近公開されたパッケージを一定期間インストールしないよう設定し、セキュリティ研究者とPyPI管理者が対応する時間を確保する戦略だ。

uv — 現在サポート中:

# ~/.config/uv/uv.toml または pyproject.toml  
[tool.uv]  
exclude-newer = "P3D"  # 3日以内に公開されたパッケージを除外

pip v26.1 — 4月中にサポート予定:

# ~/.config/pip/pip.conf  
[install]  
uploaded-prior-to = P3D

⚠️ クールダウンは万能ではない。セキュリティパッチが必要な場合は即座にインストールする必要があるため、Dependabot・Renovateのような脆弱性スキャンツールと併用すべきだ。

2. 依存関係のロック（Lock Files）

バージョンだけを記録するpip freezeはロックファイルではない。セキュリティのためにはチェックサム/ハッシュを含む本物のロックファイルが必要だ。

推奨ツール:

  • uv lock
  • pip-compile --generate-hashes
  • pipenv

🔒 オープンソース管理者向けセキュリティ勧告

1. リリースワークフローのセキュリティ強化

  • 安全でないトリガーの使用禁止 — GitHub Actionsのpull_request_targetは特に危険
  • パラメータ・入力値の無害化 — 環境変数として渡し、テンプレートインジェクションを防止
  • 可変参照の使用禁止 — Gitタグの代わりにコミットSHAを使い、依存関係のロックファイルを維持
  • レビュー必須のデプロイ設定 — Trusted Publishers + GitHub Environmentsの組み合わせでデプロイ時に追加承認を要求

GitHub Actionsユーザーなら、Zizmor ツールでワークフローの脆弱性を点検することが推奨される。

2. APIトークンの代わりにTrusted Publishersを使用

  • APIトークンは長期有効のため、窃取されても即時検知が難しい
  • Trusted Publishersは短期トークンを使用するため、窃取されてもすぐに使わなければならずリスクが低い
  • Digital Attestationsにより、正規のリリースワークフローを経ていない配布を下流利用者が検知できる

3. 2FAの必須適用

PyPIは2024年からパッケージ配布に2FAを義務化した。しかしPyPIアカウントだけでなく、GitHub、GitLab、メールなどオープンソース開発に関わるすべてのアカウントに2FA（可能ならハードウェアキー）を適用すべきだ。

💰 この活動を支援するには

PyPIのセキュリティ活動は**Python Software Foundation（PSF）**の支援によって成り立っている。PSFスポンサーシッププログラム、直接支援、またはsponsors@python.orgへの問い合わせで支援できる。

Mike FiedlerとSeth LarsonのPyPIセキュリティエンジニア職はAlpha-Omegaの支援を受けている。

関連記事

1件のコメント

 
yjcho9317 21 일 전

MCPサーバーを作ってnpmに上げてみたのですが、このインシデント報告はかなりぞっとしました。

MCPサーバーも結局そのままnpmやPyPIに公開されるのに、バージョンを固定せずにインストールするケースがかなり多いですし、通報の仕組みやtrusted publisherのようなものもまだありません。LiteLLMは2時間ちょっとしか露出していなかったのに、ダウンロード数があれだけあるのを見ると、こちらは一度入り込まれるとかなり長く残るのではないかと思いました。

Claude Codeのほうも見ていると、pip installするときにこうした保護設定がきちんとかからない場合があって、エージェントが勝手にパッケージを入れてしまう流れだと、どこで止めるべきなのか曖昧です.