LiteLLMの公開配布プロセスが侵害され、悪意あるコードを含むパッケージと、隔離された実行環境を収めたファイルであるコンテナイメージが一定時間配布された。該当時間にこれらをインストールまたは実行した利用者は、環境をクリーンアップし、ホストがアクセスできたシークレットを更新する必要がある。企業顧客向けの非公開配布は今回の影響対象ではないと同社は述べた。

1. 汚染されたパッケージとイメージの範囲

同社が2026年10月21日に公開した報告書によると、PyPIのLiteLLM 1.107.0のインストール用パッケージであるwheel、Pythonインストール用の圧縮配布ファイル7個がすべて汚染された。悪意あるコードには、システムへのアクセスを証明する情報である認証情報を盗み、ネットワーク越しにコードを実行するリモートコード実行ツールを読み込む機能が含まれていた。同社は以前のバージョンは安全で、影響を受けた配布物を撤回したと述べた。

コンテナではDocker HubとGHCRのv1.107.0とlatestタグが影響を受けた。タグはダウンロードするイメージを指すラベルだ。

main-latestとmain-stableタグも汚染されたイメージを指していた。

GHCRでは基本イメージのほか、litellm-databaseとlitellm-non_rootイメージも影響対象だった。

公式GitHubの1.107.0ソースタグには悪意あるファイルはなく、汚染された配布物は攻撃者が管理する別のリポジトリで作られた。

2. リポジトリごとの露出時間でインストール履歴を確認

同社の報告書の時刻はすべて2026年10月21日のUTC、協定世界時基準だ。

表：リポジトリごとの汚染配布物の公開・削除または確認時刻

条件：2026年10月21日、影響を受けたパッケージとイメージタグが対象

単位：UTC時刻

リポジトリごとの露出時間でインストール履歴を確認
リポジトリ公開開始削除または確認時刻終了時刻の意味
PyPI11:39:5113:23この時刻までに問題のバージョンを削除
Docker Hub11:46:5614:20影響を受けたタグとイメージの派生版を削除、または検証済みの正常な配布物への再接続を完了
GHCR11:46:5613:51影響を受けたタグが利用不可であることを確認した時刻であり、実際の削除時刻ではない

リポジトリごとに対応完了時点が異なるため、使用した配布物のインストール・実行履歴をそれぞれ照合する必要があり、GHCRの確認時刻を確定した露出終了時刻とみなしてはならない。

同社はバージョンを固定せずに11:39~13:23にインストールした利用者に、影響を確認するよう案内した。

同社は、PyPIの11:39:51~13:23の時間帯に問題のバージョンをインストールした場合や、Docker Hubの11:46:56~14:20の時間帯に汚染されたイメージを実行した場合は、環境が侵害されたとみなすよう勧告した。GHCRの影響を受けたタグは13:51に利用不可であることが確認されたが、実際の削除時刻は確認されていない。当面は1.106.2またはそれ以前に公開された明示的なバージョンに固定するよう案内している。

3. Pythonを再起動する前に悪意あるファイルを削除

復旧はシェルで悪意あるファイルを削除することから始める。影響を受けた環境でPythonが起動すると悪意あるコードが再び実行される可能性があり、pipの実行もPythonを起動するためだ。

同社の勧告に従い、影響を受けた各インストールディレクトリからcook.pthとcook.pyを削除する。

sitecustomize.pyと関連するバイトコードキャッシュ、Pythonコードを変換して保存したファイルも削除する。

続いて、/tmp/remote_code_loader.lockを保持している、バックグラウンドで実行中のPythonプロセスを終了する。クリーンアップ後にインストール済みバージョンを確認するコマンドは次のとおりだ。

pip show litellm

その後、1.106.2に固定して再インストールする。同社はイメージと仮想環境は最初から作り直す方がよいと勧告した。

問題のバージョンが外部と通信可能なホスト、ネットワークに接続されたコンピューターにインストールされた場合、同社は情報流出が成功したとみなすよう求めた。そのホストがアクセスできたインスタンス・タスクロールの認証情報（サーバーや実行タスクに付与されたアクセス権限を使う認証情報）、プロキシデータベースのプロバイダーキーと管理・仮想キー、データベース接続パスワードとプロセス環境のシークレットを更新する必要がある。

同社はクラウドの活動記録サービスであるCloudTrailで、インストール時点の前後に呼び出し元の身元を確認するGetCallerIdentity呼び出しがあったか確認するよう案内した。続いて、そのロールの認証情報が利用者のインフラ外部で使われたか調べるよう勧告した。

4. 盗んだ権限で正規の公開手順を悪用

同社は3月の事故後、配布ファイルを管理する場所であるリリースリポジトリを非公開に移し、所定のワークフローと信頼された公開機能を導入した。イメージタグを変更できなくし、イメージに署名する措置も取った。正規の手順は、コード変更をまとめて記録した単位であるコミットのうち、テストに合格したものから配布物を作り、別のジョブで公開する方式だった。

しかし月曜日、顧客向けバグ修正版の配布のため、社内エンジニア2人の権限を一時的に拡大した。同社によると、攻撃者は開発者3アカウントのGitHub CLI認証情報を入手し、そのうち組織所有者のトークンで保護設定を無効にし、ワークフローを変更した。

攻撃者は公開ジョブが正規のリポジトリBerriAI/litellmではなく、類似した名前のBerri-AI/litellmを参照するようにした。同社の時系列によると、2番目の開発者アカウントの認証情報は本番配布の承認段階を通過するために使われた。盗まれた認証情報はソース変更だけでなく、公開承認段階にも使われたのだ。改ざんされたワークフローは汚染された配布物に署名し、公開した。署名が付く段階の前に作成経路が変更されたことになる。

同社によると、特定の状況でClaude Codeの応答に、アプリへのアクセス権限を委任する認証値である利用者のGitHub CLI OAuthトークンが含まれ、応答を記録すると社内サービスのログにも残る可能性がある。同社は攻撃者がインターネットに露出した社内のデプロイ環境にアクセスし、ログからトークンを入手したとみている。

5. 配布物の撤回後も残る利用者の復旧作業

配布物の撤回と正常なイメージへの再接続は、新たにダウンロードする経路をクリーンアップする措置だ。同社は調査中、メンテナーの認証情報を必要最小限の水準まで取り消した。利用者はそれとは別に、インストール・実行環境をクリーンアップして再構築し、アクセス可能だったシークレットを追跡して更新する作業を担うことになった。

同社は最初の社内アクセス経路をまだ特定できておらず、最近修正した脆弱性を疑っていると述べた。また、コンテナや一時ファイルのクリーンアップで痕跡が消える可能性があるため、悪意あるファイルや流出の痕跡を示すファイルがないという事実だけでは環境が安全だと判断できない。

今回の事故での利用者の対応は、配布物の撤回の有無よりも、露出時間帯のインストール・実行履歴とアクセス可能だったシークレットを最後まで追跡することにかかっている。