AI統合開発環境（AI IDE）のセキュリティ境界が、根本から問い直されている。2025年12月から2026年3月にかけて、OpenAI ChatGPT VS Code拡張機能およびCodex関連ツールに対して5つの脆弱性クラスが相次いで公開された。データ流出、GitHubトークン窃取、コマンドインジェクション、悪意ある拡張機能による大規模ソースコード窃取、そしてDNS隠れチャネルによるサンドボックス脱出である。本記事では、テクノロジーの視点からこれら5大脆弱性クラスの技術的構造を解析し、AI IDEがエンタープライズ開発環境に持ち込む新たな攻撃面と、その多層防御設計を実装レベルで提示する。なお、GitHub Copilot Workspace vs Cursor Agent Modeの選定基準でも論じたとおり、エージェンティックIDEの機能拡張とセキュリティリスクは表裏一体の関係にある。

脆弱性クラス1: ChatGPTデータ流出 ── 単一プロンプトが会話全体を外部送信する構造

2026年2月20日にパッチが適用され、同年3月に公開された最初の脆弱性クラスは、ChatGPTのデータ流出問題である。攻撃者が単一の悪意あるプロンプトを注入するだけで、通常の会話がデータ流出チャネルへと変換される。影響範囲はChatGPT Webインターフェース、Codex CLI、Codex SDK、そしてVS Code拡張機能（Codex IDE Extension）の全製品に及ぶ。

技術的には、プロンプトインジェクションによってLLMのコンテキストウィンドウに保持されたユーザーメッセージ、アップロードファイル、機密情報が外部エンドポイントへ送信される。問題の本質は、LLMが「ユーザーの指示」と「システムの制約」を同一のテキストストリーム内で処理する構造にある。この構造的弱点により、コンテキスト内に注入された悪意あるテキストがシステム命令として解釈され、データの外部送信が実行される。

筆者は脆弱性診断・ペネトレーションテストの実務経験から、プロトコルやHTTPヘッダ一つの設定ミスが致命的な脆弱性になり得ることを体得してきた。AI IDEの場合、この「一つの設定ミス」に相当するのが、プロンプトインジェクションに対する入力サニタイゼーションの欠如である。従来のWebアプリケーションにおけるXSSやSQLインジェクションと同様に、信頼境界の曖昧さが根本原因となっている。

OpenAIは2026年2月20日にデータ隔離保護を実装してパッチを適用し、悪用の証拠は確認されていないと発表した。しかし、このクラスの脆弱性はLLMアーキテクチャの構造的制約に起因するため、完全な根絶は困難であり、継続的な監視が必要である。

脆弱性クラス2: Codex GitHubトークン窃取 ── ブランチ名によるコマンドインジェクション

2025年12月16日にBeyondTrust Phantom Labsが報告した脆弱性は、OpenAI Codexにおけるコマンドインジェクションである。GitHubブランチ名パラメータの不適切なサニタイゼーションを悪用し、HTTPS POSTリクエスト内のブランチ名に任意のコマンドを注入できる。

攻撃フローは以下のとおりである。まず、攻撃者がシェルメタキャラクタを含む細工されたブランチ名を作成する。Codexエージェントがこのブランチ名を処理する際、入力がエスケープされないままシェルコマンドとして実行される。これにより、エージェントのコンテナ内で任意コマンドが実行され、GitHub User Access Tokenが取得される。窃取されたトークンにより、攻撃者はリポジトリ全体への読み取り・書き込みアクセスを獲得し、さらにGitHub Installation Access Tokenの窃取やbashコマンドの実行へと横展開が可能となる。

タイムラインを整理すると、2025年12月16日に報告、12月23日に初期ホットフィックス、2026年1月30日に包括的パッチ（入力バリデーション強化、シェルエスケープ措置、OAuth トークン制御の厳格化）が適用された。影響範囲はデータ流出と同じく、ChatGPT Web、Codex CLI、Codex SDK、Codex IDE Extensionの全製品である。

この脆弱性の危険性は、CI/CDパイプラインとの連鎖にある。GitHubトークンが窃取されれば、ソースコードの改ざん、マルウェアの注入、サプライチェーン攻撃への踏み台として利用可能である。FortiClient EMS CVE-2026-35616ゼロデイ連鎖で示されたように、認証バイパスから横展開に至る攻撃チェーンは、単一の入力バリデーション欠如から壊滅的な被害に拡大し得る。

脆弱性クラス3: MaliciousCorgi ── 150万DL悪意あるVS Code拡張の大規模ソースコード窃取

2025年1月にKoi Securityが発見したMaliciousCorgiキャンペーンは、AI IDE統合のサプライチェーンリスクを象徴する事例である。2つの拡張機能──「ChatGPT – 中文版（WhenSunset、134万インストール）」と「ChatMoss / CodeMoss（zhukunpeng、15万インストール）」──が、合計150万人以上の開発者のソースコードを密かに窃取していた。

技術的な悪意ある機能は3層構造である。第1層は「リアルタイムファイル監視」で、エディタで開かれるすべてのファイルの内容を読み取り、Base64エンコードして攻撃者制御サーバーへ送信する。第2層は「バッチファイル収集」で、サーバーからのコマンドに従い、1回の実行で最大50のワークスペースファイルを標的型で流出させる。第3層は「行動追跡」で、4つの商用中国アナリティクスSDKを読み込み、デバイスフィンガープリンティングとユーザープロファイリングを実行する。

巧妙な点は、これらの拡張機能が実際にAIコーディング支援機能を提供していたことである。ユーザーの信頼を維持しつつ、バックグラウンドでデータ流出を実行する「トロイの木馬」戦略であった。両拡張機能は同一のバックエンドインフラストラクチャ（中国所在のC2サーバー）を共有しており、組織的な攻撃であったことが示唆される。

さらに深刻なのは、VS Code Marketplace自体のエコシステムの構造的問題である。2025年10月にKoi Securityが発見したGlassWorm攻撃では、72以上のOpen VSX拡張機能にAnivia Loader→OctoRATマルウェアチェーンが埋め込まれ、npm・GitHub・Git認証情報の窃取、暗号通貨ウォレットの窃取、SOCKSプロキシ展開、VNCサーバー設置が行われた。不可視のUnicode variation selectorを使用してコードを隠蔽し、人間のレビューと静的解析を回避する手法が使われている。

脆弱性クラス4: コマンドインジェクション連鎖 ── MCP経由のサイレントRCE

2025年12月にセキュリティリサーチャーAri Marzoukが公開した「IDEsaster」レポートは、AI IDE全体に共通する30以上の脆弱性を特定した。そのうち24件にCVEが付与されている。影響を受けるツールにはGitHub Copilot、Cursor、Windsurf、Kiro.dev、Zed.dev、Roo Code、Junie、Cline、Gemini CLI、Claude Codeが含まれる。

代表的な脆弱性として、CurXecute（CVE-2025-54135、CVSS 8.6）がある。2025年8月1日にAIM Securityが公開したこの脆弱性は、Cursor IDEにおけるMCP（Model Context Protocol）自動起動を悪用したリモートコード実行である。攻撃ベクトルは、MCPサーバー（Slack、イシュートラッカー、サポートインボックス、検索エンジン等）からの非信頼データを経由する。攻撃者がパブリックSlackチャンネルにプロンプトインジェクションを送信し、ユーザーがCursorにメッセージの要約を依頼すると、インジェクションがトリガーされ、~/.cursor/mcp.jsonが書き換えられ、攻撃者制御のコマンドが承認なしで実行される。

同様に、MCPoison（CVE-2025-54136、2025年8月5日Check Point Research公開）は持続的RCEを実現する。ユーザーがMCP設定を一度承認すると、攻撃者がサイレントに動作を変更し、プロジェクトを開くたびに悪意あるコマンドが実行される。追加のプロンプトや通知は表示されない。

OpenAI Codex CLI自体にもコマンドインジェクション脆弱性（CVE-2025-61260）が存在した。プロジェクトローカル設定（.env、.codex/config.toml）にMCPエントリを配置し、CODEX_HOME環境変数をプロジェクトディレクトリにリダイレクトすることで、Codex CLI起動時に自動的にMCPコマンドが実行される。対話的な承認も二次検証もなく、リポジトリをクローンした開発者に対してサイレントに攻撃が発動する。2025年8月20日にCodex CLI v0.23.0でパッチが適用された。

筆者はインシデント対応の最前線で、1秒の判断遅れが被害範囲を指数関数的に拡大させることを学んだ。MCP経由のサイレントRCEは、まさにその「発見までの時間」が無限に引き延ばされるケースである。攻撃が正規のIDE操作に見えるため、従来のEDR（Endpoint Detection and Response）では検知が極めて困難である。

脆弱性クラス5: DNS隠れチャネル ── サンドボックス脱出とC2通信

2026年3月30日にCheck Pointが公開した脆弱性は、ChatGPTのコード実行環境からDNSプロトコルを悪用した隠れチャネル（Covert Channel）の確立である。2026年2月20日にパッチが適用されている。

技術的詳細はこうである。AIエージェントがコード実行に使用するLinuxランタイムのサイドチャネルを悪用し、DNS通信パスを「隠れトランスポート機構」として利用する。情報はDNSリクエスト（Aレコード、AAAAレコード）にエンコードされ、攻撃者が制御するドメインへ送信される。AWS Bedrockの脆弱性では、サンドボックスモードのAgentCore Code InterpreterでDNSルックアップが許可されており、完全に機能するC&C（コマンド&コントロール）チャネルが標準ネットワーク制御をバイパスして確立された。

DNSが攻撃ベクトルとして危険である理由は3つある。第1に、DNSは信頼されたプロトコルであり、ほとんどの環境でファイアウォールを通過する。第2に、DNSトラフィックは通常のネットワーク監視では精査されない。第3に、DNSクエリ内にデータをエンコードする手法は、従来のDLP（Data Loss Prevention）ソリューションでは検知が困難である。

この脆弱性は、AI IDEのサンドボックスモデル自体の再設計を迫るものである。コード実行環境をネットワークから完全に隔離するか、DNSを含むすべてのアウトバウンド通信を監視・制御するインスペクションレイヤーが必須となる。

攻撃面の構造分析: プロンプトインジェクション→ツール操作→IDE基盤機能の3段階連鎖

テストされたAI IDEの100%が共通の攻撃パターンに対して脆弱であったことは、個別のバグ修正では対処不能な構造的問題の存在を示している。攻撃チェーンは3段階に分解される。

第1段階は「コンテキストハイジャック（プロンプトインジェクション）」である。隠された命令が以下の経路から注入される──ルールファイル、README、ファイル名、悪意あるMCPサーバーからの出力。第2段階は「ツール操作」で、AIエージェントが正規のIDE機能を使って操作を実行するよう誘導される。第3段階は「IDE基盤機能の悪用」で、ビルトイン機能がデータ流出や攻撃者コードの実行に利用される。

この3段階連鎖の厄介な点は、各段階が単体では「正常な動作」に見えることである。プロンプトインジェクションはテキスト入力であり、ツール操作はIDEの正規機能であり、基盤機能の利用もまた正常なプロセスである。これは、従来のシグネチャベースのセキュリティ対策が根本的に機能しない新たな攻撃カテゴリの出現を意味する。

Next.js CVE-2025-55182大規模侵害でReact Server Componentsの構造的脆弱性が766ホストに波及したように、AI IDEの攻撃面はツールチェーン全体に連鎖拡大する性質を持つ。開発環境で一度コードが改ざんされれば、その影響はビルド・デプロイ・プロダクション環境に至るまで伝播する。

エンタープライズ多層防御設計: AI IDE統合の実装ガイドライン

以上の5大脆弱性クラスを踏まえ、エンタープライズ環境でAI IDEを安全に導入するための多層防御設計を提示する。

レイヤー1: 拡張機能ガバナンス

VS Code拡張機能のインストールをホワイトリスト方式で管理する。組織のセキュリティチームが承認した拡張機能のみを許可し、Marketplace全体へのオープンアクセスを禁止する。GlassWormやMaliciousCorgiの事例が示すとおり、ダウンロード数や評価は信頼性の指標にならない。定期的な拡張機能監査（インストール済み拡張機能のハッシュ検証、ネットワーク通信の監視）を実施する。

レイヤー2: MCP設定の制御

MCPサーバーの接続を組織管理下に置く。mcp.json等の設定ファイルの変更をファイル整合性監視（FIM）で検知し、未承認のMCPサーバー追加を即時ブロックする。プロジェクトローカルの.envや設定ファイルによるMCP自動起動を無効化する。IDEsasterの調査結果を踏まえ、すべてのMCPツール呼び出しに明示的なユーザー承認を要求する設定を強制する。

レイヤー3: トークン・認証情報の隔離

GitHubトークン、APIキー、認証情報をIDEプロセスから隔離する。短命トークン（Short-lived Token）の使用を強制し、トークンのスコープを最小権限に制限する。Codex GitHubトークン窃取の事例が示すとおり、1つのトークン漏洩がリポジトリ全体の侵害に直結する。CI/CD環境ではOIDC（OpenID Connect）フェデレーションを使用し、静的トークンの配置を排除する。

レイヤー4: ネットワークセグメンテーションとDNS監視

AI IDEのコード実行環境からのアウトバウンド通信を制限する。特にDNSトラフィックの異常検知が重要である。DNS over HTTPS（DoH）のブロック、内部DNSリゾルバの強制使用、DNSクエリログの分析（エントロピー分析によるデータエンコード検知）を実装する。AI実行サンドボックスからの外部通信はプロキシ経由に限定し、許可リスト方式で制御する。

レイヤー5: 開発者教育とインシデント対応

開発者に対し、AI IDEの攻撃面を理解させる教育プログラムを実施する。具体的には、プロンプトインジェクションの仕組み、不審な拡張機能の見分け方、MCPサーバー接続時のリスク評価手法を教育する。インシデント対応計画にAI IDE経由の侵害シナリオを追加し、SOCのプレイブックを更新する。

筆者の経験上、セキュリティ戦略はビジネスの制約を理解した上でないと絵に描いた餅になる。AI IDEの利便性を完全に排除することは現実的ではない。AIガバナンスROI測定のSEE-MEASURE-DECIDE-ACTモデルで示されたフレームワークを応用し、セキュリティ投資の効果を測定可能にすることで、経営層の理解を得ながら段階的に防御を強化するアプローチが現実解となる。

VS Codeエコシステムの構造的課題と今後の展望

VS Code Marketplaceのセキュリティモデルは、根本的な再構築を迫られている。2025年10月のKoi Securityの調査では、500以上の拡張機能から550以上の有効なシークレット（APIキー、トークン等）が検出され、うち100以上がMarketplace Personal Access Token（PAT）の漏洩であった。PATが漏洩すれば、攻撃者は正規の拡張機能に悪意あるアップデートを配信でき、インストールベース全体が一瞬で侵害される。

VS Codeフォーク（Cursor、Windsurf、Google Antigravity、Trae等）にも独自の脆弱性がある。2026年1月に発見された問題では、ハードコードされた「推奨拡張機能」が未登録のOpenVSXネームスペースを参照しており、脅威アクターがこれらのネームスペースを登録して悪意ある拡張機能を配布する攻撃ベクトルが存在した。

今後の展望として、以下の3つの構造的変化が予想される。第1に、拡張機能のコード署名とサンドボックス化の強化である。現状のVS Code拡張機能はNode.jsのフルアクセスを持つが、ブラウザ拡張機能と同様の権限モデルへの移行が不可避である。第2に、AI IDEベンダーによるセキュリティ認証制度の整備である。SOC 2 Type IIやISO 27001に準拠したAI IDE認証基準の策定が進むと見られる。第3に、AIエージェントの行動監査ログの標準化である。MCPツール呼び出し、ファイルアクセス、ネットワーク通信のすべてを不変の監査ログに記録し、事後検証を可能にする仕組みが求められる。

MCPサーバーエコシステムの産業化が進む中、セキュリティはAI開発ワークフローの「制約」ではなく「品質保証」として再定義される必要がある。脆弱性の発見と修正は、エコシステム成熟の証であると同時に、次の攻撃面の予兆でもある。

FAQ

ChatGPT VS Code拡張機能の脆弱性はすべて修正されたのか？

OpenAIは2026年1月30日までにCodexのコマンドインジェクション、2月20日までにデータ流出とDNS隠れチャネルの脆弱性にパッチを適用した。ただし、プロンプトインジェクションはLLMアーキテクチャの構造的制約に起因するため、完全な根絶は困難である。継続的なアップデート適用と組織レベルの防御策が必須である。

MaliciousCorgiのような悪意ある拡張機能を見分ける方法は？

ダウンロード数や評価は信頼性の指標にならない。拡張機能のネットワーク通信をプロキシで監視し、不審な外部通信がないか確認する。組織ではホワイトリスト方式の拡張機能管理を導入し、セキュリティチームが承認した拡張機能のみを許可することが最も効果的である。

AI IDEのMCP機能は無効化すべきか？

全面無効化ではなく、信頼できるMCPサーバーのみを許可リストで管理するアプローチを推奨する。mcp.json等の設定ファイルにファイル整合性監視を適用し、未承認の変更を即時検知する。プロジェクトローカル設定による自動起動は無効化すべきである。

DNS隠れチャネル攻撃を検知する方法は？

内部DNSリゾルバの強制使用、DNSクエリログのエントロピー分析（ランダム文字列のサブドメインを検知）、DNS over HTTPSのブロック、AI実行サンドボックスからのDNSリクエストの監視が有効である。SIEM/SOCのプレイブックにDNSトンネリング検知ルールを追加することを推奨する。

エンタープライズでAI IDEを安全に導入する最低限の対策は？

（1）拡張機能ホワイトリスト管理、（2）MCP設定のファイル整合性監視、（3）GitHubトークンの短命化とスコープ最小化、（4）AI実行環境のネットワーク分離、（5）開発者向けセキュリティ教育の5層を最低限実装すべきである。段階的導入でROIを測定しながら進めることが現実的である。

参考文献