AI開発ツール ブラウザ脆弱性「EMBRACE」、VS CodeとCodexは未修正で企業の対策が急務

AI開発ツールの内蔵ブラウザ脆弱性「EMBRACE」——何が起きているか

2026年10月29日、セキュリティ企業Forever SecurityのGal Weizman氏が、5つのAIコーディングアシスタントの内蔵ブラウザに共通する脆弱性クラス「EMBRACE」を公開した（HelpNet Security、Hackread.com）。影響を受けるのはVS Code、Cursor、GitHub Copilot、Codex、Claude Desktopの5製品で、脆弱性の種類は製品によって異なる。

最も深刻なのは、VS CodeとCodexに存在するファイル窃取の脆弱性だ。細工されたHTMLファイルを開発者が1クリックするだけで、SSHキー・クラウド認証情報（.aws/credentialsなど）・開発者トークンが外部に送出される可能性がある（HelpNet Security）。VS Codeでは「Webワーカーがフォルダ制限を回避する」経路、Codexでは「フォルダ制限そのものが存在しない」構造が悪用される。

パッチ対応状況は二極化している。CursorとGitHub Copilot（v1.1.29）、Claude Desktopはいずれも修正済みだが、VS CodeとCodexは2026年10月29日の公開時点で未修正のまま残されている（Hackread.com）。

AIを狙った情報漏洩が実際にどれだけ起きているかは、日本・世界の主なAIハッキング被害一覧で説明しています。

関連記事AIによる情報漏洩とは？原因・経路・企業の対策は？

AI開発ツールのブラウザ脆弱性が日本企業のリスク構造を変える理由

この問題を「海外のセキュリティ研究者の発見」として静観できない理由は、被影響ツールの普及規模にある。VS Codeは世界で約4000万人の開発者が利用しており、Codexの週間利用者数も500万人を超える（Hackread.com）。日本のソフトウェア開発現場においても、VS Codeは事実上の標準エディタとして浸透している。AI支援機能の導入が進む企業では、開発者が意識しないままこの脆弱性にさらされている状況が生まれうる。

攻撃手順の単純さが問題をより深刻にする。専門的な知識を持つ攻撃者が必要なのは、細工されたHTMLファイルを開発者のプロジェクトに紛れ込ませることだけだ。外部ベンダーから受け取ったコード、オープンソースリポジトリからクローンしたプロジェクト、チームメンバーが提出したプルリクエストなど、開発現場には外部起源のHTMLファイルが流入する経路が複数存在する。

日本のITベンダーやSIerが顧客コードを扱う受託開発の現場では、開発者のローカル環境に保存された認証情報が流出した場合、リスクは開発チームにとどまらない。クラウドインフラへの不正アクセスやソースコードリポジトリへの侵入は、委託元企業のシステムにまで波及しうる。サプライチェーン上の情報セキュリティ管理として、委託先の開発ツール環境を問われる局面が増えると考えられる。

ベンダーの対応姿勢についても直視が必要だ。Forever SecurityはCodexに関してOpenAIに2026年7月27日に報告したが、公開時まで応答も修正もなかった（AI Weekly）。VS Codeについて、Microsoftは「Workspace Trustの問題」として対応を拒否している（AI Weekly）。大手ベンダーであっても脆弱性報告への対応が保証されないという現実は、ツールを導入する企業側が主体的な自衛策を持つことの必要性を示している。

AI開発ツールのブラウザ脆弱性対策：今すぐ実施できる実務手順

未パッチのVS CodeおよびCodexを利用している組織向けに、HelpNet Securityが推奨する対応手順は以下のとおりだ。

1. 信頼済みプロジェクトの棚卸し：VS Codeでは各開発者マシンの設定ファイルから、Workspace Trustで信頼済みとしたプロジェクトを一覧化する。信頼の付与が適切かどうかを確認する起点となる。
2. HTMLファイルの精査：Forever Securityが公開した技術資料に記載のエクスプロイトパターンと、プロジェクト内のHTMLファイルを照合する。外部から受け取ったファイルや、マージ済みプルリクエストに含まれるHTMLを優先的に確認する。
3. 認証情報のローテーション：疑わしいHTMLファイルを開いた可能性がある開発者については、SSHキー・クラウド認証情報・APIトークンを速やかにローテーションする。
4. パッチ監視の仕組みの整備：VS Code・Codexの公式更新チャンネルを定期的に確認し、パッチが提供され次第、組織内への適用フローをあらかじめ決めておく。

組織全体の管理という観点では、開発者端末に導入されているAI開発ツールとそのバージョンを棚卸しし、パッチ適用状況を一元把握する仕組みが現実的な対応となる。MDMやエンドポイント管理ツールを運用するIT部門であれば、対象ソフトウェアのバージョン確認を既存の管理フローに組み込むことが考えられる。

AI開発ツールのブラウザ脆弱性の構造的背景と対応の限界

今回の脆弱性が「AI開発ツール固有の問題」として注目される背景には、Electronベースの構造的要因がある。VS Code・Cursor・GitHub CopilotはいずれもElectron上に構築されており、Chromiumの内蔵ブラウザがローカルファイルシステムやAIエージェントのAPIと接続する構造を持つ。この「ブラウザとネイティブ機能の橋渡し」部分は攻撃対象になりやすく、今後も類似の問題が繰り返し発見される可能性がある。

企業が考慮すべき現実的な制約もある。VS Codeはオープンソースプロジェクトであり、パッチの提供タイミングはMicrosoftの判断に依存するため、利用企業側が修正を強制することはできない。エクスプロイトパターンの照合には技術的知識が要求され、全社規模での実施には相応の工数がかかる。また、AI開発ツールは更新頻度が高く、新バージョンで再度脆弱性が混入するリスクは継続的に存在する。

一方、今回の公開が持つポジティブな意義も見逃せない。Cursorが報告から約1か月でパッチを提供したように、詳細な脆弱性情報の公開はベンダーの対応を促進する圧力として機能する。また、脆弱性クラスとして体系化されたことで、セキュリティ研究者コミュニティが同種の問題を発見・報告しやすくなる。ベンダー対応の透明性への要求は、中長期的に製品の安全性を高める方向に働くと考えられる。

日本の組織が取り得る現実的なスタンスは、ゼロトラストの原則を開発ツールにも適用することだ。どれほど信頼できるベンダーのツールであっても、ローカル認証情報へのアクセス権限を最小化し、認証情報の保存場所と有効期限を管理する姿勢が、AI開発ツール運用の基礎となる。特定のツールやバージョンに依存せず、「認証情報は漏洩しうる」という前提でアーキテクチャを設計することが、現段階では最も堅牢な対応と言える。

主要AI開発ツールの脆弱性リスクと対応状況：比較表

製品名	脆弱性の種類	報告日	ベンダー対応	パッチ状況（2026年10月時点）
VS Code	ファイル窃取（Webワーカーがフォルダ制限を回避）	2026年9月10日	「Workspace Trustの問題」として拒否（Microsoft）	未パッチ
Codex	ファイル窃取（フォルダ制限なし）	2026年7月27日	公開時まで無応答（OpenAI）	未パッチ
Cursor	コード実行（通信ブリッジ悪用）	—	迅速に対応・パッチ提供	パッチ済み（2026年10月1日）
GitHub Copilot	アドレスバー偽装	—	バージョン更新で対応（Microsoft）	v1.1.29でパッチ済み（2026年10月13日）
Claude Desktop	ファイル窃取	2026年7月23日（Forever Security）／7月24日（Noma Security）	Noma Securityの報告を受理・対応（Anthropic）	パッチ済み

出典：HelpNet Security（helpnetsecurity.com）、Hackread.com（hackread.com）、AI Weekly（aiweekly.co）

---

参考文献

• HelpNet Security「Researchers broke the browsers built into VS Code, Cursor, Copilot, Codex and Claude Desktop」（2026年10月29日公開）— https://www.helpnetsecurity.com
• Hackread.com「EMBRACE Vulnerability Found in AI Coding Assistants」（2026年10月29日公開）— https://hackread.com
• AI Weekly「EMBRACE: Browser Vulnerabilities in AI Development Tools」（2026年公開）— https://aiweekly.co