ツールE一つだけの応答：LiteLLM認証情報収集マルウェア（CVE-2026-42271）

6月13日、当社のLiteLLMデコイに、1,513バイトのPython製認証情報収集プログラムが送り込まれました。このプログラムはModel Context Protocol（MCP）サーバーになりすまし、initializeとtools/listに応答したうえで、収集結果をEという名前のツール1つの説明欄（description）に格納していました。ゲートウェイから見ると、この戻り経路は正規のMCP応答にしか見えません。デコイは送信された本文をそのまま保存していたため、副作用から推測するのではなく、ソースコードとして収集プログラムを直接分析できました。

その後の8週間で、この設計は日付付きの15件のソースアーティファクトとして到来しました。名前付きシークレットの一覧は、3日足らずで7件から72件に増えました。データベース収集機能も加わりました。壊れたFernetルーチンは、次の完全な配信（12時間22分41秒後）で、LiteLLM自身のSecretBox方式に置き換えられました。最後の完全なソースは最初のものの44.2倍の大きさになりましたが、応答は最後までEのままでした。

最近の3つの調査が、この件を取り巻く状況を示しています。Microsoft Security Researchは、公開状態のLiteLLMゲートウェイを起点に、プロセス環境変数のスクレイピングからPostgreSQL認証情報の収集、XMRigの設置、永続化に至る攻撃を追跡しました。Wiz Threat Researchは、90日間にわたるハニーポット調査の一環として、偽のMCP stdioサーバー経由でマイナーが配信され、コマンドの出力がツールの説明欄で返される事例を観測しました。Horizon3.aiは、これらのリクエストの背後にあるコマンドインジェクションと認証の欠陥を分析しています。

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

要点

• 15件のソースアーティファクト：完全なものが10件、途中で切れたものが5件あり、いずれもエミュレートしたLiteLLMのMCPテスト用ルート2か所に配信されました。
• 3日足らずで名前付きシークレットが7件から72件に：その後、一覧は固定され、データベース、ワークロードID、シークレットストアの収集機能が周囲に積み重なっていきました。
• 復号ルーチンの修正：次の完全な配信で、壊れていたFernetロジックがLiteLLMのSecretBox方式に置き換わりました。
• 103のIPから2,048回の配信：DigitalOceanのAS14061が全体の92.9％を占めました。
• 変わらない戻り経路：完全なプログラムはすべて、Eという名前のツール1つを中心に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日、両エンドポイントに管理者チェックを追加しました。ツールE型の最初の配信が当社に届いたのはその55日後で、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の設定ファイルらしきものを読み取っていました。

冒頭部分が保存されていた以降のアーティファクトはすべて、8月20日まで72件の名前のタプルを維持しました。その間も、ソースにはパターンマッチング、データベースアクセス、ワークロードID、シークレットストアの収集機能が追加されています。

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応答：Eという名前のツール1つで、シリアライズされた収集結果がdescriptionに入っている
• テーブル：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値が識別するのは、デコード後のPythonソースまたは保存された冒頭部分であり、周囲のHTTP本文ではありません。

以下の本文ハッシュは、バイト単位で完全に一致する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つのレイヤーで行います。エッジでは、stdioとPythonを含む、脆弱なパスへのリクエストを探します。ホスト上では、LiteLLMがインタプリタを起動し、そのインタプリタが/proc/*/environ、設定ファイル、マウントされたトークンを読み取っていないかを監視します。応答では、Eという名前のツール1つと、JSON形式の大きなdescriptionを含む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ルールを展開し、2つのMCPテストパスを対象にしてください。
2. LiteLLMがインタプリタを起動した場合にアラートを出してください。その際、/proc/*/environの読み取り、設定ファイルへのアクセス、データベースクエリ、クラウドIDの利用、シークレットストアの読み取り、Kubernetes APIの操作と突き合わせてください。
3. ポリシー上可能であれば、MCP応答を検査してください。Eという名前のツール1つと、JSON形式の大きな説明欄が、帯域内で結果を返す際の特徴です。
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チームは、インターネットをより良く、より安全な場所にすることに全力で取り組んでいます。❤️