AI接続ソフトLiteLLMの配布版が汚染、約2時間公開で認証情報窃取

何が起きたのか

LiteLLMは100を超える生成AIのサービスを同じ形で呼び出せるオープンソースのソフトです。2026年10月21日、マルウェア入りの1.107.0が公開されました。公開されていたのは世界時でPyPI（Pythonの部品の配布サイト）が11時39分から13時23分まで、Dockerのイメージが11時46分から14時20分までです。GitHubのコンテナレジストリ（GHCR）の同じ名前のイメージも、11時46分から13時51分までは取得できました。

GitHubの公式のソースコードに不正なファイルはありません。このバージョンは、攻撃者が用意した名前の似た別のリポジトリから作られていました。

同社が10月23日に出した原因の分析を、時系列にまとめます。

• 5月27日：社内の実験的な基盤（エージェントの実行基盤）の管理キーが入った設定ファイルが、誤って公開リポジトリに入りました。約3時間後に別のコミットで消しましたが、元のコミットは10月22日まで公開の履歴に残り、キーは無効にされていませんでした。
• 10月10日：攻撃者がこのキーで基盤にアクセスし、設定の一覧から、GitHub組織のオーナー2人のうち1人のトークンを手に入れました。続いて、このトークンを使ってCI（自動の検証の仕組み）の中に、機密情報を外部へ送る処理を仕込みました。
• 10月21日：リリース用のリポジトリの設定を、別の組織のコードも取り込めるように書き換えました。ブランチの保護はいったん拒まれましたが、オーナーの権限で保護を外して反映しています。リリースの承認の条件は攻撃の週に緩められており、盗んだ別々のメンテナーのトークンで、実行と承認の両方を通しました。
• 同じ日の世界時の11時台から12時台：自分の痕跡になる実行記録を消し、変更を元に戻す操作もしています。

不審に気づいたのは、外部のセキュリティ研究者の報告でした。公開の約20分後です。

漏れた情報

マルウェアはPythonが起動するたびに動き、認証情報を盗むほか、遠隔からプログラムを動かす仕組みを読み込みます。同社は、外部へ通信できる環境で動いたなら、情報は盗まれたものと考えるよう求めています。影響を受けた組織の数は公表されていません。

自社の環境が影響を受けたかは、次で確かめます。

• pip show litellm でバージョンが1.107.0でないか
• コンテナが、公表されたダイジェスト（イメージの識別値）の不正なイメージで動いていないか
• ファイルシステムに cook.pth、sitecustomize.py、cook.py が見つからないか、/tmp/remote_code_loader.lock がないか

これらが見つかれば影響を受けています。見つからなくても、環境が無事だという証明にはならないと同社は書いています。ほかのバージョンと、同社の企業向けの非公開レジストリは対象外です。

会社の対応

同社は不正なバージョンを取り下げ、署名の鍵を交換しました。PyPIは13時23分までにファイルを隔離しています。GitHubの権限もいったんすべて外し、内部のシステムとベンダーのサービスに関わるトークンはすべて無効にしました。すべて盗まれたものとして扱っています。

影響を受けた環境で同社が案内する順番は、次のとおりです。

1. 先に pip install を動かさない。Pythonが起動するたびにマルウェアが動くため、まず不正なファイルを消します
2. cook.pth、cook.py、sitecustomize.py と、対応するキャッシュのファイルを消し、/tmp/remote_code_loader.lock を持つバックグラウンドのPythonのプロセスを止める
3. 1.106.2に固定して入れ直す。イメージも仮想環境も、作り直すほうが確実です
4. 環境から届く認証情報をすべて替える。クラウドの権限、LiteLLMのプロキシに登録した各AIサービスのキー、マスターキー、データベースのパスワード、環境変数にあった秘密情報が対象です

安全なバージョンとして1.106.2が挙げられています。1.107.0のイメージには、当時の鍵の有効な署名が付いているため、署名だけで安全とは判断できません。新しい鍵で署名したイメージは、10月24日以降のリリースから出ています。

日本の会社に関係すること

自社で開発していなくても、委託先が作ったAI機能や社内ツールの中で使われている場合があります。バージョンを固定せずに取り込むと、公開中の短い時間でも不正なバージョンが入ります。pip install litellm のように版を指定しない入れ方や、コンテナの latest タグを自動で取り込む設定は、この事故のような場面では危険です。確認したバージョンに固定し、更新するときに人が確かめる流れにします。

この事故から学べる大きな点は、キーを消すだけでなく無効にすることです。公開リポジトリに入れてしまったキーは、履歴から消えるまでの間に複製されている前提で、すぐに失効させて新しいものに替えます。