LiteLLM 1.107.0：侵害されたPythonを再起動せずにアーティファクトの影響範囲を調べる

概要

2026年10月25日時点の情報である。LiteLLMのインシデント告知では、10月21日に公開された1.107.0が悪意あるリリースとして特定されている。復旧前に、この告知と正式な根本原因報告を再確認する。本稿は、10月23日21:50 UTC付の告知の訂正、10月23日公開の根本原因報告、およびOSVの更新日時である10月21日22:01:01 UTCの記録に基づく。

ベンダーの告知による配布期間は、いずれも10月21日のUTCで、PyPIのwheelが11:39:51–13:23、Docker Hubが11:46:56–14:20、GHCRが11:46:56から遅くとも13:51に取得できなくなるまでである。コンテナのタグはv1.107.0、latest、main-latest、main-stableだった。キャッシュに残ったコピーは、この期間が過ぎてから実行されることもある。

重要な理由

OSV MAL-2026-2144には、アプリケーションがLiteLLMをインポートしなくても、Pythonの起動によって認証情報の窃取とリモートコードローダーが作動すると記載されている。この記録は以前のインシデント資料と10月の調査結果をまとめたものである。OSVの広範なバージョン記載を全リリースが悪意あるものだと解釈せず、ベンダーが示すアーティファクトの対象範囲に従う。

当初のデプロイログを原因とする説は、正式な調査報告が示す説明に置き換えられた。漏えい後も失効していなかったマスターキーで別のエージェントサービスにアクセスでき、そのサービスがオーナーのGitHubトークンを返した。盗まれたIDが、その後のリリースプロセスの侵害に使われた。このため、パッケージの置き換えとともに、リポジトリとアカウントの復旧も重要となる。

適用方法

• 影響を受けたマシンを隔離し、公開を一時停止する。ロックファイル、インストール記録、イメージ参照、CIログを保全する。アーティファクトがダウンロード、インストール、実行のどの段階まで進んだかを記録する。現在の依存関係の一覧から、削除された環境の状態を復元することはできない。
• ファイルシステムの読み取り専用コピーを、信頼できるツールで調べる。例えば、find /mnt/evidence -type d -name 'litellm-1.107.0.dist-info'なら、疑わしいインタープリターを起動せずにインストール済みメタデータを見つけられる。cook.pth、cook.py、sitecustomize.pyをアドバイザリの侵害指標と照合する。一般的なファイル名だけでは、内容が悪意あるものだとは判断できない。
• 信頼できる管理環境からdocker image inspect IMAGE_IDを実行し、保存されたローカルイメージのメタデータを調べる。GHCRの正しいバリアントも含めて、レジストリのダイジェストをベンダーの告知と照合する。変更可能なタグの現在の値では、以前のコンテナが何を実行していたかは分からない。レジストリのダイジェストに関するメタデータがなければ、デプロイ記録またはレジストリの記録が必要になる。
• 疑わしい環境内でpipやPythonを実行しない。クリーンな入力から再構築する。ベンダーがこのインシデントの復旧用に指定した固定バージョンはlitellm==1.106.2であり、新規の環境に限り、python3 -m pip install 'litellm==1.106.2'でそのバージョンを指定できる。接続を戻す前に、依存関係全体と最新のアドバイザリを確認する。
• クリーンなマシンから、アクセス可能だった認証情報を失効させて置き換える。対象は、公開とリポジトリの認証情報、クラウドへのアクセス、データベースのパスワード、プロバイダーのキー、アプリケーションのシークレットである。漏えいが起きた可能性のある最も早い時点以降の利用状況を調べる。サービスを復旧する前に、置き換え後の環境で記録したアーティファクトを、承認済みの復旧用入力と照合する。

落とし穴

パッケージをアンインストールしても、認証情報の窃取を取り消すことはできず、永続化の仕組みが消えた証拠にもならない。一時的な痕跡が見つからなくても、安全とは判断できない。復旧用の固定バージョンは、このインシデントへの対応であり、無関係なすべての脆弱性に対処するものではない。恒久的な安全性の保証とせず、再確認する必要がある。