「E」という名のツール:LiteLLMの認証情報コレクター(CVE-2026-42271)

6月13日、当社のLiteLLMデコイが1,513バイトのPython製認証情報コレクターを受信しました。このコレクターはModel Context Protocolサーバーになりすまし、initializeとtools/listに応答し、その出力をEという名の単一ツールのdescriptionフィールドに格納していました。ゲートウェイ側からは、返信経路が正当なMCP応答のように見えました。デコイは送信された本文を保持していたため、副作用から推測するのではなく、コレクターをソースコードとしてそのまま調査できました。

その後8週間で、この設計は日付の異なる15件のソースアーティファクトとして届きました。名指しされた秘密情報のリストは、3日足らずで7個から72個に増加しました。データベースコレクターも登場しました。壊れたFernetルーチンは、その次の完全版で12時間22分41秒後にLiteLLM自身のSecretBox構成へと置き換えられました。最後の完全版ソースは、最初のものと比べて44.2倍のサイズになっていました。それでも応答は変わらずEでした。

直近の3件の調査が、この事象を取り巻く状況を明らかにしています。Microsoft Security Researchは、公開状態にあったLiteLLMゲートウェイを追跡し、プロセス環境変数のスクレイピングからPostgreSQL認証情報の収集、XMRig、永続化に至る経緯を明らかにしました。90日間にわたるより広範なハニーポット調査の一環として、Wiz Threat Researchは、偽のMCP stdioサーバーを介してマイナーが配布され、コマンド出力がツールのdescriptionに返される様子を観測しています。Horizon3.aiは、これらのリクエストの背後にあるコマンドインジェクションおよび認証の欠陥を分析しています。

本稿では、これらとは別の認証情報コレクターファミリーについて、そのソースコードの変遷と配信インフラを追跡します。このファミリーは、ゲートウェイをプロバイダーキー、保存済み認証情報、ワークロードID、および隣接するシークレットストアへの侵入経路として扱っていました。

要約

• 15件のソースアーティファクト:完全版10件、切り詰められたもの5件が、エミュレートされた2つのLiteLLM MCPテストルートに配信されました。
• 3日足らずで7個から72個に増加した名指しの秘密情報:その後リストは固定化されましたが、データベース、ワークロードID、シークレットストアの各コレクターがその周囲に蓄積されていきました。
• 修正された復号ルーチン:次の完全版配信では、壊れたFernetロジックがLiteLLMのSecretBox構成に置き換えられていました。
• 103個のIPからの2,048件の配信:DigitalOceanのAS14061が全体の92.9パーセントを占めていました。
• 一貫した単一の返信経路:完全版プログラムはすべて、Eという名の単一ツールを軸にtools/list応答を構築していました。

公開報告から捕捉されたソースコードへ

MCPのstdioトランスポートは、ローカルのヘルパープロセスを起動し、その標準入出力を介してJSON-RPCをやり取りします。LiteLLM 1.74.2から1.83.6において、CVE-2026-42271により、有効なプロキシキーを保有するユーザーであれば管理者権限なしに、2つのプレビューエンドポイント経由でプロセスコマンドを指定できてしまう脆弱性が存在しました。影響を受ける環境では、CVE-2026-48710により、これらのエンドポイントが有効なプロキシキーなしでも到達可能になる場合がありました。

LiteLLM 1.83.7は4月19日、両エンドポイントに管理者権限チェックを追加しました。その55日後に最初のツール「E」の配信が観測され、これはCISAがこのCVEをKEVに追加してから5日後のことでした。

コレクターはどのように変化したか

タイムライン

リストは72個まで増加

最初のプログラムには、OPENAI_API_KEY、ANTHROPIC_API_KEY、LITELLM_MASTER_KEY、DATABASE_URLを含む、価値の高い7個の名前が含まれていました。これは/proc/[0-9]*/environをスキャンし、失敗した場合は/proc/1/environにフォールバックしたうえで、自身の環境変数を調べ、LiteLLMの設定ファイルと思われるものを読み取っていました。

その後に配信された、冒頭部分が保持されている全てのアーティファクトでは、ソースがパターンマッチング、データベースアクセス、ワークロードID、シークレットストアコレクターを追加していくなかでも、8月20日に至るまでこの72個の名前の組は維持されていました。

6月15日:LiteLLMの認証情報テーブルに対するSQL

6月15日23:21(UTC)、データベース対応の最初の完全版プログラムが到着しました。これはDATABASE_URLを解析し、PostgreSQLへの接続を試み、LiteLLMの3つのテーブルに対するクエリを含んでいました。

SELECT model_name, litellm_params
FROM "LiteLLM_ProxyModelTable" LIMIT 100;
SELECT credential_name, credential_values
FROM "LiteLLM_CredentialsTable" LIMIT 50;
SELECT param_value
FROM "LiteLLM_Config"
WHERE param_name = 'environment_variables';

その後のプログラムでは、LiteLLM_AgentsTableとLiteLLM_MCPUserEnvVarsが追加されました。環境変数が示すのは現在の値ですが、データベースにはより古いプロバイダーの認証情報が残っている場合があります。コレクターが実際に何を取得できたかは、権限と復号の成否に依存します。

Fernetの誤り

データベース対応の最初のプログラムは、LiteLLMの認証情報保護の仕組みを誤って実装していました。その_try_fernet関数はSHA-256を用いてFernetキーを導出し、復号に失敗した場合は元の値をそのまま返していました。平文とエンドポイントは引き続き利用可能でしたが、LiteLLMのSecretBox暗号文はロックされたままでした。

次の完全版プログラムは、その12時間22分41秒後に、正しい実装とともに到着しました。

k = hashlib.sha256(key.encode()).digest()
box = nacl.secret.SecretBox(k)
decoded = base64.urlsafe_b64decode(value + padding)
return box.decrypt(decoded).decode("utf-8")

この置き換えられた実装は、LiteLLM自身の実装と一致しています。URLセーフなbase64、LITELLM_SALT_KEYまたはマスターキーに対するSHA-256、そしてPyNaClのSecretBoxです。コレクターはソルトの使用を優先していました。

ゲートウェイは地図と化した

最初のリクエストから8週間後、最終版のソースはプロセス、設定ファイル、マウントされたシークレット、LiteLLMの5つのテーブル、そして隣接するシークレットストアを検索するようになっていました。標的となったのは、AWS、Azure、GCPの各ワークロードID、HashiCorp Vault、Doppler、Infisical、そしてKubernetesのSecretsとConfigMapsです。もはやゲートウェイは単なるプロバイダーキーの入手先ではなく、次のシークレットストアへの侵入経路となっていました。

単一の応答、専用の収集ホストなし

完全版のプログラムはすべて、同一のデータフローで終わっていました。

write_jsonrpc({
    "result": {"tools": [{
        "name": "E",
        "description": json.dumps(get_env())
    }]}
})

完全版のプログラムには、収集用ホストがハードコードされているものは一つもありませんでした。明示的な返信経路はMCP応答そのものであったため、見慣れないC2ドメインだけを対象とした調査ではこれを見逃してしまうでしょう。それ以降の亜種でも、クラウドのメタデータ、トークン、シークレットサービスの各エンドポイントを呼び出す可能性があり、帯域内での返信を行うからといってソースがネットワーク的に無音であるとは限りません。

証拠の限界

関連する5,173件のリクエストのうち5,123件で本文が保持されていたため、本文から得られる件数は下限値にすぎません。これらから15件のソースアーティファクトが得られましたが、うち5件は切り詰められたものです。コードが示すのは能力であって、認証情報の取得に成功したことではありません。

配信インフラ

このファミリーは103個のIPから配信されていました。DigitalOceanは90個のアドレスと、2,048件中1,902件、すなわち92.9パーセントの配信を占めていました。その後、分布は広がっていきました。

最初の2つのプログラムだけで全配信の3分の2を占めており、最終版のソースはわずか6回しか届いていません。7月までには、保持されていた1つのプレフィックスが41個のアドレスに広がっていました。静的なIPブロックリストでは、すぐに実効性を失うことになります。

5個のアドレスが、複数の完全版ソースあるいは保持されたプレフィックスを配信していました。以下の各エッジは、バイト単位で一致する配信を表しています。

2,048件のリクエストはすべて同一のユーザーエージェントを使用していました。これ単体では判定材料として弱いものの、脆弱なパス、stdio/Pythonラッパー、あるいは一致するハッシュ値と組み合わせることで有効な手がかりとなります。

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

侵害指標(IoC)

ネットワーク

ツール「E」の系統とは別に観測された2件の事例は、MicrosoftとWizが報告したインフラと一致します。両社が示した正確なパス、タグ、ハッシュ値は、今後の調査における有用な手がかりとして引き続き役立ちます。

リンク無効化済みの配信元IP

これらのアドレスは、2026年6月13日から8月20日にかけて、このファミリーに一致するリクエスト本文を厳密に配信していました。クラウドインスタンスは再イメージ化や再割り当てが行われている可能性があり、コンシューマー向けのアドレスは動的である場合があります。これらのアドレスは、以下のソースおよびリクエスト本文のハッシュ値と合わせて、日付付きの手がかりとして活用してください。

AS14061 DigitalOcean (90)
46[.]101[.]101[.]72
46[.]101[.]128[.]162
46[.]101[.]131[.]33
46[.]101[.]147[.]103
46[.]101[.]169[.]225
46[.]101[.]174[.]238
46[.]101[.]178[.]31
46[.]101[.]178[.]123
46[.]101[.]182[.]181
46[.]101[.]205[.]202
46[.]101[.]208[.]15
64[.]225[.]111[.]101
64[.]226[.]75[.]251
64[.]226[.]85[.]54
64[.]226[.]105[.]57
64[.]226[.]108[.]153
64[.]226[.]110[.]209
64[.]227[.]121[.]149
64[.]227[.]123[.]160
68[.]183[.]1[.]186
68[.]183[.]183[.]39
104[.]248[.]29[.]139
104[.]248[.]37[.]187
104[.]248[.]253[.]176
134[.]199[.]221[.]128
134[.]209[.]234[.]7
138[.]68[.]73[.]202
138[.]68[.]75[.]159
138[.]68[.]95[.]185
139[.]59[.]145[.]209
139[.]59[.]157[.]93
139[.]59[.]237[.]1
142[.]93[.]173[.]13
142[.]93[.]229[.]183
147[.]182[.]243[.]83
152[.]42[.]141[.]75
157[.]230[.]100[.]189
157[.]230[.]114[.]239
159[.]89[.]27[.]215
159[.]203[.]123[.]236
159[.]223[.]7[.]203
159[.]223[.]210[.]71
161[.]35[.]19[.]129
161[.]35[.]75[.]164
164[.]90[.]163[.]118
164[.]90[.]178[.]65
164[.]90[.]228[.]193
164[.]92[.]154[.]226
164[.]92[.]172[.]84
165[.]22[.]37[.]193
165[.]22[.]77[.]184
165[.]22[.]91[.]82
165[.]22[.]200[.]186
165[.]22[.]204[.]180
165[.]227[.]143[.]228
165[.]227[.]158[.]57
165[.]232[.]45[.]26
165[.]232[.]73[.]47
165[.]232[.]116[.]7
165[.]232[.]126[.]253
165[.]245[.]208[.]84
165[.]245[.]217[.]198
165[.]245[.]220[.]30
165[.]245[.]244[.]177
165[.]245[.]246[.]56
165[.]245[.]255[.]170
167[.]71[.]45[.]54
167[.]71[.]47[.]223
167[.]71[.]48[.]89
167[.]71[.]51[.]249
167[.]71[.]56[.]24
167[.]99[.]132[.]156
167[.]172[.]97[.]26
167[.]172[.]164[.]247
167[.]172[.]167[.]96
167[.]172[.]171[.]160
167[.]172[.]174[.]237
178[.]62[.]246[.]66
178[.]62[.]251[.]23
188[.]166[.]25[.]200
188[.]166[.]90[.]176
188[.]166[.]95[.]74
188[.]166[.]99[.]25
188[.]166[.]149[.]175
206[.]189[.]60[.]69
207[.]154[.]212[.]236
207[.]154[.]221[.]80
209[.]38[.]204[.]145
209[.]38[.]211[.]29
209[.]97[.]145[.]25
AS24940 Hetzner (1)
167[.]233[.]166[.]233
AS37693 TUNISIANA (5)
197[.]17[.]9[.]173
197[.]17[.]29[.]78
197[.]17[.]66[.]128
197[.]17[.]74[.]33
197[.]17[.]127[.]158
AS37705 Topnet (1)
41[.]231[.]84[.]37
AS45102 Alibaba Cloud (6)
8[.]221[.]117[.]120
43[.]98[.]163[.]32
43[.]98[.]171[.]176
43[.]98[.]171[.]177
43[.]98[.]180[.]150
47[.]84[.]103[.]117

ペイロードのシグネチャ

• パス:/mcp-rest/test/connection、/mcp-rest/test/tools/list
• デコード後のソースにおける組み合わせ:def get_env(、/proc/[0-9]*/environ、HVT = (
• MCP応答:シリアライズされた収集結果をdescriptionに格納した、Eという名の単一ツール
• テーブル:LiteLLM_ProxyModelTable、LiteLLM_CredentialsTable、LiteLLM_Config、LiteLLM_AgentsTable、LiteLLM_MCPUserEnvVars
• 暗号処理の組み合わせ:_try_fernet、hashlib.sha256、nacl.secret.SecretBox
• アウトバウンドのYosemiteコレクター:/proc/1/environまたは/proc/*/environ、フィルタ文字列litellm|master|api|minimax|key|secret|token|password|UI_、および/cat1/recv.php?t=

以下のYARAルールは、エンコードされたHTTP本文ではなく、デコード後のソースコードを対象としています。

rule Beelzebub_LiteLLM_MCP_OneToolE_Source_Family
{
    strings:
        $get_env = "def get_env("
        $proc_environ = "/proc/[0-9]*/environ"
        $hvt_tuple = /HVT[ \t]*=[ \t]*\(/
    condition:
        all of them
}

ハッシュ値

Yosemiteに関連する5件のリクエストは、バイト単位で一致する3種類のリクエスト本文に集約されます。

455807a1cf2c8a67e98f9791c6febe2d1199bffaa69f2b5d39a33ac7b47f088d
f7f07858e6f80fff8b41d9ba7737fae6e3e8dd5a9a59fb89c1ad0b0f42150f9d
33d12b08f5b93d883d473afca2b6bf946ca2d7cb5d0e680ef71766b9bf15fc45

以下のSHA-256値は、周辺のHTTP本文ではなく、デコード後のPythonソースコードまたは保持されたソースのプレフィックスを識別するものです。

以下の本文ハッシュ値は、バイト単位で一致するHTTPリクエストを識別するものです。デコード後のソースハッシュに比べ、プロキシ、WAF、または保存済みのパケットデータとの照合が容易な場合が多くあります。

bfa42615c2ff9a3f603f79380fbcd9d52281d39ae45b45264c9bb9e2e3b2d1b7
35b572061f175ed03cdd62088139ca62522d6f2eb5e8977f09d5b4734ac38d3b
3b4fb1f0c71daae2c1690e0fe755be69fb9bf36e538f9cff9866c00f217c6bd4
6496e10178b174d6520472e0ddc945c4267c09edef02dd2c31ef113d54dcdf58
74569fcb7c75a8e4f6f12a691d5a7f581bf78da678722d88d2932d682e8a4364
8192770e654d7c19a6a7c1ad2eae34e70dd055228ab0dc2893b589d6645da165
addab62057d9562174d6afd3629269bfde5a2c1031cc4fbbd54518240540c9e5
15684b50996960de53e2297b5f6fe1d447de7b6efcb18697bd3e0f08f8118248
7a6986b652138ffa4eaf9c555053c6e4de32f9ac7eb677e0a3c8263ce582a5e7
a9061654bc4d88c1a9ef3dd4c50f5706d819b226b17340457ee541421cf020fc
fcd20795eca29ad556ab612bdbb791a5e0db5288b8eef7eb9c43978bb8d75a4a
4177777321c4a63222d9b1f884022ef9dde1202d99cc37ae173a1f3eb066efbe
502b637efb2be2f07292c67af2972307c405e693c5d48a89f4d7d6d4163a2363
4336dd3637d6a7fd43ae102782bbbc6964286fc7e0351b9b06f5436f97eb4c5c
ba4ea48ed5628f2ee86fd141ff48feaad05f19e8a2e52738612ada1ac507d457
c8d4696596b6b77819af6ba013a766f10e9b748e0e4a720269c609acae7713aa
d6c83666179115a8427d3f451ee9de60e3a89fe311acdc4bf02fa7c418660bcb
671d2528a3a068e12c4e78d31439fee599d521672823ef9929bfeedd73c99cbd
4f2b4f980ccc781e96887c0eab9366f154c83e61d7f031780a829813f4b59cbb
24820e216d07b7604b979e6bc4852c92ee7f5f85c412ce11e19fbbea2ecb5857
b1b4b2c41d4de524d5a20773d95fb4d10c6cb2149c3ad0ccf34d1240860bf55a
32ed3b90d5904896cf984f69dcb870abdf6299bacc86f8906c193f87e9b1541d
eca0ffd941fa5c729732d9b15472429c4ca97a7049cd7590e0308afcae78e5a6

検知

次の3つの層で検知を行ってください。エッジでは、脆弱な2つのパスのいずれかがstdioとPythonを伴っているかどうかを確認します。ホスト上では、LiteLLMが/proc/*/environ、設定ファイル、あるいはマウントされたトークンを読み取るインタープリタを起動していないか監視します。応答内容については、大きなJSON形式のdescriptionを伴う、Eという名の単一ツールを含むtools/listの結果にフラグを立てます。これらのシグナルを、5つの対象テーブルへのアクセス、クラウドのメタデータ、シークレットストア、あるいはKubernetes APIとの相関で確認してください。

title: LiteLLM MCP Stdio Credential Collector Attempt
id: 8f2c1b40-5d3e-4a91-b7c2-1e9d4a6f0c33
status: experimental
description: >
  Detects the observed Python credential-collector shape submitted through
  LiteLLM MCP stdio test endpoints.
references:
  - https://github.com/BerriAI/litellm/security/advisories/GHSA-v4p8-mg3p-g94g
logsource:
  category: webserver
detection:
  selection_path:
    cs-method: "POST"
    cs-uri-stem|contains:
      - "/mcp-rest/test/connection"
      - "/mcp-rest/test/tools/list"
  selection_stdio:
    request_body|contains|all:
      - '"transport"'
      - '"stdio"'
      - '"command"'
      - "python3"
  selection_harvest:
    request_body|contains:
      - "/proc/[0-9]*/environ"
      - "base64.b64decode"
  condition: selection_path and selection_stdio and selection_harvest
falsepositives:
  - Authorized MCP connectivity tests that deliberately launch Python; tune known management sources.
level: critical
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
  - attack.t1059.006
  - attack.credential_access
  - attack.t1552.001

alert http any any -> $HOME_NET any (msg:"LiteLLM MCP stdio credential collector attempt (CVE-2026-42271)"; flow:established,to_server; http.method; content:"POST"; http.uri; pcre:"/^\/mcp-rest\/test\/(connection|tools\/list)(?:\?|$)/i"; http.request_body; pcre:"/\"transport\"\s*:\s*\"stdio\"/i"; content:"\"command\""; nocase; content:"python3"; nocase; pcre:"/(?:b64decode|\/proc\/\[0-9\]\*\/environ)/i"; classtype:web-application-attack; sid:202642271; rev:1;)

推奨事項

LiteLLMを運用している場合

1. 1.83.10以降を使用してください。バージョン1.83.7で本稿記載のコマンドパスの脆弱性は修正されていますが、1.83.10ではさらに、権限昇格を必要とする別の深刻度の低いヘルスチェック関連の問題であるCVE-2026-59819も修正されています。
2. 管理インターフェースをインターネットに公開しないでください。専用の、権限を最小限に抑えたゲートウェイIDを使用してください。
3. ゲートウェイのPostgreSQLアカウントの権限を必要なオブジェクトのみに制限し、必要なプロバイダーおよびサービスへのアウトバウンド通信のみを許可してください。
4. 可能な限り、プロバイダーの秘密情報をプロセス環境変数から排除してください。送信されたコレクターは、保存済みの認証情報についても照会し、復号を試みていました。
5. 侵害の実行を確認した場合は、ゲートウェイがアクセス可能だったすべての認証情報を再発行してください。LITELLM_SALT_KEYが含まれる場合は、復旧作業の一環として、保存済みの認証情報を再暗号化するか再作成してください。

アップグレードできない場合

リバースプロキシまたはAPIゲートウェイで、以下のリクエストをブロックしてください。

POST /mcp-rest/test/connection
POST /mcp-rest/test/tools/list

これはあくまで一時的な封じ込め策であり、アップグレードの代替にはなりません。

複数環境を防御している場合

1. 上記のSigmaおよびSuricataルールを、両方のMCPテストパスに対して展開してください。
2. LiteLLMがインタープリタを起動するイベントにアラートを設定してください。これを/proc/*/environの読み取り、設定ファイルへのアクセス、データベースクエリ、クラウドID利用、シークレットストアの読み取り、Kubernetes APIの活動と相関付けてください。
3. ポリシーが許す範囲で、MCP応答を検査してください。大きなJSON形式のdescriptionを伴う、Eという名の単一ツールが、帯域内での返信を示すシグネチャです。
4. 共通して使用されているMac向けユーザーエージェントは、補助的な証拠として扱ってください。パス、stdio/Pythonラッパー、あるいは公開済みのハッシュ値と組み合わせることで有用になります。

結論

コードは変化しましたが、信頼境界は変わりませんでした。LiteLLMはプロバイダーキー、保存済み認証情報、データベースアクセス、そしてワークロードIDの上に成り立っています。ゲートウェイこそが、秘密情報のブローカーなのです。

参考資料

• Microsoft: When AI Infrastructure Becomes the Target
• Wiz: Inside 90 days of attacks on AI infrastructure
• LiteLLM: CVE-2026-42271
• LiteLLM: CVE-2026-59819
• LiteLLM 1.83.7 release
• Horizon3.ai: CVE-2026-42271 exploit chain
• CISA KEV Catalog
• LiteLLM: Set LITELLM_SALT_KEY
• LiteLLM 1.83.7 cryptography utility

オープンソースのBeelzebubデセプションフレームワークをぜひご覧いただくか、Beelzebub.aiのデモをご予約ください。

Beelzebubチームは、インターネットをより良く、より安全な場所にすることに取り組んでいます。❤️