2025年6月に報告され、2025年8月に公開されたGitHub Copilot の脆弱性CVE-2025-53773（CVSS 9.6）は、プルリクエスト記述やコードコメントに隠蔽されたプロンプトインジェクションがリモートコード実行（RCE）を可能にするという、AI IDEの構造的欠陥を白日の下にさらした。セキュリティ研究者Markus Vervier（Persistent Security）らによる「IDEsaster」調査では、テスト対象のAI IDE全製品が同種の攻撃チェーンに対して脆弱であることが確認されている。さらに2025年5月に修正されたMicrosoft 365 Copilot EchoLeak（CVE-2025-32711、CVSS 9.3）は、ゼロクリック攻撃でOutlook・SharePoint・Teamsの横断的データ流出を可能にし、RAGベースAIアーキテクチャの根本的な信頼境界問題を露呈した。OWASP Top 10 for Agentic Applications 2026（100人超のセキュリティ研究者が参加）が体系化したAgent Goal Hijacking・Tool Misuse・Memory Poisoningの防御設計、そしてBlueRock Security調査で判明した「MCPサーバーの36.7%がSSRF脆弱性を内包」というサプライチェーンリスクを、OpenAI ChatGPT VS Code拡張機能の5大脆弱性クラス分析に続き、本稿では技術実装レベルで検証する。

CVE-2025-53773の攻撃チェーン解剖 ── プルリクエスト記述が起動する3段階リモートコード実行

CVE-2025-53773の核心は、GitHub Copilotがプロジェクト設定ファイル（.vscode/settings.json）をユーザー承認なしで書き換え可能であるという設計上の欠陥にある。攻撃チェーンは精密に3段階で構成される。

第1段階：プロンプトインジェクション埋め込み。攻撃者はGitHubプルリクエスト記述、ソースコードコメント、Issue、READMEファイル、さらにはリポジトリ内の設定ファイル（.editorconfig、.prettierrc）に悪意ある指示を隠蔽する。これらのテキストは人間のレビュアーには無害に見えるが、AI IDEのコンテキストウィンドウに取り込まれた時点で「命令」として解釈される。Unicode制御文字や不可視文字を用いた隠蔽手法も確認されており、目視でのコードレビューによる検出は極めて困難である。

第2段階：YOLO（You Only Live Once）モード強制有効化。注入されたプロンプトはCopilotに対し、"chat.tools.autoApprove": trueを.vscode/settings.jsonに追記するよう指示する。この設定変更により、すべてのユーザー確認ダイアログが無効化される。ファイル操作は差分表示を経ずに即座にディスクに書き込まれ、シェルコマンドはアラートなしで実行される。開発者が気づく前に、IDE全体の権限モデルが崩壊する。

第3段階：リモートコード実行とワーム型拡散。autoApprove有効化後、Copilotは任意のシェルコマンド実行、インターネットアクセス、ファイルシステムの自由な読み書きが可能となる。ここで最も深刻なのは「ワーム特性」である。攻撃コードはGitコミットに埋め込まれ、force pushを通じて上流リポジトリに伝播する。別の開発者がそのリポジトリをcloneし、AI IDEで開いた時点で同じ攻撃チェーンが自動的に起動する。つまり、1つの汚染リポジトリから組織全体のサプライチェーンへと感染が連鎖する構造である。

筆者は脆弱性診断・ペネトレーションテストの実務経験から、プロトコルやHTTPヘッダ一つの設定ミスが致命的脆弱性になり得ることを幾度となく目にしてきた。しかし、CVE-2025-53773は設定ファイル1行の自動書き換えが「IDE全体の権限モデル崩壊→RCE→サプライチェーン汚染」へと直結するという、従来のWebアプリケーション脆弱性とは次元の異なる攻撃面を示している。

タイムラインを整理する。2025年6月29日に責任ある開示が行われ、2025年8月12日に公開された。MicrosoftはAIエージェントがセキュリティ関連設定ファイルを明示的なユーザー承認なしに変更することを防止するパッチを2025年8月のPatch Tuesdayでリリースした。しかしこのパッチは「設定ファイル保護」という対症療法であり、プロンプトインジェクション自体を根本的に防御するものではない。

EchoLeak CVE-2025-32711とIDEsaster調査 ── AI IDE脆弱率100%が示す設計レベルの構造的欠陥

CVE-2025-53773が単独の脆弱性ではなく、AI IDEというカテゴリ全体の構造的欠陥を示すものである証拠は、2つの独立した調査結果に明確に現れている。

EchoLeak（CVE-2025-32711）：ゼロクリック型LLMスコープ違反。Aim Labsのセキュリティ研究者が2025年1月に発見したこの脆弱性は、Microsoft 365 Copilotにおいて一切のユーザー操作なしにデータ流出を引き起こす。攻撃メカニズムは「LLMスコープ違反（LLM Scope Violation）」と命名された新しい攻撃類型である。M365 Copilotは、Outlookメール、SharePointドキュメント、Teamsメッセージ、OneDriveファイル、組織の事前読み込みデータを信頼境界の分離なく結合・処理する。攻撃者は任意のソース（たとえば共有ドキュメントやメール本文）に悪意あるプロンプトを埋め込むだけで、Copilotの既定動作を「サイレントリークベクター」に転換できる。CVSS 9.3というスコアは、この攻撃がネットワーク経由・低複雑性・ユーザー操作不要であることを反映している。

Microsoftは2025年5月にサーバーサイドパッチを適用し、2025年6月のPatch Tuesdayで正式にCVE-2025-32711として公開した。しかし研究者は、同様の「一般的な設計上の欠陥」が他のRAGアプリケーションにも存在する可能性を指摘しており、EchoLeakはカテゴリ全体の構造問題を示唆するものと位置づけている。

IDEsaster調査：テスト対象AI IDE脆弱率100%。セキュリティ研究者Ari Marzouk（MaccariTA / Persistent Security）は6ヶ月にわたる調査で30以上の脆弱性を発見し、24のCVEが割り当てられた。テスト対象はGitHub Copilot（CVE-2025-64660）、Cursor（CVE-2025-61590、CVE-2025-54135、CVE-2025-54136、CVE-2025-59944）、Windsurf、Roo Code（CVE-2025-58372）、Zed.dev、Junie、Kiro.dev、Cline、Gemini CLIを含む主要AI IDEの網羅的リストであり、脆弱率は100%であった。

攻撃チェーンは「プロンプトインジェクション→ツール悪用→ベースIDE機能の活性化」という3段構造で共通している。たとえばCursor CVE-2025-61590では、.code-workspaceファイルへのプロンプトインジェクションがワークスペースオーバーライドを経由してRCEに至る。Roo Code CVE-2025-58372では、タスク設定インジェクションがワークスペース再オープン時にRCEを引き起こす。さらにOX Security研究では、CursorとWindsurfが古いChromiumバージョン上に構築されており、94以上の既知Chromium脆弱性が180万人の開発者に影響を与えることが判明している。

この「100%脆弱率」という結果は、個別の実装バグではなく、AIエージェントが命令とデータを確実に区別できないという根本的アーキテクチャ上の欠陥を示している。OpenAI GPT-5.4-Cyberが3,000脆弱性修正で示した「防御側特化型AI」のアプローチは攻めと守りの非対称性を示唆するが、IDE自体が攻撃面となる構造問題には別の解法が必要である。

OWASP Top 10 for Agentic Applications 2026の防御設計 ── Agent Goal Hijacking・Tool Misuse・Memory Poisoningの実装仕様

2025年12月9日に正式リリースされたOWASP Top 10 for Agentic Applications 2026は、100人超のセキュリティ研究者・業界実務者・GenAI技術プロバイダーが1年以上かけて策定したフレームワークであり、NIST・欧州委員会・Alan Turing研究所の専門家レビューを経ている。CVE-2025-53773やEchoLeakを含む実際のインシデントが事例として組み込まれており、理論ではなく実証に基づく分類体系である。

ASI01 Agent Goal Hijacking（エージェント目標ハイジャック）。攻撃者がメール、ドキュメント、Webコンテンツなどの悪意あるテキストを通じてエージェントの目標を改変する。CVE-2025-53773のPR記述インジェクション、EchoLeakの信頼境界越境がこのカテゴリに直接該当する。防御設計として、入力コンテンツのサニタイズ、命令とデータの分離層の実装、エージェント目標の不変性検証（各ステップで当初目標との整合性をチェック）が求められる。実装レベルでは、システムプロンプトに対するユーザー入力の優先度を厳密に制御し、外部コンテンツをサンドボックス化した上でのみLLMに渡す設計が必要である。

ASI02 Tool Misuse & Exploitation（ツール誤用・悪用）。エージェントが正規ツールを曖昧なプロンプトや操作された入力により誤用し、データ損失・流出を引き起こす。GitHub Copilotの.vscode/settings.json書き換えはまさにこのカテゴリの典型例である。防御設計では、ツール呼び出しに対する最小権限原則の適用、破壊的操作（ファイル削除、設定変更、ネットワークアクセス）への明示的承認フローの強制、ツール出力の検証（期待される出力パターンとの照合）が不可欠である。IDE固有の対策としては、セキュリティ関連設定ファイルへの書き込みを完全にブロックするホワイトリスト方式が有効であり、Microsoftが8月パッチで採用したアプローチもこれに該当する。

ASI06 Memory & Context Poisoning（メモリ・コンテキスト汚染）。RAGデータの汚染、クロステナントリーク、敵対的コンテンツがエージェントの将来の判断に影響を与える。EchoLeakのRAG統合における信頼境界欠如が直接事例であり、Gemini Memory Attackのように初回接触後も長期にわたり行動を変容させるケースも確認されている。防御設計では、RAGソースごとの信頼レベル分類、コンテキストウィンドウ内での出所追跡（どのソースからどの情報が来たかのメタデータ付与）、定期的なメモリ整合性チェックが必要である。

そのほか、ASI03 Agent Identity & Privilege Abuse（エージェントが高権限クレデンシャルを継承）、ASI04 Agentic Supply Chain Compromise（MCP・プラグインの汚染）、ASI05 Unexpected Code Execution（サンドボックスなしのコード生成・実行）、ASI07 Insecure Inter-Agent Communication（マルチエージェント間の認証・暗号化欠如）、ASI08 Cascading Agent Failures（小さなエラーの連鎖的増幅）、ASI09 Human-Agent Trust Exploitation（ユーザーの過度な信頼の悪用）、ASI10 Rogue Agents（正常に見えて有害に動作する侵害エージェント）が体系化されている。CVE-2025-53773は実際にASI01・ASI02・ASI05の複合攻撃であり、単一カテゴリでは捕捉できない多層的脅威であることをOWASP自身が認めている。

MCPサーバー36.7% SSRF脆弱性 ── サプライチェーン多層防御の技術仕様と実装指針

OWASP ASI04が警告するAgentic Supply Chain Compromiseの具体的規模を定量化したのが、BlueRock Securityによる7,000以上の公開MCPサーバーのセキュリティ分析である。同調査は「36.7%のMCPサーバーがSSRF（Server-Side Request Forgery）脆弱性を内包している」という衝撃的な数値を報告した。

代表的事例：MCP fURI（Microsoft Markitdown MCPサーバーのSSRF）。GitHubスター数85,000を誇るMicrosoft Markitdown MCPサーバーにおいて、攻撃者が未検証URIをサーバーに渡すことで、プライベートIPレンジを含む任意URLへのリクエストが可能となる脆弱性が発見された。具体的には、AWS EC2 IMDSv1（Instance Metadata Service v1）のエンドポイント169.254.169.254へのリクエストにより、AWSアクセスキー、シークレットキー、セッショントークンが取得される。これはクラウドアカウント全体の乗っ取りとラテラルムーブメントに直結する。

筆者がSOC構築・SIEM導入の実務で得た教訓は、「セキュリティの価値はツールではなく、アラートから判断までの人間のプロセスにある」というものであった。MCPサーバーの脆弱性問題も同様に、技術的修正だけでは解決しない。MCPエコシステム全体の信頼モデルが欠如しているのが根本原因である。

多層防御の技術仕様。BlueRock Securityおよび業界のベストプラクティスから導出される防御設計は以下の5層構造となる。

第1層：URI検証とアロウリスト。MCPサーバーが受け付けるURIを明示的なアロウリストで制限する。プライベートIPレンジ（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、169.254.0.0/16）へのリクエストを完全にブロックする。DNSリバインディング攻撃対策として、DNS解決後のIPアドレスを再検証する。

第2層：MCPサーバー認証とバージョン固定。npmやpipのロックファイルと同様に、MCPサーバーのバージョンをハッシュで固定する。起動時の署名検証を実装し、改竄されたサーバーの実行を防止する。BlueRock MCP Trust Registryのようなサードパーティ検証レジストリの活用も有効である。

第3層：ネットワーク分離とサンドボックス。MCPサーバーをコンテナ内で実行し、ネットワークアクセスをegress firewallで制限する。AWS環境ではIMDSv2の強制を必須とし、トークンベースのメタデータアクセスを義務化する。Kubernetes環境ではNetworkPolicyでMCPサーバーポッドの通信先を明示的にホワイトリスト化する。

第4層：出力検証とデータフロー監視。MCPサーバーの応答をLLMに渡す前に、クレデンシャルパターン（AWSキー形式、JWTトークン形式等）のスキャンを行う。異常な応答サイズやレスポンスタイムを検知するモニタリングを実装する。

第5層：組織的ガバナンス。使用するMCPサーバーのインベントリを維持し、定期的なセキュリティ監査を実施する。AIガバナンスROI測定のSEE-MEASURE-DECIDE-ACTモデルで提示されたフレームワークは、MCPサプライチェーン管理にも適用可能である。Shadow AIとして非承認MCPサーバーが開発環境に導入されるリスクを、検知・測定・対応の各フェーズで管理する。

36.7%という数値は、MCPの急速な普及がセキュリティプラクティスを大幅に追い越していることを示している。OWASPが指摘するASI04 Supply Chain Compromiseのリスクは理論的可能性ではなく、既に定量化可能な現実の脅威である。

AI IDE防御設計の今後 ── 「命令とデータの分離」不在という根本課題と実務者が取るべき5つのアクション

CVE-2025-53773、EchoLeak、IDEsaster、MCPサーバーSSRFの分析を通じて浮かび上がる根本課題は一つに集約される。現在のLLMアーキテクチャは、命令（instruction）とデータ（data）を確実に区別できない。この問題はSQLインジェクションにおける「コードとデータの混在」と構造的に同型であるが、LLMの場合は自然言語処理の確率的性質により、完全な解決がさらに困難である。

Veracode 2025 GenAI Code Security Reportは、80のコーディングタスクと100以上のLLMモデルを対象にした調査で、AI生成コードの45%がセキュリティ脆弱性を含むことを報告している。言語別ではJavaが70%超の脆弱率、Python・C#・JavaScriptが38〜45%であり、クロスサイトスクリプティング（CWE-80）ではAIツールが86%のケースで脆弱なコードを生成した。モデルサイズやトレーニングの高度化にかかわらず、セキュリティ性能は横ばいであるという事実は、問題がモデル性能ではなくアーキテクチャレベルにあることを裏付ける。

筆者はセキュリティアーキテクトとして多くの組織でゼロトラスト設計やポリシー策定に携わってきたが、セキュリティ戦略はビジネスの制約を理解した上でなければ絵に描いた餅になるという教訓を何度も得ている。AI IDEの防御設計もまた、開発者の生産性向上というビジネス価値を毀損しない範囲で実装されなければ、結局はバイパスされる。以下に、現実的な5つのアクションを提示する。

アクション1：AI IDEのautoApprove系設定を組織ポリシーで禁止する。MDM（Mobile Device Management）やWorkspace管理ツールを通じて、chat.tools.autoApproveや類似設定の有効化をブロックするGPO（Group Policy Object）を配布する。CVE-2025-53773の攻撃チェーン第2段階を無効化する最もコスト効率の高い対策である。

アクション2：MCPサーバーのインベントリと承認フローを確立する。開発チームが使用するMCPサーバーを登録制とし、セキュリティチームによるレビューを経たもののみを許可する。36.7%のSSRF脆弱率を考慮すれば、未レビューのMCPサーバー利用はリスクとして許容できない。

アクション3：OWASP Agentic Top 10に基づく脅威モデリングを開発プロセスに組み込む。既存のセキュアSDLCにASI01〜ASI10の脅威シナリオを追加し、設計レビュー段階でAIエージェント固有のリスクを評価する。特にASI01（Goal Hijacking）、ASI02（Tool Misuse）、ASI05（Unexpected Code Execution）は全てのAI IDE利用組織に該当する。

アクション4：Git pre-commit / pre-pushフックでプロンプトインジェクションパターンを検出する。不可視Unicode文字、既知のインジェクションパターン（"Ignore previous instructions"等）、異常な長さの設定ファイル変更をフックで検出しブロックする。これはCVE-2025-53773のワーム型拡散を組織レベルで抑止する防衛線となる。

アクション5：AI生成コードに対するセキュリティスキャンをCI/CDパイプラインに必須化する。Veracodeの45%脆弱率データを踏まえ、SAST（静的アプリケーションセキュリティテスト）ツールをAI生成コードに対して自動実行する。従来のSASTルールに加え、AI固有の脆弱性パターン（不適切なデシリアライゼーション、コマンドインジェクション、CWE-80等）を重点的にカバーするルールセットを追加する。

間接的プロンプトインジェクション攻撃は前年比70%以上増加しており、コパイロット経由のコードベースインジェクションはエンタープライズのプロンプトインジェクションインシデントの18%を占める。2025年1月のAI生成コード起因CVEは6件であったが、2026年3月には35件以上に急増している。この上昇曲線が示すのは、AI IDEセキュリティが「将来の課題」ではなく「今日の運用リスク」であるという現実である。2026年4月の攻撃面構造転換分析が示すように、攻撃者はAIツールを新たな侵入経路として既に体系的に活用している。

FAQ

CVE-2025-53773はどのバージョンのGitHub Copilotに影響するか

2025年8月のPatch Tuesday以前の全バージョンが影響を受ける。Microsoftは同パッチでAIエージェントがセキュリティ関連設定ファイルをユーザー承認なしに変更することを防止した。Visual Studio全バージョンのCopilot拡張も対象であり、速やかなアップデートが必要である。

プロンプトインジェクションとは何か、なぜAI IDEで特に危険なのか

プロンプトインジェクションは、LLMに対して意図しない命令を外部データ経由で注入する攻撃手法である。AI IDEではファイルシステムアクセス、シェルコマンド実行、設定変更という高権限操作が可能なため、インジェクション成功時の影響が深刻化する。Webアプリのプロンプトインジェクションと異なり、開発環境全体の制御を奪取できる点が根本的に危険である。

OWASP Top 10 for Agentic Applications 2026と従来のOWASP Top 10の違いは何か

従来のOWASP Top 10はWebアプリケーションの脆弱性を対象とするが、Agentic版はAIエージェント固有のリスクに特化している。Agent Goal Hijacking、Tool Misuse、Memory Poisoningなど、LLMの確率的動作とツール連携に起因する10カテゴリを体系化し、100人超の研究者が実際のインシデント事例に基づいて策定した点が特徴である。

MCPサーバーのSSRF脆弱性36.7%とはどういう意味か

BlueRock Securityが7,000以上の公開MCPサーバーを分析した結果、3分の1以上がサーバーサイドリクエストフォージェリ脆弱性を持つことが判明した。攻撃者はMCPサーバーを経由してAWSメタデータサービス等にアクセスし、クラウドクレデンシャルを窃取可能である。MCPエコシステムの急速な拡大がセキュリティ審査を追い越している現状を示す数値である。

開発者が今すぐ実施すべきAI IDEセキュリティ対策は何か

最優先はautoApprove系設定の無効化確認、AI IDEとCopilot拡張の最新版へのアップデートである。次に、使用中のMCPサーバーの棚卸しと未承認サーバーの除去、Git pre-commitフックでの不可視文字・インジェクションパターン検出を推奨する。CI/CDパイプラインへのSASTスキャン追加も効果的である。

AI生成コードの脆弱性率45%にどう対処すべきか

Veracodeの調査はAI生成コードの約半数にセキュリティ欠陥があることを示している。対処法として、AI生成コードを「信頼されない入力」と同等に扱い、人間によるコードレビューとSASTスキャンの両方を必須化することが推奨される。特にJavaでは70%超の脆弱率であり、言語別のリスク評価が重要である。

EchoLeakのようなゼロクリック攻撃から組織を守るには

EchoLeak（CVE-2025-32711）はRAGベースAIの信頼境界問題に起因するため、組織レベルではM365 Copilotのデータアクセス範囲の最小化、機密ドキュメントへのAIアクセス制限ラベル付け、データ主権を重視したAI-nativeセキュリティアーキテクチャの検討が有効である。Microsoftの修正パッチ適用も必須である。

参考文献