当社のAIエンジンNeutronが、UCバークレーのCyberGymベンチマークで97.1%のスコアを記録しました。 詳細を見る

ディープダイブ

ディープダイブ

悪意あるLiteLLM 1.107.0が認証情報を窃取し、ホストにバックドアを設置

脅威アクターは漏えいしたまま失効されていないマスターキーでLiteLLMのリリースパイプラインを乗っ取り、2026年10月21日に悪意ある1.107.0をPyPIとDockerへ公開しました。wheelはPythonの起動ファイルを設置し、LiteLLMを一度もインポートしなくても認証情報を盗み、1時間ごとに動くバックドアを開きます。PyPIは1時間44分後に隔離しました。インストールした環境は再構築し、到達可能な全シークレットをローテーションする必要があります。

Ostorlab Team

要点

  • 2026年10月21日11:39 UTCにPyPI、11:46 UTCにDocker HubとGHCRへ公開されたLiteLLM 1.107.0は、プロジェクトではなく攻撃者が作成したものです。Upwindが12:06 UTCに攻撃を報告し、PyPIは13:23 UTCに隔離、Dockerタグは14:20 UTCに削除または付け替えられました。
  • 悪意あるwheelはLiteLLMパッケージディレクトリの外にPythonの起動ファイルを書き込みます。そのため、LiteLLMをインポートしなくても、その環境でPythonが起動するたびにペイロードが実行されます。Microsoftの研究者が記録したとおり、パッケージだけを削除すると起動コンポーネントが残ります。
  • ペイロードは、SSHとGitの認証情報、環境変数、レジストリとパッケージマネージャーのトークン、クラウドとAIのキー、ブラウザーデータを集めてlitellm[.]dev/healthcheckへ送る情報窃取プログラムと、毎時攻撃者のコードを取得・実行するUnixバックドアです。
  • 対象時間内にどこかで1.107.0をインストールまたは取得していた場合、ホストとシークレットを侵害済みと扱ってください。検証済みの安全なバージョンから環境を再構築し、ホスト、ビルド、周辺のCIが到達できたすべての認証情報をローテーションします。最後の安全なPyPIリリースは1.106.3です。

影響を受けるか

次の条件をすべて満たす場合に影響を受けます。

  • 2026年10月21日11:39 UTCから13:23 UTCの隔離までにPyPIからlitellm 1.107.0をインストールした、または11:46 UTCから、タグv1.107.0、latest、main-latest、main-stableが削除・付け替えられた14:20 UTCまでに公開されたLiteLLMのDockerまたはGHCRイメージを取得した。
  • インストール後に少なくとも一度その環境が起動された。Pythonの起動ファイルを通じて実行されるため、LiteLLMのインポートは不要で、一度も呼んでいないことは保護になりません。
  • それ以降、環境の再構築とシークレットのローテーションを行っていない。

ホスト、CIランナー、イメージで、インストール済みと固定されたバージョンを確認します。

pip show litellm | grep -E '^(Name|Version|Location)'
grep -rn 'litellm' requirements.txt pyproject.toml 2>/dev/null
grep -n -A2 'name = "litellm"' uv.lock poetry.lock 2>/dev/null   # shows the pinned version
docker images | grep -i litellm                                  # local caches

CIや開発端末では、あるべきでないPython起動ファイルも探してください。環境のsite-packagesやユーザーサイトディレクトリにある予期しない.pth、sitecustomize.py、usercustomize.pyです。これがwheelの永続化機構です。10月25日時点のPyPIには正式版1.107.0が一切なく、プレリリースのdevとrcだけがあり、最新の正式版は1.106.3です。正式版1.107.0が正規に公開されたことはないと、これでも素早く確認できます。

規模の目安として、litellmの直近1週間のPyPIダウンロード数は21,343,835件でした（pypistats、2026年10月25日確認）。1時間44分の公開でも、大量の自動インストール、CIキャッシュ、夜間ビルドに届き得ます。

悪意あるコードの動作

悪意あるリリースは、通常のアンインストールで消えるパッケージの外側、Pythonの起動経路にコードを設置し、LiteLLMをライブラリからホスト全体への侵入プログラムに変えます。

Socket、OpenSourceMalware研究グループ、Microsoft Security Researchの分析は、1.107.0のwheel内に2つの実行経路がある点で一致しています。

  1. Python起動時に動く認証情報収集プログラム。システム情報、SSHファイル、GitとGitLabの認証情報やトークン、環境変数、開発ツール、AIアプリ、クラウド環境、Webブラウザーの認証素材、およびnpm、PyPI、pip、Yarn、Maven、Gradle、Composer、RubyGems、Cargoのトークンを収集します。データは圧縮され、リリースの8日前である2026年10月13日に登録されたlitellm[.]dev/healthcheckへHTTP POSTで送られます。
  2. バックグラウンドプロセスとして起動するUnix向けバックドア。毎時攻撃者に接続して任意のコードを取得・実行し、盗まれたセッションの対処やパスワード変更後も永続的なアクセスを維持します。

決定的なのはコードの設置場所です。wheelはcook.pth、cook.py、sitecustomize.pyの3ファイルをlitellm-1.107.0.data/purelib/データディレクトリに含めていました。pipはインストール時にこれらをlitellmパッケージの外、site-packagesのルートへコピーします。ファイルはwheelのRECORDマニフェストに有効なハッシュで記載されており、後から追加されたのではなく、リリースに組み込まれていました。Pythonはインタープリターの起動ごとに、site-packagesの.pthファイルとsitecustomize.pyを実行します。Microsoft Security Researchは、悪意ある起動ファイルがLiteLLMのアプリケーションディレクトリ外にあったため、LiteLLMを一度もインポートしなくても、影響環境でPythonを起動するだけでコードが動く可能性があり、アプリケーションファイルだけを削除しても起動コンポーネントが残り得るとしています。したがって、パッケージのアンインストールや更新では除去にならず、環境の再構築が必要です。

侵害の経緯

LiteLLM自身の開示が連鎖全体を再構成し、Socketの時系列がワークフローの詳細を補っています。

  1. 2026年5月27日、公開リポジトリLiteLLM-Labs/lite-harnessへコミットされた設定ファイルに、LiteLLM Agent Platform環境のマスターキーが含まれていました。誤りが発見され、コミットはforce-pushで上書きされ、キーは失効が必要とされましたが、実際の失効は行われませんでした。
  2. 10月10日、69.48.229[.]143から活動する攻撃者が、失効していないマスターキーでAgent Platformへ入り、設定されていたGitHub CLIのOAuthトークンを抽出しました。このトークンはGitHub組織所有者のアカウントに属し、スコープが制限されていなかったため、組織内の全リポジトリへの所有者権限を与えました。
  3. 同日22:11～22:12 UTC、攻撃者は内部リポジトリBerriAI/litellmとBerriAI/litellm-autoに、ci-tmp-a351cc、ci-tmp-4d8517という短命のブランチへコミットしました。それぞれ、無害に見える件名「ci: bump cache config」で.github/workflows/cache.ymlを追加し、全pushで実行させました。ワークフローはGitHubトークン、組織のLinearワークスペース、LiteLLM環境、Together AIのAPIキー、GitHub Appの識別子と署名鍵を収集し、攻撃者が制御する2つのwebhook[.]siteエンドポイントへ送信しました。実行履歴とブランチは数分後に削除されました。10月12日の2回目は、Anthropic、OpenAI、AWS Bedrockのキー、Tavilyキー、GitGuardianのシークレットスキャン用テナントキー、Playwrightのストレージ状態、PostgreSQLとRedisの認証情報まで広げました。GitGuardianのテナントキーは防御上重要です。シークレットスキャン基盤自体の認証情報であり、活動を検出し得たアラートを閲覧し、場合によっては制御できるためです。
  4. 10月21日10:08～11:08 UTC、攻撃者はブランチ保護を上書きし、リリースパイプラインの取得元をBerriAI/litellmから、BerriとAIの間にハイフンを入れた類似リポジトリ「Berri-AI/litellm」へ変更しました。通常のリリースは、許可されたエンジニアに加え、オフィス内の物理端末に固定された特別アカウントの承認が必要でした。しかし、その週の早い段階で任意のエンジニア2人へ制約が緩和されていました。攻撃者は盗んだメンテナートークンの一つでリリースを起動し、別のトークンで承認しました。
  5. 11:39 UTCにPyPIへ1.107.0が届き、11:46にDocker HubとGHCRのイメージが続き、11:53に本番とステージングの実行記録が削除されました。Upwindの研究者Lidor Machlufが12:06にサプライチェーン攻撃を報告し、PyPIが13:23に隔離、Dockerタグは14:20に削除または検証済みの安全なイメージへ付け替えられました。

LiteLLMは、GitHubトークンが内部デプロイログから漏えいしたという当初の仮説を否定し、現在はすべての内部システムとベンダープラットフォームに関連する全トークンを失効させています。

攻撃フロー

flowchart LR A["公開リポジトリへマスターキーをコミット
失効されないまま（5月27日）"] --> B["攻撃者がキーでAgent Platformへ侵入
（10月10日）"] B --> C["組織所有者のGitHub CLI
トークンを抽出"] C --> D["ci-tmp-*ブランチで
トークン収集ワークフローを実行"] D --> E["リリース元を類似Berri-AIリポジトリへ変更
（10月21日）"] E --> F["悪意ある1.107.0を
PyPI、Docker Hub、GHCRへ公開"] F --> G["起動フックがlitellm[.]devへ認証情報を窃取
バックドアが毎時実行"] style E fill:#f8d7da

攻撃者に可能なこと

悪意あるwheelが実行されたホストでは、次が可能です。

  • プロセス所有者が読めるすべての認証情報を読み取り、持ち出す。SSHキー、Git設定とトークン、クラウドとAIプロバイダーのキー、データベースとキャッシュの認証情報、環境変数、npm、PyPI、pip、Yarn、Maven、Gradle、Composer、RubyGems、Cargoのパッケージレジストリトークン
  • バックドアを通じて毎時攻撃者のコードを再実行する。環境を再構築しなければ、盗まれた認証情報のローテーション後もアクセスを維持
  • 収集したCIとプラットフォームの認証情報を通じて侵入を拡大する。メンテナー権限のGitHubトークン、GitHub App署名鍵、GitGuardianのスキャンテナントキー、LiteLLMがユーザーのために中継するものと同種の上流APIトークン

プロジェクトのメンテナーにとって、影響は一つのリリースを超えました。攻撃者は11日間、全リポジトリの読み取りと変更が可能なGitHub組織所有者権限を保持し、メンテナー権限を持つエンジニア2人からシークレットを収集していました。

インストールした場合の対処

アップグレード先となる安全な正式版1.107.0はPyPIに存在しません。1.107.0のインストールをホスト侵害として扱い、次の順に対応してください。

  1. 影響を受けたホスト、コンテナー、CIランナーを隔離します。気軽な調査のためにログインするのではなく停止してください。Pythonを起動するとペイロードが再実行されるためです。
  2. 検証済みの安全なバージョンで、環境をゼロから再構築します。新しいコンテナーイメージ、仮想環境、CIランナーを使います。最後の安全なリリースlitellm==1.106.3、または今後プロジェクトが提供する検証済みリリースに固定してください。pip uninstall litellmだけでは不十分です。起動ファイルはパッケージディレクトリ外にあり、残ります。
  3. 環境、そのビルド、CIが到達できたすべてのシークレットをローテーションします。環境変数、SSHキー、GitとGitLabのトークン、クラウドとAIプロバイダーのキー、データベースとRedisの認証情報、ブラウザー保存の認証情報、窃取プログラムが対象とする全エコシステム（npm、PyPI、pip、Yarn、Maven、Gradle、Composer、RubyGems、Cargo）のレジストリトークンです。攻撃者が単に見たのではなく保持していると想定してください。
  4. インストール元を確認して除去します。10月21日11:39～14:20 UTCに取得したCIキャッシュ、ベースイメージ、Dockerダイジェストと、次のビルド用に1.107.0を固定している可能性のあるロックファイルを確認します。
  5. LiteLLM組織やそのエンジニアのワークフローに関わる場合、GitHub監査ログでci-tmp-*ブランチ、削除されたワークフロー実行、ブランチ保護の変更を確認し、GitGuardianのテナントキーをローテーションします。

侵害されたかを確認する方法

公開分析にある、すべて公開済みの指標です。

  • パッケージの存在：pip show litellmが1.107.0を表示する、またはロックファイルやイメージダイジェストがその版に固定されている。PyPIの公開時間は2026年10月21日11:39～13:23 UTC、Docker HubとGHCRは11:46～14:20 UTC
  • ネットワーク：litellm[.]dev/healthcheck（2026年10月13日登録）へのHTTP POST。ワークフローの収集で使われたwebhook[.]siteの2つの持ち出し先、65a42464-3cfa-4b02-a18c-17a6d7b86f37と4da03473-a3e7-4dc2-a087-9c564b4208e1への接続。後者はプロジェクトのCIにも該当
  • ホスト：wheelをインストールした環境のsite-packagesにある起動ファイルcook.pth、cook.py、sitecustomize.py、その他の予期しない.pth、sitecustomize.py、usercustomize.py。実行時マーカー/tmp/remote_code_loader.lockと/tmp/.pc_once_*。毎時リモートホストへ接続する説明できないバックグラウンドプロセス
  • GitHub組織（メンテナー向け）：ci-tmp-に16進文字列を付けたブランチ、件名「ci: bump cache config」で.github/workflows/cache.ymlを追加したコミット、10月10日と12日に作成後数分で削除されたワークフロー実行、10月21日のブランチ保護やパイプライン変更

経緯

  • 2026-05-27：Agent Platformのマスターキーが公開リポジトリLiteLLM-Labs/lite-harnessへコミット。コミットはforce-pushで上書きされたが、キーは失効されず。
  • 2026-10-10：攻撃者がキーを使って組織所有者のGitHubトークンを抽出し、22:11 UTCにci-tmp-*ブランチで最初のトークン収集ワークフローを実行。
  • 2026-10-12：2回目のワークフローがAI、クラウド、データベース、シークレットスキャンの認証情報へ対象を拡大。
  • 2026-10-13：持ち出し用ドメインlitellm[.]devを登録。
  • 2026-10-21：10:08 UTCにリリース元を類似リポジトリへ変更。11:39にPyPI、11:46にDockerへ1.107.0が到達。11:53に実行記録を削除。12:06にUpwindが報告。13:23にPyPIが隔離。14:20にDockerタグを処理。
  • 2026-10-23：Microsoft Security ResearchがPython起動フックの分析を公開。
  • 2026-10-24：LiteLLMが根本原因を開示し、Socketがワークフローの時系列を公開。
  • 2026-10-25：本記事を公開。

よくある質問

PyPI自体が侵害されたのか？

いいえ。攻撃者はメンテナー権限のGitHub認証情報でLiteLLM自身のリリースパイプラインを通したため、研究者が報告するまでPyPIには正規のアップロードに見えていました。PyPIは公開から1時間44分で隔離し、公開時間を制限しましたが、なくすことはできませんでした。

1.107.0をインストールしてもLiteLLMをインポートしていなければ安全か？

いいえ。悪意あるコードはパッケージディレクトリ外のPython起動ファイルとして設置され、インタープリター起動時、インポートの前に実行されます。パッケージを入れただけで無関係なPythonコードを実行した環境も、LiteLLMをLLMゲートウェイとして使うアプリケーションと同じく危険にさらされています。

アンインストールや1.107.0より新しい版への更新だけでよいか？

いいえ。アンインストールが削除するのはパッケージで、起動ファイルではありません。また、安全な1.107.0は存在せず、PyPIの最新正式版は1.106.3です。環境を再構築して安全なバージョンに固定し、認証情報をローテーションしてください。

Dockerイメージもwheelと同じくらい危険か？

はい。同じ悪意あるビルドが11:46 UTCにDocker HubとGHCRへ公開され、影響タグが削除・付け替えされたのは14:20です。latest経由を含め、その時間帯に取得したイメージには同じペイロードがあり、キャッシュされたダイジェストが、ダイジェスト固定のビルドに今も供給される可能性があります。

リリース承認で止められなかった理由は？

通常は物理端末に固定された特別アカウントが承認しますが、その週はリリースを速めるため、任意のエンジニア2人が起動と承認を行えるよう緩和されていました。攻撃者は盗んだメンテナートークンの一つで起動し、もう一つで承認し、緩和された規則の範囲内で実行しました。

LiteLLMプロキシの仮想キーも影響を受けるか？

プロセスが読めたものはすべて収集済みと扱うべきです。窃取プログラムは環境変数とクラウド・AIプロバイダーの認証情報を集めます。それこそが、LiteLLM環境が上流キーやデータベース設定を保持する場所です。コードからどれに到達できたか推測するのではなく、他のシークレットとともにローテーションしてください。

窃取プログラムはLiteLLMプロキシ環境も狙っています。DATABASE_URLが設定されていると、Python子プロセスを起動し、PrismaでLiteLLM_CredentialsTableのcredential_valuesフィールドとLiteLLM_ProxyModelTableのlitellm_paramsフィールドを、各クエリ最大500行まで読みます。これにより環境変数に加えて、プロキシデータベースに保存された上流モデルの認証情報も取得します。

Ostorlabでリポジトリ、コンテナーイメージ、CI設定をスキャンし、再構築前にlitellm 1.107.0へ固定されたすべての環境を確認してください。

参考資料

  • Oliver JensenとMateo WangによるLiteLLMの根本原因開示「Security incident October 21, 2026: attack chain」、2026年10月24日：https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain （2026年10月25日確認）
  • 公開LiteLLM-Labs/lite-harnessリポジトリのコミットe10b14aにある漏えいした設定ファイル：https://github.com/LiteLLM-Labs/lite-harness/blob/e10b14a/harnesses/opencode/opencode.json （2026年10月25日確認）
  • LiteLLMメンテナーによる初期のトークン漏えい仮説の訂正：https://github.com/BerriAI/litellm/issues/47826#issuecomment-6374891275 （2026年10月25日確認）
  • Microsoft Security Research、「Inside the LiteLLM 1.107.0 supply chain compromise: credential theft through Python startup hooks」、2026年10月23日：https://www.microsoft.com/en-us/security/blog/2026/10/23/inside-the-litellm-1-107-0-supply-chain-compromise-credential-theft-through-python-startup-hooks/ （2026年10月25日確認）
  • 悪意あるci-tmp-*ワークフローのコミットと持ち出し先を調べたSocketの調査：https://socket.dev/blog/litellm-attack-timeline （2026年10月25日確認）
  • wheelの2つの実行経路に関するOpenSourceMalwareの分析：https://opensourcemalware.com/blog/litellm-1-107-0-pypi-wheel-contains-a-credential-stealer-and-persistent-python-backdoor （2026年10月25日確認）
  • LiteLLMの開示を引用した、漏えいしたマスターキーとパイプライン乗っ取りに関する2026年10月24日のThe Hacker News報道：https://thehackernews.com/2026/10/leaked-litellm-master-key-let-attackers.html （2026年10月25日確認）
  • SafeDep、Socket、StepSecurity、Upwindによる侵害パッケージの初期報告を扱う2026年10月21日のThe Hacker News報道：https://thehackernews.com/2026/10/litellm-compromised-in-supply-chain.html （2026年10月25日確認）
  • 正式版1.107.0がなく、最新正式版が1.106.3であることを示すlitellmのPyPIリリース履歴：https://pypi.org/pypi/litellm/json （2026年10月25日確認）
  • litellmのPyPIダウンロード統計。直近1週間に21,343,835件：https://pypistats.org/packages/litellm （2026年10月25日確認）

タグ：

security, supply-chain, litellm, pypi, vulnerability