VS Codeゼロデイ：ワンクリックであなたのGitHubトークンが盗まれる

その背景には、以前にAskar氏が報告したVS Codeの脆弱性を、マイクロソフトが彼へのクレジット（謝辞）なしに、ひっそりと修正したという経緯がありました 。彼はMSRCのプロセスに「もはや関わる気はない」と明言しています 。この過去の問題は、最初にGitHubのバグ報奨金プログラム「HackerOne」に報告されましたが、「対象範囲外であり、MSRCに報告するように」と門前払いされ、結果的に報酬も評価も得られないまま終わったのです 。この経験が、今回の全面公開という強硬手段につながりました。

攻撃の仕組み：4段階の連鎖攻撃

この攻撃は、github.devのセキュリティ境界をすべてすり抜けるために、3つの脆弱性を巧みに組み合わせたものです。

1. Webviewのキーボードイベント転送機能

VS CodeのWebviewは、Jupyter NotebookやMarkdownのプレビューなどを安全に表示するための、隔離されたサンドボックス領域です。しかし、キーボードショートカットを使えるようにするため、エディタはこのサンドボックス内で発生したキーイベントを、メインのエディタプロセスへ転送する仕組みになっています 。この「便利な機能」が、攻撃の侵入口となります。

2. 偽装されたキーストロークの注入

攻撃者のリポジトリに含まれる悪意のあるJupyter Notebookが、サンドボックスからメインウィンドウへ向けて、偽装したキーボードイベント（例：Ctrl+Shift+A、Ctrl+F1）を送信します 。このキー入力は、拡張機能のインストールコマンドを裏で実行し、本来表示されるはずの「発行元が信頼できない」といった警告ダイアログをバイパスしてしまうのです 。

3. ローカルワークスペース拡張への「暗黙の信頼」

攻撃者のリポジトリには、.vscode/extensionsフォルダにあらかじめ悪意のある拡張機能が仕込まれています。github.devは、ワークスペースと一緒に提供される拡張機能を「暗黙的に信頼」するため、この不正なプログラムはユーザーの許可を一切求めることなく、自動的にインストールされてしまいます 。

4. OAuthトークンの奪取

インストールされた不正な拡張機能は、github.devの実行環境への完全なアクセス権を手に入れます。この環境には、github.comからgithub.devへリポジトリを開くたびに自動的に送信されるGitHub OAuthトークンが存在します。ここで極めて重要なのは、このトークンの権限範囲が、現在開いているリポジトリだけに限定されていないことです。 トークンは、ユーザーがアクセス可能な全てのリポジトリに対する完全な権限を保持しています 。

拡張機能はこのトークンを抽出し、攻撃者のサーバーへ送信します。これにより、攻撃者は被害者の全プライベート・パブリックリポジトリを読み書きできるようになります 。

マイクロソフトの対応

マイクロソフトは2026年6月2日にこの脆弱性を認識し、自社のサービス（具体的にはgithub.devとWeb版VS Code）に対する緩和策を実施したと発表しました 。

6月3日には、ブラウザ版でNotebookを開く際に信頼確認のステップを追加したり、拡張機能のインストールコマンドが任意の呼び出し元情報を受け付けないようにするといった、サーバーサイドでの修正が行われました 。6月4日には、さらにWebviewのイベント処理に関する制限が追加されています 。

マイクロソフトは、この問題はデスクトップ版のVS Codeには影響しないとしています 。しかし、「ワークスペースの拡張機能を十分な検証なしに信頼する」という根本的な設計思想は、信頼できないリポジトリをローカルで開くユーザーにとっては、引き続きリスクとなり得ます。

本件の注目すべき3つの特異点

1. 攻撃の起点が「URL」であること：被害者はファイルをダウンロードしたり、ターミナルでコマンドを実行したりする必要は一切ありません。攻撃者と被害者を結ぶのは、ブラウザで開くただのリンクだけです 。

2. トークンの権限範囲が極めて広範であること：github.comからgithub.devへ渡されるOAuthトークンが、表示中のリポジトリに限定されていない点です。これは、ある開発者が公開オープンソースプロジェクトの作業中にこの攻撃を受けた場合、その開発者の勤務先のプライベートリポジトリの認証情報までもが漏洩する危険性があることを意味します 。

3. 「ワークスペースの信頼」が逆手に取られたこと：スムーズな開発体験のために用意された機能が、そのまま悪意あるプログラムの「自動実行」を許すメカニズムへと変貌した点です。

同時発覚：AIエージェント「OpenClaw」を狙う5つのゼロデイ脆弱性

同じく2026年6月初旬、セキュリティ研究者らは、AIエージェントフレームワーク「OpenClaw」に、許可されたユーザーになりすまし、AIエージェントへのアクセス権を乗っ取ることを可能にする5つのゼロデイ脆弱性を公開しました 。

問題の根源は「分散した信頼」

根本原因は、そのアーキテクチャにあります。OpenClawはTelegram、Slack、Discord、WhatsAppなど15種類ものメッセージングプラットフォームに対応していますが、各プラットフォーム向けのアダプタが、ユーザーを認可する仕組み（許可リストの処理など）を個別に、そしてバラバラに実装しているのです 。

セキュリティ上重要な「誰が許可されたユーザーか」を判断するために、表示名のような、ユーザーが自由に変更できる情報が使われており、その検証方法もプラットフォームごとにバラバラです 。このため、攻撃者は以下のような方法で信頼の境界を突破できます。

• あるプラットフォームで、自分の表示名を許可されたユーザーのものに変更するだけで、簡単になりすますことができます 。
• 各プラットフォームの拡張機能で一貫性のない本人確認処理を悪用し、ある場所では有効な信頼チェックを、別の場所ではすり抜けることができます 。
• 最終的に、シェルへのアクセス権やAPIキーといった強力な権限を持つAIエージェント自体を乗っ取ることが可能になります 。

この問題は、OpenClawの設計全体に潜む構造的な欠陥を示しています。2026年6月3日付けのarXivに掲載されたセキュリティ分析では、実行ポリシー、ゲートウェイ、チャネル、サンドボックスなど複数のアーキテクチャ層にまたがる脆弱性の存在が指摘され、その根底には「統一されたポリシー境界」ではなく「各層・各機能呼び出しでの場当たり的な信頼の強制」という設計思想があると分析されています 。また、シンガポールのサイバーセキュリティ機関（CSA）も、2026年5月下旬にOpenClawの未修正の脆弱性や弱いアクセス制御に関する注意勧告を発出しています 。

この一連の出来事は、便利さの裏に潜む信頼の設計が、いかに容易く悪用され得るかを、開発者とプラットフォーム提供者の双方に突きつけています。