タブの中のIDEが、ワンクリックでGitHubトークンを差し出した

2026年6月2日、セキュリティ研究者のAmmar Askarが、github.dev — 任意のGitHubリポジトリで.を押すと到達する、ブラウザ内版の Visual Studio Code — のゼロデイに対する概念実証を 公開しました。 ゼロデイとは、公になったのと同じ瞬間に判明したため、ベンダーが 修正する時間を一切持てなかったバグのことです。今回の場合、Askarの 説明によれば、公開された詳細はMicrosoftに通知されてからおよそ 1時間後に出ました。彼は、Microsoftのセキュリティレスポンス センターへの過去の報告がどう扱われたかへの 不満 から、VS Codeの発見については完全な公開開示に踏み切ったと述べました。

この仕組みはじっくり見る価値があります。なぜならこれは、ある カテゴリ — 一回限りのバグではなく、ブラウザベースの開発ツールが 生み出し続けることになる攻撃の「形」 — のきれいな一例だからです。

プレビューペインは発射台であってはならない。

コードエディタは大量の信頼できないコンテンツをレンダリングします。 あなたが開いたMarkdownファイルはレンダリングされたプレビューに なります。Jupyterノートブックはその出力を表示します。これらの プレビューはウェブビューの中で動きます — エディタに埋め込まれた サンドボックス化されたミニブラウザで、悪意のあるREADMEが あなたのマシンをそのまま乗っ取れないよう、エディタ自身の権限から 意図的に隔離されています。

その壁こそが核心です。Askarのエクスプロイトはそれを越えました。

ウェブビューはメッセージパッシングチャネル — 両者が連携する ために使う狭いパイプ — を通じてメインのエディタと話します。その チャネルを悪用することで、信頼できないウェブビューの中で動く悪意の あるJavaScriptは、メインのエディタウィンドウで キーストロークを模擬 できました — 合成されたkeydownイベントです。それが選んだ キーストロークはCtrl+Shift+P、コマンドパレットを開く ショートカットであり、VS Codeが知っているほぼあらゆるコマンドを 実行できるテキストボックスでした。

そこから攻撃は、正当な機能をそれ自身に対して使いました。VS Codeは ローカルワークスペース拡張機能をサポートしています：プロジェクトの .vscode/extensionsフォルダに置かれた拡張機能で、リポジトリが 自前のツールを同梱できるようにするためのものです。悪意のある リポジトリは自分のファイルを支配しているので、自前の拡張機能を 同梱できます — そして通常なら「本当にこの公開者のコードを実行 しますか?」と尋ねる信頼プロンプトは、拡張機能のpackage.jsonに カスタムキーバインディングを細工することで回避されました。連鎖の 中で唯一の人間によるチェックポイントである公開者信頼ダイアログは、 一度も現れませんでした。

狙いは、あなたが開いたリポジトリではなかった。

この連鎖のペイロードはトークンです。github.devはGitHubであなたを サインインさせ、OAuthトークン — あなたの代理として動いている ことを証明するために、ブラウザがGitHubのサーバーに提示する認証情報 — を保持します。OAuthの要点は、トークンをスコープ化できることです： アプリは必要な狭いアクセスしか得るべきではありません。

このトークンは狭くありませんでした。Askarが 述べた ように、そのトークンは「あなたが操作した特定のリポジトリにスコープ されておらず、つまりあなたがアクセスできる他のすべてのリポジトリへの フルアクセスを持つ」 — 読み取りと書き込み、プライベートリポジトリも 含めて、というものでした。だから攻撃者が手に入れたのは、あなたが クリックして入った公開プロジェクトではありません。彼らが手に入れた のは、あなたのアカウントが到達できるすべてへの鍵でした：あなたの プライベートリポジトリ、アクセスがあるならあなたの雇用主の プライベートリポジトリ、それらのリポジトリに置かれたデプロイキーと シークレット、あなたが誰にも見せたことのないソース。概念実証は それを使って被害者のプライベートリポジトリを列挙しました — ほとんどの現役の開発者にとって、そのリスト自体が機微なものです。

これは一般化される部分です。ブラウザベースのIDEとクラウド開発環境が 便利なのは、まさにあなたの代わりに認証情報を運んでくれるからです。 github.devはGitHubトークンを保持します。クラウドIDEはクラウド トークンを保持します。ブラウザのタブの中で動くエージェント型 コーディングアシスタントは、コードをプッシュしAPIを呼び出すために 必要なものを何でも保持します。それらの一つひとつが、あなたが 書いていないウェブページからサンドボックス脱出ひとつ分しか離れて いない、高価値のシークレットなのです。

正直な部分：これは修正されたのか?

2つの報道、2つの異なる絵姿、そしてその差が重要です。

BleepingComputerは、執筆時点でこの問題を公式パッチもCVE割り当ても ないものとして説明し、手動の回避策を提示しました：github.devの クッキーとローカルサイトデータを消去し、初回サインイン警告が再び 現れるようにする、というものです。

The Hacker NewsはMicrosoftのエンジニアの声明を掲載しました。 パートナーソフトウェアエンジニアリングマネージャーのAlexandru Dimaは 「この問題はVS Code Desktopには影響しない」 と述べました — このバグは、あなたがマシンにインストールするアプリ ではなく、ブラウザでホストされるgithub.dev固有のものです。Microsoftは 後に、この脆弱性は「当社のサービスについては緩和済みであり、顧客側の 対応は不要」と述べましたが、これはあなたがダウンロードする クライアントパッチではなく、サーバー側の変更を指しています。

私たちは緩和を独立に検証できる立場にないので、脅威は終わったとは 言いません。私たちが語れるのは、こうした連鎖が成功したときに被害が どこに着地するかです — なぜならそれはアーキテクチャの問いであり、 アーキテクチャは、プレス声明を信じることに依存しない部分だからです。

IDEが実際に動く場所。

github.devが私たちにとって興味深いのは、ここです：エディタ全体が ウェブページなのです。ウェブビュー、コマンドパレット、拡張機能 ホスト、OAuthトークン — そのすべてがブラウザのタブの中に住んでいます。 つまり「これがどれだけの被害を与えられるか」という問いは、めずらしく、 Bromureがあらゆるタブについて答えるために作られたのと同じ問いなのです。

Bromureでは、すべてのタブが独自の使い捨て仮想マシンの中で動きます — Mac上の使い捨てLinuxゲストで、あなたのファイル、キーチェーン、他の タブへの経路はありません。github.devをBromureのプロファイルで実行 すれば、盗まれたOAuthトークン、悪意のあるウェブビュー、こっそり インストールされたローカルワークスペース拡張機能はすべて、その1つの VMにスコープされます。非永続セッションでウィンドウを閉じれば、 それらが住んでいた世界は消し去られます：トークンキャッシュ、クッキー、 拡張機能、ゲスト丸ごと、すべて消えます。

この配置が変えるものが2つ、変えないものが1つあります。

それはトークンが何に到達できるかを変えます。従来型のブラウザ では、あなたが持つすべてのGitHubセッションが1つのクッキージャーと 1つのプロファイルを共有します。あなたのgithub.devタブから持ち出された トークンは、そのブラウザが保持する他のすべての隣に座ります。Bromure では、github.devを独自のプロファイルで実行できます — 独自のVM、独自の クッキー、独自のストレージ — あなたの銀行、メール、他のGitHub アイデンティティから分離されます。使い捨てプロファイルの侵害は、 攻撃者に他のプロファイルのクッキーを与えません。それらは同じマシンに ないのです。

それは足がかりがどれだけ長く続くかを変えます。この連鎖で最も 価値のある一手は、こっそりインストールされた拡張機能です — あなたが エディタを再び開くたびに残る足がかりです。使い捨てセッションに対しては、 戻ってくる先がありません。拡張機能は、もはや存在しないVMにインストール されていたのです。

これが解決しないもの。

それは盗まれたトークンを盗まれていない状態には戻しません。悪意のある セッションが生きている間、OAuthトークンは本物であり、攻撃者はそれを 使って、自分のインフラからリアルタイムであなたのプライベート リポジトリを列挙し読み取ることができます。隔離はシークレットが住む 場所を封じ込めます。それはインターネット越しにGitHubのサーバーに 手を伸ばして、攻撃者がすでに保持している認証情報を失効させることは しません。そこでの緩和策は通常のものです：短命で厳密にスコープされた トークン、何か怪しいことがあった後のセッション失効、そしてベンダー — ここではMicrosoft — が脱出を塞いで、そもそもトークンに到達できない ようにすること。

1つの比較については正確にしておく価値があります。なぜなら混同されや すいからです。BromureはそもそもどんなChrome拡張機能のインストールも 許可しません — サンドボックス化されたものも、キュレーションされた ものも、どのストアからのものも。これは意図的なプロダクトの姿勢です： ブラウザ拡張機能は現代のウェブで最も悪用される足がかりの1つなので、 Bromureはそのカテゴリ自体を取り除きます。しかしこの話の中の拡張機能は VS Codeの拡張機能で、github.devのウェブアプリが自身のエディタに インストールしたものです — ページの周囲ではなく中に住む、Chrome拡張 機能とは別物です。Bromureの拡張機能なしルールは、github.devの中まで 手を伸ばしてそれを止めることはしません。Bromureがするのは、エディタ 全体を、トークンも拡張機能も丸ごと、あなたが捨てられるVMの中に封じ込める ことです。

盗むトークンが存在しなければ別だが。

同じアーキテクチャを使う、より鋭い方法があり、それは何のコストも かかりません：あなたが誰であるかをあなたが何を訪れるかから 分離することです。

連鎖全体は1つのシークレット — あなたがサインインしたためにgithub.devが 保持するOAuthトークン — に到達するために存在します。そのトークンは、 あなたが自分のコードに取り組む場所にだけ存在すればいいのです。だから それにちょうどその分だけの領土を与えましょう：GitHubにサインインした 専用のBromureプロファイルで、そこであなたのリポジトリと、あなたが すでに信頼しているリポジトリを開きます。トークンはそこに住み、 見知らぬ者のコードはそこに入りません。

それ以外のすべて — リンクから来た興味深いリポジトリ、誰かが投稿した 概念実証、あなたが評価している依存関係 — は、あなたが誰でもない場所で 開きます：一度もGitHubにサインインしていないプロファイルです。 github.comのコードを匿名の訪問者として読みましょう。エディタに手を 伸ばしても、サインインしていないgithub.devには差し出す価値のあるものが 何もありません。認証されていないセッションは、保持していないトークンを 漏らせません。エクスプロイト連鎖は、もし動くとしても、ポケットが空の 使い捨てVMの中で動きます。

それは防御の形を変えます。封じ込めは、トークンが奪われた後の ステップ5で被害を制限します。分離は、ステップ1で連鎖の首をはねます： 悪意のあるリポジトリは認証情報に一度も出会いません。この規律は1行に 収まります — 働く場所ではサインインし、さまよう場所では誰でもない — そしてBromureのプロファイルは、それをセキュリティポリシーではなく 2つのアイコンの習慣にします。

この一般的な教訓は、この特定のバグより長く生きます。開発のより多くが ブラウザに移るにつれて — クラウドIDE、github.dev、タブの中で動き プッシュアクセスを運ぶエージェント型コーディングエージェント — それらの ツールが保持する認証情報は常在する標的になり、あなたが書いていない ページからウェブビュー脱出ひとつ分しか離れていません。守れる姿勢は 「IDEの中のサンドボックスを信頼する」ことではありません。そのサンド ボックスはいずれ漏れると想定し、それが漏れ込むページが使い捨てであり かつ無一文であるように物事を配置することです。

危険なタブを、それ自身の世界 — あなたが誰でもない世界 — で動かしましょう。 何かが入り込んでも、奪うものは何もなく、そしてあなたはどのみちその 世界を閉じます。

それがBromureの目的です。インストールして、自分自身のGitHubに専用の プロファイルを与え、他人のコードはすべて見知らぬ者として訪れ、最悪の ケースをあなたが閉じられるウィンドウにしましょう。