- 広く使われているLLM統合ライブラリ LiteLLM のPyPIパッケージ2バージョン（1.82.7、1.82.8）に 悪意あるペイロードが挿入 されて配布され、インストール時にシステム認証情報を窃取する攻撃が発生
- 攻撃原因はCI/CDセキュリティスキャンツール Trivyのサプライチェーン侵害 に端を発し、CircleCI認証情報が流出してPyPI公開トークンとGitHub PATが窃取されたことにある
- 公式LiteLLM Proxy Dockerイメージ 利用者は requirements.txt でバージョン固定されていたため影響を受けなかったが、PyPIから直接
pip install した環境は直ちに点検が必要
- GitHubのIssueスレッドには数百件の ボットによるスパムコメント が殺到し、実質的な議論を妨害しており、これは攻撃者が意図的に対応コミュニケーションを攪乱したものと確認
- DSPy、CrewAI などLiteLLMを依存関係に持つ多数のプロジェクトにも波及影響があり、ソフトウェア サプライチェーンセキュリティの根本的脆弱性 を改めて浮き彫りにした
事件概要と発見の経緯
- 新規プロジェクトの設定中にシステムが異常動作し、RAMが枯渇 してフォークボムのようなプロセスが実行された
- 調査の結果、
proxy_server.py に base64でエンコードされた悪意あるブロブ が追加されており、これをデコードして別ファイルを生成した後に実行する構造だった
- 1.82.7バージョンは
litellm/proxy/proxy_server.py にペイロードが含まれ、import litellm.proxy 時に実行 された
- 1.82.8バージョンは追加で
litellm_init.pth ファイルを含み、パッケージがインストールされているだけでPython起動時に 自動的にマルウェアが実行 された
.pth ファイルはPythonの site モジュールが起動時に自動実行する仕組みで、import キーワードの後に任意コードを実行できる- この仕組みはPython 2.1から 存在し、別途PEPなしで導入された
- FutureSearchチームが最初の被害を報告: uvxが自動で最新の litellm（バージョン未固定）をインストール した後、CursorがローカルMCPサーバーを自動ロードして感染が発生
攻撃経路とTeamPCPとの関連
- 攻撃は最近Trivyを侵害した TeamPCP グループと同一の攻撃者によるものと確認
- 侵害経路: Trivyのハッキング → CircleCI認証情報の全面流出 → PyPI公開トークン + GitHub PAT窃取 → 悪性パッケージ配布
- LiteLLMのCEO/CTOの GitHubアカウントも完全に乗っ取られ、個人リポジトリの説明がすべて "teampcp owns BerriAI" に変更され、Issueが閉じられるなどの行為が発生
- PYPI_PUBLISHトークンがGitHubプロジェクトの 環境変数として保存 されており、これがTrivy経由で流出した
- アカウントには 2FAが設定 されていたが、トークン自体が窃取されて回避された
- 攻撃者はGitHub Issueに数百の ボットアカウント で同一文言を繰り返し投稿し、実質的な議論を妨害
- Trivyリポジトリでも同様のパターンで 700件以上のスパムコメント が確認された
- スパムアカウントの一部は実際に貢献履歴のあるGitHubユーザーで、2月以降 "Update workflow configuration" コミットにより CIワークフローへ認証情報窃取器を挿入 した履歴が確認された
- Trivy侵害は 少なくとも5日前 に発生しており、最新の攻撃告知が前日に出たため、メンテナーが認識しないまま被害が発生した可能性がある
- 攻撃者は Internet Computer Protocol（ICP）Canisters もペイロード配信に利用しており、DNS遮断だけでは防御できない
悪性ペイロードの動作方式
- バックグラウンドのPythonプロセスを生成し、内蔵されたステージをデコードして実行
- 認証情報収集器 が実行され、データ収集に成功すると攻撃者のRSA公開鍵でAES鍵を暗号化し、窃取データを リモートホストへ送信 する
- マルウェア内で見つかったURL:
checkmarx.zone/raw と models.litellm.cloud
- 主に
~/.git-credentials のSSH鍵と暗号資産ウォレット情報 を窃取対象としていた
- CPU集約的な処理のためシステムに過負荷がかかり、かえって発見しやすくなっており、ファンの騒音で異常に気づいた事例も報告された
- Harborのインストール時にも同じ症状が発生:
grep -r rpcuser\rpcpassword プロセスがフォークボムのように実行され、暗号資産ウォレット探索 を試みた
LiteLLMチームの対応
- 影響を受けたバージョン（v1.82.7、v1.82.8）は PyPIから削除 済み
- すべてのメンテナーアカウントで パスワード変更、GitHub/Docker/CircleCI/pipの全キーを削除・交換
- 新しいメンテナーアカウントは @krrish-berri-2 と @ishaan-berri に置き換え
- PyPIではパッケージ全体が一時的に 隔離（quarantine） された後、感染バージョンの削除後に解除
- すべての新規リリースを 停止 し、サプライチェーン全体のレビュー完了まで配布を凍結
- Googleの Mandiant セキュリティチームと協力して調査と復旧を進行中
- Trivyは最後の安全版である v0.35.0 に固定（当初の v0.69.3 固定からコミュニティのフィードバックを反映して変更）
- 今後は Trusted Publishing（JWTトークンベースのOIDC） への移行、別個のPyPIアカウント利用などセキュリティ強化を検討
- 悪性バージョンの 最初の公開時刻はおよそUTC 8:30、PyPI隔離処理はおよそ UTC 11:25 だった
影響範囲とダウンストリームプロジェクト
- LiteLLMは DSPy の唯一のLLMプロバイダー呼び出しライブラリであり、CrewAI でもフォールバックとして使われている
- Airflow、Dagster、Unsloth.ai、Polar、nanobot などもLiteLLMに依存
- GitHub検索ベースで、requirements.txt にLiteLLMを バージョン未固定で含む プロジェクトが628件以上確認された
- 公式Proxy Docker配布経路の利用者は requirements.txt で バージョン固定 されていたため影響なし
- Docker配布では、ホストファイルシステムと環境変数へのアクセスが制限されているため相対的に安全だが、マウントされた認証情報は依然として危険
- 攻撃者の主目的は 個人SSH鍵 であり、LLMキーへのアクセスは副次的
- Harbor、browser-useなどLiteLLMを依存関係として自動インストールするツール利用者でも 間接被害 が報告された
- CrewAIは litellm を 1.82.6（最後の安全版）に固定 したが、コミットメッセージに侵害への言及はない
- DSPyは 公開Issueを作成 して対応中
- LangChainは独自のLLMプロバイダー呼び出しレイヤーを持つため 今回のサプライチェーン侵害の直接的影響はない（任意の langchain-litellm パッケージ利用時を除く）
コミュニティの議論: サプライチェーンセキュリティとサンドボックス化
- 依存関係と開発環境は もはや信頼できず、VM分離 + コンテナプリミティブ + 許可リスト + egressフィルタ + seccomp + gVisor などの 多層防御（defense in depth） が必要
- 過去50年間の セキュリティ上の便宜主義が揺り戻し を迎えており、セキュリティモデル全体の再設計が必要
- プログラミング言語レベル でモジュールごとのサンドボックス化が必要という意見
- Javaには1990年代の v1.2 からこの機能があったが、使い勝手の問題で廃止された
- Capabilityベース言語 を開発すべき時期だという意見
- Cloudflareの workerd ランタイムがモジュール分離可能な既存ソリューションとして言及された
- OpenBSDの pledge/unveil、Linuxの chroot/namespace/cgroup、FreeBSDの Capsicum など、OSレベルの分離ツールはすでに存在する
- Guixは 数秒で隔離コンテナ を生成でき、$HOME にアクセスせず依存関係をインストール可能
- Firejail と bwrap などユーザー空間分離ツールの積極活用が必要
- モバイルアプリの サンドボックス + 権限モデル（Intents） はすでに存在するが、デスクトップ環境では一般的な計算制限への反発が強い
- これに対し、Apple/Meta などの アプリストアの閉鎖性とセキュリティサンドボックスは別問題 であり、ユーザーに制御権を与えつつ安全性を確保するツール構築は可能だとの意見
- macOS向け canary/honeypotツール 公開（github.com/dweinstein/canary）: 偽のシークレットをWebDAV/NFSにマウントして異常アクセスを検知
- パッケージ公開とパブリックリポジトリの間に壁を設けるべき という意見: パブリックリポジトリを直接Trusted Publisherに設定すると攻撃面が広がる
- 反論として、Trusted Publishingの本来の目的は ソースと公開アーティファクトの監査可能なつながり を提供することであり、プライベートリポジトリ経由は後退だとする見解もある
実務的なセキュリティ勧告
- 依存関係は SHA256チェックサム付きでバージョン固定 が必須
- 内部 パッケージミラー を運用し、最新バージョンの直接利用を防ぐ
- ビルドアーティファクト を使い、
uv run などによる配布時のその場インストールに依存しないこと
- PyPI障害時にシステムが停止する構造的リスクも排除できる
- 配布可能なアーティファクトの利点: 監査可能性、迅速なロールバック、送信先ネットワークの危険なエンドポイント遮断が可能
- uvの
exclude-newer 設定により 一定期間以内の新規パッケージを除外 できる
- pyproject.toml に
[tool.uv] exclude-newer = "5 days" を設定可能
- CI/CDで公開トークンは OIDCベースのワークフロー に移行し、トークン自体をなくすことが根本的解決
- GitHubとPyPIはいずれもOIDCをサポートしており、公開作業にだけOIDCエンドポイントへのアクセス権を付与すれば、Trivy作業で窃取されるトークン自体が存在しない
- Trivyなどのセキュリティスキャンツールは 公開権限のない別ワーカー で実行すべき
- lockfile管理 と週次更新で最新バージョンの即時採用を避ける
- Pythonの
.pth ファイルは 自動コード実行 が可能であり、-S オプションで site import を抑制できるが互換性問題がある
- osv-scanner などを用いた プロジェクト全体の依存関係スキャン を推奨
- 感染有無の確認コマンド:
find / -name "litellm_init.pth" -type f 2>/dev/nullfind / -path '*/litellm-1.82.*.dist-info/METADATA' -exec grep -l 'Version: 1.82.[78]' {} \; 2>/dev/null
- パッケージマネージャー生態系全体での 認証情報一斉ローテーション（credential rotation） の必要性も提起された
SOC2監査と信頼性の問題
- LiteLLMのSOC2監査業者が最近物議を醸した Delve だった点が指摘された
- SOC2は「文書化されたプロセスに実際に従っているか」を確認するものであり、セキュリティ水準そのものを保証するものではない
- 適切なSOC2であっても今回のサプライチェーン攻撃を防げたかは不確実
LiteLLM代替プロジェクト
- Bifrost (github.com/maximhq/bifrost): Rustベースの代替、無料オープンソースインスタンスでも仮想キー設定が可能
- Portkey (portkey.ai): プロキシサービス、無料プランあり、LiteLLMより高速との評価
- pydantic-ai: Pythonベースの代替
- any-llm (github.com/mozilla-ai/any-llm): Mozillaのプロジェクト
- LLM Gateway (llmgateway.io): LiteLLM向け移行ガイドを提供
- InferXgate (github.com/jasmedia/InferXgate): 新規プロジェクト、対応プロバイダーは限定的
- 一部開発者は、LLMプロバイダーAPIは実質的に OpenAIとAnthropicの2種類 しかないため、直接
requests.post() で呼ぶほうが安全だという立場
- 反論として、AnthropicのOpenAI互換APIは 長期的・本番向けソリューションとしては推奨されず、ベンダーごとのネイティブAPIにはOpenAI APIへマッピングされない固有機能が存在する
1件のコメント
Hacker Newsの意見
LiteLLMのメンテナーです。現状はまだ調査中ですが、ここまでに把握している内容は次のとおりです
requirements.txtでバージョンを固定していたためです現在、原因分析とセキュリティ強化策を検討中であり、ご不便をおかけして申し訳ありません
.venv、uv、システム環境をすばやくスキャンできるそうです私たちは依然として依存関係と開発環境を信頼できません。dev containerは隔離が不十分で、使い勝手もよくありません。今こそsandboxベースの開発環境へ移行すべきです。VMレベルの隔離、egressフィルタ、seccomp、gVisorのような防御層を備えた環境が必要です。そうした環境なら、侵害が発生してもコンテナはすぐ終了し、問題を容易に特定できます
macOS向けに作ったcanaryツールの紹介です（リンク）。パッケージがアクセスしてはいけないファイルを検知するシンプルなGoバイナリです。WebDAVやNFSで偽の秘密情報を公開し、アクセス時に通知を送ります。honeypotアプローチで異常な挙動を検出できます
ここ数週間のTeamPCPの活動に関連する事件です。私がまとめたタイムラインが役立つと思います
GitHubのスパム検知システムが弱すぎるという指摘がありました。litellmのissueに170件以上のスパムコメントが付いたそうです
こういうことはいつか起きると予想していました。依存関係のバージョン固定で防ごうとしてきましたが、それでも完全ではありません。オープンソースのサプライチェーンの複雑さのため、すべてのコードを検証するのは不可能です。LLMのおかげで悪意あるコードが大量に拡散するリスクは100倍になりました
もしAIが書いたコードがLLVMやLinuxに入り込んだら、私たちは本当の意味で「trusting trust」問題に直面することになります
curl | bashを実行します。XZバックドア事件は、こうした現実を思い出させる事例でしたLiteLLMのSOC2監査機関がDelveだったことが言及されていました。
Harborをインストールしたところ、CPUが100%まで跳ね上がってシステムが止まりました。
grep -r rpcuser\rpcpasswordプロセスが暗号通貨ウォレット探索を試みたようです。幸い、バックドアはインストールされませんでした今回の事件は、TrivyをハッキングしたTeamPCPと同じ攻撃グループの犯行のようです。issueにボットコメントがあふれているのも同じパターンです。LLMを活用した自動化攻撃である可能性が高いです