LiteLLM 1.107.0の改ざん版 入れた環境の調べ方と鍵の交換

社内のAIアプリで、OpenAIやAnthropic、Geminiなど複数のモデルのAPIをまとめるゲートウェイとしてLiteLLMを使っている。あるいは、開発者の端末やCIで、依存のどこかにLiteLLMが入っている。そうした環境は、10月下旬に配られた改ざん版の影響を確かめる必要があります。

LiteLLMの告知によると、改ざんされた1.107.0は2026年10月21日、PyPIで約2時間（協定世界時11時39分〜13時23分、日本時間20時39分〜22時23分）公開され、公式のコンテナイメージでも配られました。Microsoftも10月23日（米国時間）に詳しい分析を公開しています。厄介なのは、アプリがLiteLLMを読み込まなくても、その環境でPythonを起動するだけで不正なコードが動く点です。LiteLLMのゲートウェイを動かしていない開発者の端末やCIのランナーも対象になります。

この記事では、LiteLLMの告知とMicrosoftの報告をもとに、仕組み、影響を受けた配布物と期間、影響を受けた環境の探し方、見つかった場合の対応の順番を整理します。

何が起きたか

LiteLLMが10月23日に公表した調査結果によると、発端は、2026年5月27日に公開のリポジトリへ誤ってコミットされた、社内の実験的なサービス（LiteLLM Agent Platform）の管理用のキーでした。このキーは失効されないまま残っていました。攻撃者は10月10日にこのキーでサービスに入り、そこに設定されていた、GitHubの組織のオーナーのGitHub CLIのトークンを取り出しました。さらに、CIのワークフローを使ってほかの2人の保守担当者のトークンも盗みました。

そのうえで攻撃者は、オーナーのトークンでブランチの保護を越えてリリースのワークフローを書き換え、正規の BerriAI/litellm ではなく、よく似た名前の Berri-AI/litellm から作るようにしました。リリースの開始と承認には、別々の担当者のトークンを使いました。その週は、バックポートのリリースを増やすため、承認の制限を一時的に緩めていたとしています。Microsoftの報告も、保守担当者の説明として同じ流れを引用しています。ただし、最初の侵入経路はMicrosoftとしては独自に確かめていない、としています。

LiteLLMは、2026年3月にも別の版（1.82.7・1.82.8）が改ざんされています。その経緯は2026年サプライチェーン攻撃まとめで扱いました。今回は別の版、別の経路による事案です。

影響を受けた配布物と期間

LiteLLMの告知が挙げる対象は次のとおりです（いずれも10月21日、協定世界時）。

告知は、この時間に版を固定せずにpipでLiteLLMを入れた場合と、この時間にこれらのタグのイメージを使った場合を対象としています。latest のように版を書かないタグで取得したイメージも含まれる点に注意が要ります。Docker Hubと ghcr.io/berriai/litellm の改ざんされたイメージのダイジェストは sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e です（litellm-database と litellm-non_root の値は告知を参照してください）。Enterpriseの顧客向けのプライベートなレジストリから取得している場合は影響を受けていない、とされています。

GitHubの v1.107.0 のタグのソースには不正なファイルは含まれておらず、改ざんされたのは攻撃者のリポジトリから作られた配布物だ、とLiteLLMは説明しています。また、1.107.0より前の版は安全だとしています。

編集部が2026年10月29日にPyPIの公開情報（JSON API）を確認した時点で、1.107.0は公開版の一覧になく、最新の正式版は10月28日公開の1.106.6でした。1.107.0の開発版・候補版（1.107.0.dev1〜dev3、rc1・rc2）は一覧に残っています。新しくインストールし直せば1.107.0が入ることはありませんが、すでに入れた環境、キャッシュ、社内のミラー、作り済みのコンテナイメージには残っている可能性があります。

LiteLLMを使わなくても動く仕組み

改ざん版のwheelには、cook.pth・cook.py・sitecustomize.py の3つのファイルが含まれていました。インストールすると、これらはLiteLLMのフォルダではなく、Python環境のライブラリの置き場（site-packages）の直下に置かれます。

Pythonは起動時の初期化で、site-packagesにある .pth ファイルを読み、import で始まる行を実行します。その後、sitecustomize というモジュールがあれば読み込みます。改ざん版はこの2つの仕組みを使っていました。

• cook.pth の1行（import cook）が cook.py を読み込み、資格情報を集めるプログラムを裏で動かす
• sitecustomize.py は、Unix系の環境で、外部のサーバーから追加のPythonのコードを取得して実行する仕組みを持つ（報告の時点で、取得と実行は確認されていない）

報告は、Windowsで、無関係な依存をインストールするためにPythonを起動しただけで収集のプログラムが動いた例を挙げています。そのため、影響を受けたかを確かめる目的で、疑わしい環境でpythonやpipを実行してはいけない、と強調しています。

編集部の環境で仕組みを確かめた

編集部は、この起動時の仕組みを、無害なファイルで確かめました。Linux上のPython 3.11.17の仮想環境のsite-packagesに、import demo_hook の1行だけを書いた demo.pth と、実行されたことをファイルに記録するだけの demo_hook.py、空のパッケージのフォルダを置きました。

• python -c "pass"、pip --version、python -c "import json" のいずれでも、記録が1行ずつ増えた。パッケージを読み込まなくても動いた
• パッケージのフォルダを消した後も、python -c "pass" で記録が増えた。site-packages直下のファイルは残る
• python -S（siteの初期化を行わない）では記録は増えなかった

あわせて、同じ仮想環境のsite-packagesには、setuptoolsが置く正規の distutils-precedence.pth があり、これも import で始まる行を持っていました。import を含む .pth があること自体は不正の証拠にならず、報告も、ファイル名やパッケージの有無だけで判断しないよう求めています。

入った環境を探す

報告は、LiteLLM 1.107.0をインストールした、ミラーに取り込んだ、またはイメージに組み込んだ組織に、すべての複製を見つけて封じ込めるよう求めています。探す場所として挙げているのは、インストール済みの環境、uvとpipのキャッシュ、社内のパッケージのミラー、ロックファイル、ビルドの成果物、コンテナイメージです。

疑わしい環境のPythonを起動せずに探すには、たとえば次のように、ファイルとロックファイルを外から調べます。パスは環境に合わせて変えてください。

# site-packages の直下に、報告にある3つのファイル名や 1.107.0 の記録があるか（Python を起動しない）
find / -path '*site-packages/*' \
  \( -name 'cook.pth' -o -name 'cook.py' -o -name 'sitecustomize.py' \
     -o -name 'litellm-1.107.0.dist-info' \) 2>/dev/null

# requirements 系のファイルで 1.107.0 を固定していないか
grep -rnE 'litellm[^0-9]*1\.107\.0' --include='*.txt' --include='*.in' .

# uv.lock・poetry.lock では、名前の次の行に版がある
grep -rn -A1 'name = "litellm"' --include='uv.lock' --include='poetry.lock' .

編集部は、上の3つのコマンドを、検証用に作ったファイル（空の cook.pth、版を1.107.0にしたrequirements.txtとuv.lock）でLinux上で試し、それぞれ見つかることを確かめました。litellm-1.107.0.dist-info の条件は公開前に追加したもので、空のフォルダを作ってmacOS上で見つかることを確かめています。LiteLLMの告知は、これらのファイルが見つかれば影響を受けたと確定できる一方、見つからなくても安全だという証明にはならない、としています。sitecustomize.py は、正規の用途で置かれている場合もあります。見つかったファイルは、報告に掲載されたSHA-256の値と照合してください。コンテナイメージは、書き換えられるタグではなく、内容から決まるダイジェストで特定し、報告の値と比べるよう求められています。

なお、LiteLLMの告知には pip show litellm で確かめる方法も書かれています。しかし、pipを起動するだけでも cook.pth が動くため、この記事ではMicrosoftと、最初に報告したUpwindの研究チームの勧めに従い、疑わしい環境の外から調べる方法を示しました。依存の監査の道具を使う場合は、GitHub Advisory Databaseの悪性パッケージの項目（GHSA-92x9-889m-jgmw）の対象に1.107.0が含まれています。

見つかったときの順番

報告が示す対応を、順番が分かるように並べます。

1. 隔離して、Pythonを止める: 開発者の端末、ビルドのエージェント、試験の環境、コンテナ、AIゲートウェイのホストを隔離し、動いているPythonのプロセスを止め、自動で再起動しないようにする。証拠を集めるときも、その環境のpythonやpipを使わず、汚染されていない別の機械から信頼できる道具で調べる
2. 確かめた成果物から作り直す: 3つのファイルがライブラリの置き場から消えたことを確かめる。litellmのフォルダを消しただけで済んだと考えるより、作り直すほうが確実だとしている。作り直すときの版は、版を明示して固定する（下の「作り直すときの版」を参照）
3. 届いた資格情報を、汚染されていない機械から変える: モデルのAPIキー、クラウドとワークロードの資格情報、CI/CDの秘密情報、ソースコード管理やレジストリのトークン、SSHとGPGの鍵、AIコーディングツールのトークン、ブラウザのセッション。ゲートウェイのホストでは、保管しているモデル事業者の資格情報と DATABASE_URL も含める。LiteLLMの告知は、プロキシのマスターキーと仮想キーも挙げている。鍵を変えるだけでなく、セッションの失効も行う
4. 判断の前に突き合わせる: ファイルのハッシュ、Pythonのプロセスの親子関係、.pc_e_ で始まる一時フォルダでの暗号化、通信先、ワークロードの識別情報、その後のクラウドや認証での利用を合わせて判断する。ただし、外部と通信できる環境に1.107.0を入れたことがあるなら、送信は成功したものとして扱うよう、LiteLLMの告知は求めている

報告によると、収集のプログラムが狙ったのは、AIアシスタントやIDE、GitHub Copilot、VS Code、MCPの連携の設定、Gitの資格情報、.env ファイル、AWS・Azure・Google Cloudの資格情報、Kubernetesのサービスアカウント、ブラウザの保存データ、SSHの鍵、そして同じホストのほかのプロセスの環境変数（Linux）などです。LiteLLMのプロキシが使うデータベースからも、資格情報とモデルの設定の一部を読もうとしていました。ゲートウェイは複数のモデル事業者の鍵を1か所に持つため、交換の対象は広くなります。

作り直すときの版

LiteLLMは10月21日の時点で、1.106.2か、それ以前の版を明示して固定するよう案内していました。その後の10月27日に、別の脆弱性のアドバイザリ（GHSA-w4c7-34wj-hqm8、重大度はcritical）が公開されています。Enterpriseのライセンスで動かすプロキシで、認証なしにローカルのファイルを読まれ、マスターキーなどが漏れるおそれがあるというもので、修正版は1.106.5です（1.103.10・1.104.8・1.105.6にも修正が入っています）。ライセンスのないオープンソース版は対象外とされています。Enterpriseのライセンスを使っている場合は、1.106.2で止めず、1.106.5以降（または上の各系列の修正版）にしてください。

次の改ざんに備えて

報告は、今後の対策として、ハッシュで固定したロックファイル、パッケージとイメージの出どころの確認、タグではなくダイジェストでのイメージの指定、確認を経たパッケージだけを社内のミラーに入れること、開発者の端末・ビルドのエージェント・AIゲートウェイのホストの外向きの通信を必要な宛先に絞ることを挙げています。

公開直後の版をすぐに取り込まない設定（クールダウン）は、pipの依存のクールダウンで扱いました。また、モデルの鍵をゲートウェイに集める設計の利点と注意は、社内AIにゲートウェイを1枚挟むかで整理しています。ゲートウェイを置く場合は、そのホストが保管する鍵の一覧と、交換の手順を前もって用意しておくと、今回のような事案で慌てずに済みます。

確認した範囲

2026年10月28日に、Microsoft Security Blogの報告「Inside the LiteLLM 1.107.0 supply chain compromise」（2026年10月23日）と、PyPIのJSON APIでLiteLLMの公開版の一覧を確認しました（資料調査）。公開前の2026年10月29日に、LiteLLMの告知（10月21日のインシデントの記事と、10月23日の攻撃の経緯の記事）、GitHubのissue #47826での保守担当者の報告、GitHub Advisory Databaseの項目、PyPIの公開版の一覧を確認し、配布物と期間、経緯、作り直すときの版を書き足しました。Microsoftの報告は、10月29日には編集部の環境から開けなかった（HTTP 403）ため、Microsoftの報告にもとづく記述は10月28日に確認した内容です。.pth による起動時の実行は、無害なファイルを使い、Linux上のPython 3.11.17の仮想環境で確かめました（実機検証）。改ざん版そのものは入手・実行していません。

AIアプリの依存や資格情報の管理の見直しは、開発・AI・自動化のご相談からお問い合わせください。

参考資料

• Inside the LiteLLM 1.107.0 supply chain compromise: Credential theft through Python startup hooks（Microsoft Security Blog、2026-10-23）
• Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised（LiteLLM、2026-10-21）
• The attack chain behind the v1.107.0 LiteLLM release（LiteLLM、2026-10-23）
• BerriAI/litellm issue #47826（GitHub）
• GHSA-92x9-889m-jgmw: Malicious code in litellm（GitHub Advisory Database）
• GHSA-w4c7-34wj-hqm8: Unauthenticated file read leaks master key on Enterprise proxy（BerriAI/litellm）
• litellm（PyPI）