攻撃者はAIインフラを価値の高いクラウド侵入口とみなす傾向を強めており、公開状態にあるModel Context Protocol(MCP)サービスやエージェントフレームワーク、AIゲートウェイを悪用してコードを実行し、プロンプトインジェクションを検証し、クリプトマイナーを展開し、プロセスメモリから認証情報を窃取しています。
これらのキャンペーンからは、攻撃者が汎用的なWebサーバー向けの手口だけに頼るのではなく、展開されているAIスタックの内部構造に合わせて偵察や認証情報の窃取、ペイロードの偽装を作り込んでいる実態がうかがえます。
クラウド環境における自己ホスト型・マネージド型AIサービスの急速な普及が、このリスクをさらに増幅させています。
Wizの「2026年クラウドAIレポート」によると、クラウド環境の90%が自己ホスト型のAIソフトウェアを稼働させている一方、81%がマネージドAIサービスを利用し、63%が独自モデルをホストしています。
AIプロキシやエージェントは、ユーザー、モデル、クラウドID、MCPツール、社内APIの間に位置することが多く、公開された1つのコンポーネントが認証情報や横方向移動への足がかりとして高い価値を持ちかねません。
もっとも直接的な攻撃活動は、LiteLLMのMCP機能を標的にしたものでした。
研究者らは、攻撃者がCVE-2026-59822として追跡されている認証バイパスの欠陥を悪用しているのを確認しました。この脆弱性では、偽装されたAuthorizationヘッダーによって不正なOAuth2フォールバックが発生し、有効なLiteLLMキーを持たなくてもMCPツール群へのリクエストが到達可能になります。
脅威アクターは、LiteLLM MCPサーバーのプレビューエンドポイントに存在するコマンドインジェクションの脆弱性、CVE-2026-42271も悪用していました。
Criticalvulnerability alerts
影響を受けるエンドポイントは、commandフィールドを含むMCP設定を受け付け、接続テスト中にそのコマンドを実行してしまいます。
この脆弱性はLiteLLMバージョン1.74.2から1.83.6に影響し、バージョン1.83.7.labsで修正されました。
ハニーポットでの観測活動では、攻撃者が悪意あるstdioベースのMCP設定を送り込み、クリプトマイナーをダウンロードして起動する一方、構文的には正当なMCPハンドシェイクを返すことで接続テストが正常に見えるよう偽装していました。
観測されたペイロードは、一時的な隠しディレクトリを使用してマイナーをデタッチドプロセスとして起動し、その後ステージング用ディレクトリを削除することで、ディスク上のフォレンジック証拠を減らしていました。
CVE-2026-42271は、2026年6月にCISAの既知の悪用済み脆弱性(KEV)カタログに追加されました。
セキュリティ研究者らはまた、この欠陥がStarletteのホストヘッダー検証バイパス脆弱性であるCVE-2026-48710と組み合わされることで、認証を要するコード実行のバグを認証不要の侵害経路に変えうることも明らかにしています。
2つ目の攻撃パターンは、LangChain、Flowise、OpenWebUI、Node-REDなどのエージェントプラットフォームを標的としたブラインドプロンプトインジェクションでした。
目に見えるコマンド出力を必要とする代わりに、攻撃者はシェルアクセス権を持つエージェントを操って、攻撃者が管理するアウトオブバンドアプリケーションセキュリティテスト(OAST)ドメインへDNSリクエストを送らせようとしていました。
このコールバックは、注入された命令が実行可能なツールに到達したことの証拠となり、しかもアプリケーションのインターフェースを通じて出力を露出させることがありません。
Wiz Threat Researchによれば、LiteLLM、Flowise、LangChain、Langflow、ChromaDB、Ollamaを含むAI・機械学習サービスを対象とした90日間のハニーポットのテレメトリで、継続的な活動が観測されたということです。
その後、攻撃者は外部サービスから後続のコマンドを取得しており、多くの場合Base64エンコーディングを用いることで、単純なプロンプトフィルターやアプリケーションログによって最終的なペイロードが露見する可能性を下げていました。
MCPのRCE悪用
成功したセッションの多くは、AI関連ディレクトリ内、それもNode.jsやエージェントフレームワークの環境に紛れ込むよう設計された場所に、XMRigのクリプトカレンシーマイナーを設置する形で終わっていました。
この一連の活動は、プロンプトインジェクションが単なるモデルの挙動上の問題にとどまらないことを示しています。エージェントがシェルやネットワークツール、コード実行環境、権限を持つコネクタを呼び出せる状態になると、それはインフラ侵害の問題へと変質するのです。
3つ目のパターンは、AIネイティブな侵害後の活動です。攻撃者は、SSH鍵やクラウドのメタデータ、一般的な設定ファイルの収集にとどまらず、LiteLLMがロードしているPythonモジュールの状態を調べ上げ、プロキシのマスターキーを取得していました。
この手法は、AIゲートウェイにとって特に危険です。というのも、AIゲートウェイはOpenAI、Anthropic、Azure、Google GeminiといったAPIキーを一元管理していることが多く、加えてクラウドIAM権限やMCP接続された社内サービスへのアクセス権も持ち合わせているためです。
プロキシを侵害した攻撃者は、どのバックエンドモデルに到達可能かを把握し、認証情報を窃取し、LLMjacking(LLM乗っ取り)攻撃で推論クォータを消費させたり、接続先の企業システムへ横展開したりすることが可能になります。
研究者らは、フレームワークの特性を意識した偽装工作も確認しています。あるLangflowの標的では、マイナーが/app/data/.claude/配下に設置され、unicornという名前にリネームされていたと報告されており、これはClaude Codeに関連する成果物に似せることで、通常の管理者によるレビューをすり抜けることを狙ったものと考えられます。
組織は、インターネットからアクセス可能なすべてのAIコンポーネントを棚卸しし、明確な所有権、監視、パッチ適用の責任者を割り当てるべきです。
公開状態にあるAIサービスは、デフォルトで認証を必須とすべきであり、LiteLLMのMCPルートやプレビューエンドポイントは、不可欠でなければ無効化または制限するべきです。
各チームは、影響を受けるバージョンを超えるLiteLLMへ直ちにアップグレードし、露出した可能性のあるプロバイダー用およびプロキシ用の認証情報をローテーションし、MCPサービスを認証付きでネットワーク制限されたリバースプロキシの背後に配置すべきです。
実行時の検知も同様に重要です。AIサーバーがシェルやPythonのワンライナー、ダウンロードユーティリティ、Base64デコーダー、アーカイブ展開ツールを起動したり、想定外のアウトバウンドDNSトラフィックを発生させたりした際のアラートは、MCPの悪用とエージェント主導のプロンプトインジェクションの両方を検知しうるものです。
AIインフラは、実験的なツールとしてではなく、認証情報が密集する本番インフラとして保護すべき段階に来ています。
侵害指標(IOC)
| 指標 | 種別 | 説明 |
|---|---|---|
| 185.62.1[.]8 | IP | マルウェア配布サーバー(LiteLLM/MCPキャンペーン) |
| 185.84.98[.]85 | IP | クリプトマイナーのC2 |
| pool.hashvault[.]pro | ドメイン | Moneroマイニングプール(複数のキャンペーンで使用) |
| crazyeltonproxy[.]top | ドメイン | Moneroマイニングプロキシ(LangChain + Node-RED) |
| 94.26.106[.]29 | IP | Langflowバイナリのステージング先 |
注: IPアドレスおよびドメインは、誤って名前解決やハイパーリンク化されることを防ぐため、意図的にディフェング処理(例: [.])を施してあります。再度有効な形式に戻す際は、MISPやVirusTotal、あるいは自社のSIEMなど、管理されたスレットインテリジェンス基盤の中でのみ行ってください。
★ どのセキュリティツールを削減すべきか?1ページでスコア化 – 継承セキュリティスタックガイドをダウンロード
SocialSecurity protection
翻訳元: https://gbhackers.com/mcp-rce-exploitation/
