複数のAIモデルをつなぐ「ゲートウェイ」LiteLLMに、なぜ侵入できたのか。盗まれたGitHub認証情報と起動フックの手口を確かめる

まず初めに

正規のLiteLLM 1.107.0として配布されたパッケージに、Python起動時に動く不正な処理が含まれていた。普段の開発作業でも起動し得るため、影響範囲はLiteLLMを直接呼び出すアプリだけではない。LiteLLMの10月23日の確定報告は配布経路の侵害を、Microsoftの調査はパッケージ内の処理と一部端末での観測を説明している。コードが情報を収集・送信できることと、全利用者から実際に窃取したことは分けて確認する必要がある。

※個人の感想です

何が起きているのか

Microsoft Threat IntelligenceとMicrosoft Security Researchは2026年10月23日、公式ブログで「Inside the LiteLLM 1.107.0 supply chain compromise」と題した記事を公開し、AIゲートウェイとして広く使われるPythonパッケージ「LiteLLM」のバージョン1.107.0が侵害されていたことを明らかにしました。LiteLLMは、アプリケーションと複数のAIモデル提供元(プロバイダー)との間に置かれるゲートウェイとして使われるパッケージで、モデルプロバイダーのAPIキーやデータベースの接続文字列、ルーティング設定などにアクセスできる立場にあります。開発者のパソコン、CI/CD(継続的インテグレーション・デリバリー)の実行環境、テスト環境、コンテナなど、さまざまな場所で使われています。

問題のバージョン1.107.0は2026年10月21日にPyPIと公式コンテナイメージで配布されました。LiteLLMが10月23日に公表した確定報告によると、5月に公開リポジトリへ誤って含めた実験的なAgent Platformのマスターキーが失効されず、攻撃者は10月10日にこれを使って同基盤へアクセスしました。そこから組織所有者のGitHub CLI認証トークンを取得し、CI経由で別の維持管理者のトークンも入手。10月21日にリリースの参照先を正規の「BerriAI/litellm」から似た名前の「Berri-AI/litellm」へ変更し、別のトークンで本番公開の承認を通したと説明しています。Microsoftもリリース手順の差し替えを紹介していますが、最初の侵入経路は独自に特定していないと明記しています。

配布されたパッケージには、cook.pth・cook.py・sitecustomize.pyという3つのファイルが含まれ、インストール時にアプリ本体のディレクトリとは別の場所(ライブラリの配下)に置かれました。そのため、LiteLLM本体のファイルだけを消しても、この仕掛けが残ってしまう可能性があります。手口は大きく2つに分かれます。1つ目は認証情報の収集で、cook.pthが読み込まれるとcook.pyが起動し、Base64とzlibで符号化ふごうかされたプログラム(自らを「PRIVCOLLECT」と名乗る)を復号して実行し、バックグラウンドのスレッドで情報収集を行います。2つ目はUnix系OS向けの遠隔コード読み込みで、sitecustomize.pyがバックグラウンドで動作し、GitHub上のdomain.txtというファイルを「どこから命令を取得するか」の目印として読み取り、そこで指定されたサーバーから追加のPythonコードを取得・実行できる仕組みでした。ただし、Microsoftはこの追加コードの取得・実行が実際に起きたとは確認していません。この経路には署名による検証がなく、Microsoftが調査した時点ではdomain.txtは空の状態でしたが、ファイルの中身が書き換えられれば再び遠隔操作の手段として使われる可能性があります。

なぜ重要なのか

今回の手口が重要なのは、Pythonが起動時に自動で読み込む「site初期化処理」という通常の仕組みを悪用している点です。Pythonのインタープリター(プログラムを実行する基盤)は起動のたびに.pthファイルの中のimport文やsitecustomizeモジュールを自動で読み込みます。これはMITRE ATT&CKという攻撃手法の分類で「T1546.018」と呼ばれる手法にあたり、アプリケーションが実際に動いていなくても、Pythonを起動しただけでコードが実行されてしまいます。これは、LiteLLMを直接使わない別のPython処理も、影響を受けた環境では不正コードの起動経路になり得るという意味です。起動しただけで全ての収集・送信が完了するとは限りません。

収集対象として記事が挙げているのは非常に広範です。AIアシスタントやIDE、GitHub Copilot、VS Code、MCP(AIエージェント連携の規格)関連の認証・設定ファイルといった開発ツール関連、Gitの認証情報やパッケージマネージャーの設定、dotenvファイル、秘密鍵といったソースコード管理関連、AWS・Azure CLI・Google Cloudの設定やキャッシュ、Kubernetesのサービスアカウント、Dockerの設定、クラウド上の秘匿ひとく情報(マウントされたシークレット)といったクラウド関連、ChromiumやFirefoxの認証関連データと閲覧履歴、シェルやデータベースクライアントの履歴、SSH・GPG・TLS・CI/CD・Vault関連の設定などです。LiteLLMをゲートウェイとして運用している場合は、Prisma(データベース操作のためのツール)を使う子プロセスを通じて、プロキシが持つデータベースの2つのテーブルから情報を読み取る機能もありました。1回のクエリは500行までに制限されていたとされています。

収集したデータは、実行ごとに生成した32バイトのAES鍵と16バイトの初期化ベクトル(IV)でAES-256-CBC方式により暗号化され、さらに4096ビットのRSA公開鍵でそのAES鍵自体も暗号化(ラップ)されます。できあがったデータをtar.gz形式でまとめ、攻撃者の宛先へHTTP通信で送信するよう設計されていました。Microsoftは、通信が成功したと判断できるのはHTTPステータスコード200が返った場合のみであり、起動しただけでは収集や送信が完了したとは限らないとも補足しています。

私たちへの影響

今回の件で調査と対応が必要なのは、LiteLLM 1.107.0を導入した企業や開発者です。対象にはゲートウェイだけでなく、開発者のパソコン・CI/CD・テスト環境・コンテナも含まれます。該当バージョンを導入した事実と、個々の環境で認証情報が窃取された事実は区別します。MicrosoftはWindowsとmacOSの端末で認証情報収集コードの挙動と整合する観測があったとしており、ある事例では、無関係な別のパッケージをpipでインストールするという通常の操作がきっかけで収集が始まったとも説明しています。公開されたパッケージのハッシュ値は7種類(macOS用2種・Linux用4種・Windows用1種)確認されています。

一方で、Microsoftは被害を受けた組織数や具体的な件数は公表していません。あくまで、どの範囲が侵害された可能性があるかを示す調査結果であり、特定の企業名やサービス名は記事中に挙げられていません。一般の消費者が直接何らかの操作をする必要はありませんが、普段使っているAIを使ったサービスの裏側でLiteLLMのようなゲートウェイが使われている可能性はあり、提供企業側の対応次第で間接的な影響が及ぶ可能性は否定できません。

初心者が知っておくべきこと

サプライチェーン攻撃さぷらいちぇーんこうげきとは、ソフトウェアを作る側や配布する仕組みそのものに攻撃者が侵入し、利用者が正規の手順でインストールしたつもりのパッケージに、あらかじめ悪意のあるコードを混ぜ込んでおく攻撃のことです。利用者からは「いつもどおりの更新」に見えるため、気づきにくいのが特徴です。

タイポスクワッティングたいぽすくわってぃんぐとは、正規のサービス名やリポジトリ名によく似た、見分けにくい別名を用意し、利用者や内部の仕組みを本物と誤認させる手口のことです。今回の事件では「BerriAI/litellm」という正規のリポジトリに対し、ハイフンを1つ入れただけの「Berri-AI/litellm」という別のリポジトリが使われました。

PyPI(Python Package Index)とは、Pythonのプログラムで使う部品(パッケージ)を誰でも公開・ダウンロードできる公式の配布サイトのことです。多くの開発者が、ここで配布されているパッケージを信頼して自分のプログラムに組み込んでいます。

Q. 自分の会社・プロジェクトが対象かどうかは、どう確認すればよいですか。 A. Microsoftの記事によれば、インストール済みの環境やpip・uvのキャッシュ、社内のミラー、ロックファイル、ビルド成果物、コンテナイメージの中に、問題のバージョン1.107.0や、記事で公開されているファイルのハッシュ値と一致するものがないかを確認する必要があります。可変のタグ名ではなく、ハッシュ値(ダイジェスト)で照合することが推奨されています。疑わしい環境では、その場でPythonやpipを実行せず、別の信頼できる端末から調査することも推奨されています。

IT Postの見方——公開された鍵を失効させるまでが対処

今回の確定報告で重いのは、公開されたAgent Platformのマスターキーが、誤りに気づいた後も失効されなかった点だ。さらに組織所有者の広い権限を持つGitHubトークンがその基盤から取得でき、リリース手順と公開承認の双方に悪用されたとLiteLLMは説明している。攻撃者は単に似た名前のリポジトリを置いたのではなく、正規の配布経路がそこを参照するよう変更した。利用者のタイプミスが原因だったわけではない。

IT Postでは、公開が疑われる鍵の失効、トークンの権限範囲、リリース元の固定と承認の独立性を、今回の具体的な教訓と考える。LiteLLMは今後の工程改善を別途公表するとしている。維持管理者の人数や資金不足が今回の侵害を招いたと示す資料は確認できていない。

※個人の感想です

今後どうなりそうか

LiteLLMは10月23日に侵入から悪意ある1.107.0の配布までの経路を確定報告として公開しました。一方、影響を受けた組織・環境の総数や、個別の認証情報窃取の成否は、この資料だけでは分かりません。公開済みの事故対応案内とMicrosoftの調査を参照し、導入履歴、残存ファイル、到達し得た認証情報を各環境で調べる必要があります。今後はLiteLLMが予告した工程改善と、検証できる影響範囲の続報を確認します。