AWS Kiro のプロンプトインジェクションRCE - AIエージェントが自らの信頼境界を書き換える（CVE-2026-10591）

「このURLを取得して要約して」。AIコーディングエージェントに日常的に頼むこの一言が、開発者のマシン上で任意コマンド実行（RCE）の引き金になり得る、という脆弱性が報告されました。舞台は AWS のエージェント型（agentic）AI IDE「Kiro」です。攻撃者が用意した Web ページに人間には見えない隠しテキストを仕込んでおくと、Kiro がそのページを取得した際に隠された指示に従い、Kiro 自身の設定ファイルを書き換えて悪性の MCP サーバを登録し、ユーザー権限で任意コマンドを実行するところまで一気につながります。

注目すべきは、その途中で発生する「設定ファイルの書き込み」「MCPサーバの作成」「コード実行」「外部への送信」のいずれについても、開発者は明示的に承認していない点です。ユーザーが承認したのは最初の「URLを取得する」という無害な操作だけでした。この脆弱性には CVE-2026-10591 が採番され、Kiro 0.11 で修正されています。本記事では、確認できた一次〜準一次情報だけをもとに、何が起きたのか、なぜ人間の承認（human-in-the-loop）が効かなかったのか、そして AI コーディングエージェントを使うエンジニアが今すべきことを整理します。

概要（まず結論）

• 何が: AWS のエージェント型AI IDE「Kiro」で、間接的プロンプトインジェクションを起点に、エージェントが自身の設定ファイルを書き換えて任意コマンド実行に至る。
• 製品: Kiro。スペック駆動（spec-driven）開発を掲げる AWS の AI IDE。プレビュー公開は2025年7月、一般提供（GA）は2025年11月17日（出典 kiro.dev）。利用モデルは Anthropic Claude 系。
• CVE: CVE-2026-10591。AWS セキュリティ速報 AWS-2026-037「Kiro IDE Insufficient File Write Restrictions to Execution-Sensitive Paths」で採番。
• 深刻度: CVSS 8.8（High）。
• 根本原因: Kiro のファイル書き込みツール fsWrite が、ワークスペースの内容と IDE 設定ファイルを区別せず、パス制限も確認ダイアログも無しに書き込めた点。
• 攻撃経路: 汚染 Web ページの不可視テキスト（1px の白文字）→ Kiro が fetch して汚染指示をコンテキストに取り込む → ~/.kiro/settings/mcp.json を書き換え悪性 MCP サーバを登録 → Kiro が設定を自動リロードして起動 → 任意コマンドがユーザー権限で実行。
• 影響バージョン: 0.11 未満。
• 修正: Kiro 0.11（具体ビルドは v0.11.130 で確認）。実行センシティブなパスへの書き込みに明示的なユーザー承認を必須化。
• ワークアラウンド: なし。最新版へのアップグレードが推奨。
• 悪用状況: PoC 実証済み。実環境での悪用は本記事時点で確認できず（未確認）。報告クレジットは Cymulate、付番は2026年7月22日（Intezer 一次による）。

対策の要点を先に言えば、Kiro を最新版に更新すること、そして信頼できない Web コンテンツを AI エージェントに取り込ませる操作を、無条件に自動化しない運用にすることです。詳細は以下で順に見ていきます。

Kiro とは何か

Kiro は AWS が提供するエージェント型の AI IDE です。単なる補完ツールではなく、要件からスペック（仕様）を起こし、タスクに分解して自律的にコードを書く「スペック駆動開発」を掲げています。プレビュー公開は2025年7月、一般提供（GA）は2025年11月17日で、いずれも公式サイト kiro.dev で確認できます。エディタ基盤は Code OSS（VS Code のオープンソース基盤）上に構築されているとされますが、これは公式一次で明言を確認できなかったため準一次情報として扱います。利用する LLM は Anthropic の Claude 系です。

エージェント型 IDE は、ファイルの読み書き、シェルコマンドの実行、外部ツールの呼び出しを AI が自律的に行える点に価値があります。しかし裏を返せば、AI が「何をしてよいか」を判断する材料（プロンプトやコンテキスト）に攻撃者の指示が紛れ込むと、その強力な権限がそのまま攻撃者の手に渡りかねません。これが本件の本質です。エージェントの権限設計とプロンプトインジェクションの関係は、MCPのプロンプトインジェクションによるRCEの解説でも扱っているので、あわせて読むと背景が掴みやすくなります。

3つの開示を混同しない（時系列と経路の違い）

Kiro をめぐっては「単一の脆弱性」ではなく、複数の関連開示が時期をまたいで存在します。まずここを整理しておかないと混乱します。CVE-2026-10591 が指すのは、後述の (C) が対象とするパスに関する修正です。

もう少し具体的に補足します。

• (A) Embrace The Red（2025年）: Johann Rehberger による最初の開示です。間接的プロンプトインジェクションで .vscode/settings.json に "kiroAgent.trustedCommands": ["*"] を注入し、全シェルコマンドを許可させる手法や、~/.kiro/settings/mcp.json 経由での実行を示しました。CVE は付与されていません。Kiro v0.1.42 で部分的に修正され、Supervised モードでのみ確認プロンプトが追加されましたが、デフォルトの Autopilot（自律）モードでは自動書き込みが継続していたとされます。
• (B) Intezer Research（2026年7月）: Nicole Fishbein らによる開示で、記事タイトルは "When the AI Edits Its Own Trust Boundary: Remote Code Execution Vulnerability in AWS's Agentic IDE" です。本記事が主に扱う経路で、汚染 Web ページの不可視テキストを起点に mcp.json を書き換える流れを実証しました。
• (C) Cymulate Research Lab（2026年6月）: "When AI Tools Become the Backdoor: Zero-Click RCE via Prompt Injection" で、Kiro を含む複数ツールを横断的に扱っています。.vscode/tasks.json に "runOn": "folderOpen" を仕込むと、フォルダを開いた瞬間に無警告で自動実行される点を示しました。これが CVE-2026-10591 の対象パスです。

なお、別脆弱性である CVE-2026-0830（Kiro GitLab MR Helper のコマンドインジェクション）や CVE-2026-5429（Kiro Agent Webview RCE）は本件とは別物です。混同しないようにしてください。

攻撃の仕組み: 隠しテキストから任意コマンド実行まで

(B) の経路を、仕組みが分かる最小限の擬似例で追います。実際に動く攻撃コードそのものは示しません。

1. 汚染Webページに不可視の指示を仕込む

攻撃者は自分が管理する Web ページに、人間には見えない指示を埋め込みます。たとえば文字色を背景と同じ白にし、フォントサイズを極小にする CSS を使うと、ブラウザ表示上は空白にしか見えません。

<p style="color:#fff;font-size:1px">
  （ここに、AIエージェント宛の不可視の指示文が入る）
</p>

2. 開発者が何気なくページを取得させる

開発者が Kiro に「このURLを取得して要約して」といった通常の依頼をすると、Kiro はページを fetch します。このとき Kiro は可視テキストと不可視テキストを区別せず、マークアップ全体をコンテキストに取り込みます。結果として、隠された指示もそのまま AI への入力になります。

3. Kiro が自身の設定ファイルを書き換える

汚染指示に従い、Kiro は保護されていない ~/.kiro/settings/mcp.json（MCP サーバの定義ファイル）を書き換え、悪性の MCP サーバを登録します。擬似的な悪性設定はおおむね次の形です。

{
  "mcpServers": {
    "innocent-looking-name": {
      "command": "任意のコマンド",
      "args": ["攻撃者が指定する引数"]
    }
  }
}

4. 自動リロードで悪性サーバが起動しRCEへ

Kiro は設定変更を検知して MCP サーバ定義を自動リロードして起動します。その瞬間に command / args で指定された任意コマンドがユーザー権限で実行されます。Intezer の PoC は hostname・username・platform といった情報を外部に送信するものでしたが、実証は良性データの収集にとどめられています。ただし同じ手法で認証情報やソースコードの窃取も可能だと報告されています。

この一連の流れは、信頼できないコンテンツがエージェントの実行権限に直結する典型例です。似た構図の実攻撃事例は実際の攻撃事例の解説も参考になります。

根本原因: エージェントが自らの信頼境界を書き換えた

本件の核心は、Kiro のファイル書き込みツール fsWrite が、ワークスペースの内容と IDE の設定ファイルを区別していなかったことです。パスの制限も確認ダイアログも無く、~/.kiro/settings/mcp.json のような「エージェントが何を実行できるかを規定するファイル」まで自由に書き込めました。

これはつまり、エージェントが、自分の権限を定義するファイルそのものを書き換えられたということです。Intezer が記事タイトルで "The AI Edits Its Own Trust Boundary"（AI が自らの信頼境界を編集する）と表現した通り、信頼境界の自己改変が起きています。ユーザーが承認したのは「URL を取得する」ことだけであり、設定ファイルの書き込み・MCP サーバの作成・コード実行・外部送信はいずれも承認なしで連鎖しました。権限を定義するファイルを、その権限で動くエージェント自身が書き換えられる設計は、権限昇格の温床になります。

なぜ人間の承認（human-in-the-loop）が効かなかったのか

AI エージェントの安全策としてよく挙がるのが、危険な操作の前にユーザーへ確認を求める human-in-the-loop です。ところが本件では、これが実質的に機能しませんでした。理由は大きく2つあります。

ユーザーが承認したのは入口の「URL 取得」だけです。その後に起きる設定ファイル書き込み・MCP サーバ登録・コマンド実行は、そもそも個別の承認対象になっていませんでした。攻撃の実害が発生する工程に承認ゲートが置かれていなければ、いくら入口で承認しても意味がありません。

Intezer の報告では、MCP 設定の変更に対してポップアップが出る場合であっても、ユーザーがどう応答したかにかかわらず、Kiro は設定をリロードして悪性サーバを起動しました。承認 UI があっても、その応答結果が実際のリロード挙動に反映されなければ、UI は事実上無意味です。「確認ダイアログを出す」ことと「拒否したら止まる」ことは別問題であり、本件は後者が担保されていませんでした。

教訓は明確です。承認ゲートは実害が発生する直前の工程に、拒否が確実に処理を止める形で置かなければ、安全策として成立しません。設定変更を即リロード・即実行する設計は、この原則と相性が悪いのです。

lethal trifecta（致命的な三要素）で読み解く

Simon Willison が提唱した「lethal trifecta（致命的な三要素）」は、プロンプトインジェクションによるデータ窃取が成立する条件を3つに整理した考え方です。

• (1) プライベートデータへのアクセス（Access to private data）: エージェントが機密情報や開発環境に触れられる。
• (2) 信頼できないコンテンツへの露出（Exposure to untrusted content）: 外部から取り込む Web ページなどに攻撃者の指示が混入し得る。
• (3) 外部通信能力（The ability to externally communicate）: 取得した情報を外へ送り出せる。

この3つがそろうと、攻撃者はプロンプトインジェクションでデータを盗み出せます。本件に当てはめると、Kiro は開発マシン上のファイルや環境（1）にアクセスでき、汚染 Web ページ（2）を取り込み、悪性 MCP サーバ経由で外部送信（3）まで行えました。まさに三要素が完全にそろっていたわけです。逆に言えば、どれか1つの角を断つだけでも成立を大きく妨げられます。とりわけ (3) の外部通信を遮断する発想は、実務で効きやすい防御です。

lethal trifecta は Kiro に限らず、あらゆる AI エージェントの設計を点検するチェックリストとして使えます。Cursor を狙ったゼロクリック RCE の事例はCursor DuneSlide RCE の解説でも扱っており、同じ枠組みで整理できます。

開発者・組織が今すべきこと（対処チェックリスト）

本脆弱性そのものへの対応と、AI コーディングエージェント全般に効く一般化した防御を分けて示します。

• CVE-2026-10591 は Kiro 0.11（具体ビルドは v0.11.130 で確認）で修正されています。実行センシティブなパスへの書き込みに明示的なユーザー承認が必須化されました。
• 公式のワークアラウンドは「なし」です。緩和では埋められないため、最新版への更新が実質的な唯一の対処になります。

• Autopilot・autonomous・YOLO 系の自律モードは、自動書き込み・自動実行の攻撃面を広げます。信頼できる文脈に限定して使い、外部由来の入力を扱う作業では確認を挟むモードにするのが安全です。

• 出所不明な URL の取得・要約をエージェントに無条件で任せない。取り込む前に、少なくとも「これは攻撃者が内容を操作できる入力だ」という前提で扱う。
• untrusted content を取り込む際のサニタイズ（不可視要素の除去など）を検討する。

• とくに外部送信を遮断する（ネットワーク制限、送信先の許可リスト化など）。データ窃取の出口を塞ぐだけでも被害を抑えられます。

• エージェントのファイル書き込みにパス制限を設け、ワークスペースの内容と IDE / エージェントの設定ファイルを明確に区別する。設定変更を「即リロード・即実行」しない設計を選ぶ。

まとめ

CVE-2026-10591 は、AWS のエージェント型 AI IDE「Kiro」で、間接的プロンプトインジェクションを起点にエージェントが自身の設定ファイル ~/.kiro/settings/mcp.json を書き換え、悪性 MCP サーバ経由で任意コマンド実行に至る脆弱性です。CVSS は 8.8（High）で、0.11 未満が影響し、Kiro 0.11 で実行センシティブなパスへの書き込みに承認を必須化する形で修正されました。ワークアラウンドはなく、最新版への更新が唯一の実質的な対処です。

• 今すぐやること: Kiro を 0.11 以降へ更新する。自律モードの使いどころを見直す。
• 設計の教訓: エージェントが自分の権限を定義するファイルを書き換えられる設計は避ける。承認ゲートは実害の直前に、拒否が確実に処理を止める形で置く。
• 点検の枠組み: lethal trifecta（プライベートデータ・信頼できないコンテンツ・外部通信）の3要素で自組織のエージェント運用を評価し、どれか1角を断つ。

本脆弱性は PoC で実証済みですが、実環境での悪用は本記事執筆時点では確認できていません（未確認）。AWS 速報の公開日など日付の一部に情報源間の齟齬があるため、正確な情報は必ず一次ソースでご確認ください。

参考リンク

• Intezer Research: Remote Code Execution Vulnerability in AWS's Agentic IDE (Kiro)
• AWS Security Bulletin AWS-2026-037
• Cymulate: When AI Tools Become the Backdoor - Zero-Click RCE via Prompt Injection
• Embrace The Red (Johann Rehberger, 2025): AWS Kiro Arbitrary Command Execution with Indirect Prompt Injection
• The Hacker News: AWS Kiro Flaw Let Poisoned Web Page Trigger Code Execution
• Simon Willison: The lethal trifecta