プロンプトインジェクションがRCEになる日 - AIエージェントとMCPが攻撃対象になった2026年

これまで当ブログでは、axios・TanStack・TeamPCP の GitHub 流出など、npm サプライチェーン攻撃の続報を追ってきました。攻撃対象は「依存パッケージ」でした。

2026年5月、その矛先が新しい層に向きました。AIエージェントのフレームワークと、MCP（Model Context Protocol）そのものです。チャットボットの「困った出力」で済んでいたプロンプトインジェクションが、エージェントがツールに接続された瞬間、ホスト上でのコード実行（RCE）に化ける——それが現実の CVE として複数公表されました。

この記事では、5月に相次いだエージェント／MCP の脆弱性を整理し、「いま何をすべきか」をまとめます。

何が起きたのか（早見表）

共通する構図は1つです。プロンプトインジェクションで AI の入力を操れる＋AI がツールを呼べる＝攻撃者がコード実行できる。AI は「設計通り」自然言語をツール呼び出しに変換しているだけ。問題は、そのツールが何を許しているか、です。

Semantic Kernel の RCE: なぜ「設計通り」が危ないのか

Microsoft は2026年5月、自社の OSS フレームワーク Semantic Kernel（GitHub 2.7万スター超）の脆弱性を公表しました。

CVE-2026-26030: eval 経由のRCE（Python）

ベクトルストアの既定フィルタが、こんな Python の lambda を文字列から組み立てて eval() していました。

# AI モデルの出力が、そのままフィルタ式に埋め込まれていた
lambda x: x.city == 'Paris'

この 'Paris' の部分に AI の出力が直接入る設計だったため、攻撃者が ' or MALICIOUS_CODE or ' のような文字列を注入すると、ブロックリスト検証をすり抜けて実行可能なペイロードが組み上がりました。結果として RCE が成立し、calc.exe の起動が実証されています。

修正版（Python の semantic-kernel 1.39.4 以降）では、AST のノード種別allowlist・関数呼び出しallowlist・危険属性のブロックリストなど、4層の防御が入りました。

CVE-2026-25592: AI から呼べる任意ファイル書き込み（.NET）

.NET 版では、DownloadFileAsync メソッドが [KernelFunction] 属性付きで公開されており、AI モデルが呼び出せる状態でした。保存先 localFilePath の検証が無く、Windows のスタートアップフォルダなど任意の場所に書き込めてしまう——サンドボックス脱出とホストレベルの書き込みに繋がります。修正版（.NET SDK 1.71.0 以降）では当該属性を外し（AI から見えなくし）、パス正規化＋allowlist の検証を追加しました。

効く原則: 「LLM はセキュリティ境界ではない」

Microsoft の記事が掲げる原則が鋭いです。

あなたの LLM はセキュリティ境界ではない。公開したツールが、攻撃者の影響範囲を定義する。

「プロンプトを賢くフィルタすれば安全」ではなく、AI に渡したツール（関数）の権限こそが攻撃面だ、という発想の転換です。

MCP の RCE 群: 設計判断が生むシステミックなリスク

エージェント単体だけでなく、エージェントを外部ツールに繋ぐ MCP でも、5月に複数の RCE が公表されました。

OX Security のアドバイザリによると、根本原因は MCP SDK の STDIO トランスポートにあります。ローカルツール実行のために、コマンドや引数の値を検証・allowlist なしに StdioServerParameters へ渡し、subprocess として実行してしまう設計です。これにより、14製品以上で深刻な脆弱性が報告されました。確認できた CVE の一部です。

注目すべきは、トランスポート層の保守側（Anthropic を含む）が「これはトランスポート層のコードであり、それを使う開発者が各自の実装のセキュリティに責任を負う」という立場を取っている点です。つまり「サニタイズは利用側の責務」という線引きです。是非はともかく、MCP を組み込む開発者が自分で防御を設計しなければならない、という現実をはっきりさせています。

Tool Poisoning（ツール汚染）の持続性

従来のプロンプトインジェクション研究と違うのは「持続性」です。汚染されたツール定義（description）は、パッケージや設定ファイル、リモート MCP サーバーの中に同梱され、毎回の呼び出しで・全セッションで・全ユーザーに・誰かが気づくまで静かに効き続けます。一度きりの攻撃ではなく、サプライチェーンに埋め込まれた持続的な罠になり得ます。この発想は TanStack 事件で見た「正規の経路に埋め込まれた汚染」と地続きです。

いま打つべき防御策

公表された情報から、実務で効く対策を整理します。

すぐやる（パッチ）

• Semantic Kernel: Python は 1.39.4 以降、.NET は 1.71.0 以降へ更新
• 利用中の MCP サーバー・エージェント製品（LiteLLM、Flowise、Windsurf 等）のバージョンを点検し、該当 CVE のあるものを更新

設計で効かせる

• ツールの権限を最小化する: AI に公開する関数（ツール）を絞る。ファイル書き込み・コマンド実行・ネットワークアクセスは特に厳格に。「LLM ではなくツールが攻撃面」を前提に設計する
• ツール入力をサニタイズ・allowlist する: MCP の STDIO 経由でコマンド/引数を実行する箇所は、検証と allowlist を自前で必ず入れる（保守側は「利用側の責務」と明言している）
• サンドボックス化する: エージェントのコード実行は隔離環境（コンテナ・サンドボックス）で。ホストに直接触らせない
• MCP サーバーの出所を確認する: ツール定義（description）に汚染が混入し得る。信頼できる出所のサーバーのみ接続し、定義の変更を監視する

検知する

• 異常な子プロセス（calc.exe のような想定外の起動）や永続化の痕跡を、エンドポイントで検知する仕組みを入れる

MCP の安全性強化はプロトコル側でも進んでいます（MCP 2026 ロードマップ）。とはいえ「利用側の責務」という線引きがある以上、組み込む側の設計と運用が当面の主戦場です。

まとめ

• 2026年5月、攻撃対象が「依存パッケージ」から「AIエージェント／MCP」へ拡大。プロンプトインジェクションが RCE に化ける CVE が複数公表
• Semantic Kernel は eval 経由の RCE（CVE-2026-26030, Python 1.39.4 未満）と AI から呼べる任意ファイル書き込み（CVE-2026-25592, .NET 1.71.0 未満）。calc.exe 起動を実証
• MCP は STDIO トランスポートの設計起因で14製品超に RCE。保守側は「サニタイズは利用側の責務」との立場
• 原則は「LLM はセキュリティ境界ではない。公開したツールが攻撃範囲を決める」
• 対策はパッチ＋ツール権限の最小化＋入力 allowlist＋サンドボックス＋出所確認＋異常プロセス検知

エージェントに「できること」を与えるほど、攻撃者にも「できること」を与えることになります。便利さと攻撃面はトレードオフ——AIエージェントを本番に出す前に、必ず「このツールが乗っ取られたら何が起きるか」を一度通しで考えておくべきです。

参考リンク

• When prompts become shells: RCE vulnerabilities in AI agent frameworks（Microsoft Security Blog）
• MCP Supply Chain Advisory: RCE Vulnerabilities Across the AI Ecosystem（OX Security）
• MCP 2026 ロードマップ（当ブログ）
• TanStack 乗っ取り事件（当ブログ）
• TeamPCP の GitHub 内部リポジトリ流出（当ブログ）