litellm v1.82.8 サプライチェーン攻撃｜PyPI汚染、認証情報窃取と代替ライブラリまとめ

2026年3月、広く使われているLLMラッパーライブラリ litellm のPyPIパッケージが汚染された。影響バージョンはv1.82.7とv1.82.8で、クレデンシャル窃取マルウェアが仕込まれていた。

攻撃の仕組み

v1.82.7: importで実行

v1.82.7ではマルウェアが proxy/proxy_server.py に仕込まれており、import litellm を実行した時点でトリガーされた。

v1.82.8: インストールで実行（より危険）

v1.82.8では litellm_init.pth ファイルを利用するように進化した。

# litellm_init.pth の仕掛け
# Pythonは .pth ファイルをsite-packages読み込み時に自動実行する
# → pip install だけで import 不要にマルウェアが起動する

.pthファイルはPythonのsite-packagesにある設定ファイルで、Pythonインタプリタ起動時に自動処理される。つまり pip install litellm==1.82.8の実行だけで感染する。コードで一切importしていなくても被害を受ける可能性がある。

窃取対象の認証情報

Simon Willisonの分析によれば、マルウェアが標的にしたのは「bewildering array of secrets（驚くほど多数の秘密情報）」だ。

ホームディレクトリ以下のほぼすべての認証情報が対象となっていた。

攻撃の起点: Trivy経由のサプライチェーン

攻撃の起点はlitellmではなく、Trivyセキュリティスキャナーへの攻撃だったとされている。

Trivyの脆弱性悪用
    → litellmのCI/CDで使用されていたTrivyのPyPI認証情報を窃取
    → 窃取した認証情報でlitellmのPyPIパッケージに直接バックドア注入

皮肉なことに、セキュリティツールへの攻撃が下流パッケージへの侵害につながった。

対応状況

• PyPIはv1.82.7、v1.82.8を隔離済み
• 汚染ウィンドウは数時間程度
• 該当バージョンをインストール済みの場合は全認証情報のローテーションが必要

確認方法：

pipshowlitellm|grepVersion

v1.82.7またはv1.82.8だった場合は即座にアンインストールし、上記の認証情報をすべて更新すること。

安全な代替ライブラリ

コミュニティが提案している主な代替：

1. Bifrost（推奨）

pipinstallbifrost-gateway

• Go製（Apache 2.0ライセンス）
• P99レイテンシがlitellmの約50倍高速
• 20以上のプロバイダーをサポート
• litellmからの移行はbase URL変更のみ

# Before (litellm)
importlitellm
response = litellm.completion(model="gpt-4", messages=[...])

# After (Bifrost) - base URL変更のみ
# openai clientのbase_urlをBifrostエンドポイントに変更するだけ

2. Kosong（Kimi製）

• Kimi CLIで使われているLLM抽象化レイヤー
• エージェント指向設計
• OpenAI、Anthropic、Google Vertexなどのフォーマットをサポート
• 非同期ツールオーケストレーション対応

3. Helicone

• 100以上のプロバイダーをサポート
• 可観測性とデバッグ機能が強み
• BifrostやKosongより機能が多い分、重め

わさびの見方

.pthファイルを利用した攻撃は特に狡猾だ。「importしなければ安全」という常識的な判断が通じない。pip installの時点でアウトになる。

この攻撃がCIで実行されていたケース（テストパイプラインでpip install litellmを実行するだけで感染）は、開発者がなぜ感染したのか気づかないまま被害が拡大するシナリオが怖い。

Trivyというセキュリティツール自体が攻撃の起点になったという点も重要な示唆を含んでいる。セキュリティスキャナーも信頼できるとは限らない。依存関係のチェーン全体を疑う必要がある。

BifrostのようなGo製の代替が出てきているのはプラスな動きだ。litellmはPythonのPyPIエコシステムに依存しているが、Goはパッケージ管理の仕組みが異なり、こうした.pthスタイルの攻撃は機能しない。

ソース

• Malicious litellm_init.pth in litellm 1.82.8 — credential stealer – Simon Willison
• After the supply chain attack, here are some litellm alternatives – r/LocalLLaMA

この記事を書いたのは わさび（ニホンイシガメ / 3歳 / VTuber[あかはら。]の家族）
AI・セキュリティの最新情報を「はやく・わかりやすく」日本語でお届けしています。
著者プロフィール ｜ あかはら vlab トップ

わさびの見解

わさびです。litellmのサプライチェーン攻撃、Trivy経由でPyPI直撃とは皮肉すぎる。2025年12月からClaude Codeでakahara-vlabのパイプラインを回し始めて、Python依存が山ほど増えた身として、身震いした。うちのcarasiAIやZariaSystemでもlitellm似のLLMラッパー使ってるが、幸いpip install前にTrivyでスキャン入れてたおかげで回避。v1.82.8の.pthトリックは凶悪で、importすら不要で感染するなんて、ホームディレクトリ丸ごと狙われてる。

実際、AI自動化を並行運用してるわさびの実感は、依存ライブラリのセキュリティ管理が命。Claude Codeで10数プロジェクト回す中で、pip-auditやDependabotをCIに組み込んで、毎日チェックしてる。Sonnetでコード生成加速しても、供給チェーン弱いと一瞬で全滅だ。AIを使えるエンジニアとそうでない乖離は、ここで決まる。自動化のスピード勝負なのに、セキュリティ甘いと逆転負け。

皆も今すぐpip list | grep litellmで確認して、litellm-proxyやOpenLLMに乗り換えを。自分のパイプライン、Trivy信じすぎてないか？