VSCode webview脆弱性でgithub.devから1クリックGitHub OAuthトークン窃取——修正PRマージ済み、公開版反映待ち

この記事は約20分で読めます。

2026年6月2日、セキュリティ研究者Ammar Askar氏が、Visual Studio Codeのwebview実装に存在する脆弱性を実証コード（PoC）付きで完全公開しました。攻撃者が用意した github.dev リンクを開発者が1回クリックするだけで、被害者本人のGitHub権限でアクセス可能なリポジトリ（プライベートを含む）に対して、読み取り・書き込み操作が可能なGitHub OAuthトークンが攻撃者の手に渡る、というインパクトの大きい内容です。Microsoftのリポジトリでは、本稿確認時点でIssue #319593はすでにClosed状態となっており、修正PR #319700は release/1.122 ブランチへ、PR #319704は main ブランチへマージ済みです。GitHub上では #319704 が「#319700 from release/1.122 のcherry-pick」として扱われており、いずれも #319593 の修正に関連するPRです。ただしIssueには「unreleased（Patch has not yet been released in VS Code Insiders）」ラベルが付与されており、利用者向けの安定版・Insidersビルドに修正が反映されるまでは、引き続きgithub.devの利用や不審なリンクに注意が必要です。CVEは本稿確認時点で未付与です。

本件は脆弱性そのもののインパクトに加え、(1) github.devが渡すOAuthトークンが「リポジトリ単位のスコープを持たない」設計、(2) VSCode webviewの did-keydown メッセージハンドラが偽造キーイベントを区別しない仕様、(3) ローカルワークスペース拡張機能がパブリッシャ信頼チェックを実質的に迂回できる挙動、という3つの設計判断が連鎖して成立する構造的脆弱性である点に注意が必要です。直前の記事で取り上げたMiasmaワーム（Red Hat npmサプライチェーン攻撃）が ~/.claude/settings.json と .vscode/tasks.json を永続化先として利用したのに続き、AI支援開発ツール本体の攻撃面が連続して露出する展開となっています。

背景——github.devとは何か、なぜトークンが「強い」のか

github.devは、GitHubが提供するブラウザ完結型の軽量VSCodeエディタです。任意のリポジトリのURLを github.com から github.dev に書き換えるか、UIのドロップダウンメニューから選択することで起動でき、リポジトリのファイル閲覧・編集・コミット・プルリクエスト発行までブラウザ内で完結できます。実態としてはVSCodeの100万行規模のTypeScriptコードベースをほぼそのままブラウザ上で動かしている構成で、Electron版デスクトップVSCodeに近い多くの機能が、ブラウザ上でも利用できます。

この機能を成立させるため、ユーザーが github.com から github.dev に遷移すると、github.com が github.dev に対してOAuthトークンをPOSTで渡す仕組みになっています。Askar氏が問題視するのは、このトークンが「ユーザーが現在開いているリポジトリにスコープが絞られていない」点です。リポジトリAをgithub.devで開くために発行されたトークンが、そのユーザーがアクセス可能なリポジトリB・C・D（プライベートも含む）への完全な read/write 権限まで持ってしまう、という設計です。

この「強すぎるトークン」の存在に加え、VSCodeの巨大なコードベースがブラウザで動いているという面積の広さが、github.devを脆弱性研究者にとって魅力的な攻撃面にしているとAskar氏は述べています。Hacker Newsのスレッドでも、複数のコメント投稿者が「ブラウザ版エディタが永続的にGitHubセッションへサインインしている設計そのものが根本的な問題」「リポジトリ単位の一時トークンであれば被害は局所化できたはず」と指摘しています。

VSCode webviewセキュリティモデルとdid-keydown問題

VSCodeのwebviewは、Markdownプレビュー・Jupyter Notebookの出力レンダリング・拡張機能のカスタムUIなどに使われる仕組みで、メインのVSCodeウィンドウ（vscode-file:// オリジン）とは異なるオリジン（vscode-webview://）のiframeで隔離されています。これは、たとえばユーザーが開いたJupyter Notebookに埋め込まれたJavaScriptが、Node.js APIを経由してVSCode本体・OSにアクセスできないようにするためのサンドボックス境界です。

クロスオリジンの隔離は強固ですが、ユーザビリティの観点からは「Markdownプレビュー内でテキストを選択したらエディタ側のカーソルも追従させたい」「webviewにフォーカスがある状態でもVSCodeのキーボードショートカット（Ctrl+Shift+P でコマンドパレットを開く等）が効いてほしい」といった要件が出てきます。VSCodeはこれを Window.postMessage() APIによるwebview↔ホスト間のメッセージパッシングで実装しており、特にキーボードショートカットについては、webview側で keydown イベントを捕まえてホスト側に did-keydown メッセージを送り、ホスト側がそれを「ユーザーのキーボード入力」として処理する設計になっています。

Askar氏が突いたのは、この did-keydown メッセージのソースを区別する仕組みが存在しないという点です。webview内の任意のJavaScriptは、本物のユーザー入力と区別不能な形で did-keydown メッセージを postMessage 経由でホストへ送信できます。結果として、信頼境界（webviewはuntrusted）の片側から、もう片側（VSCode本体の特権APIにアクセス可能）に「ユーザーが意図したキー操作」として任意のショートカットを発火させられる構造です。Issue #319593 の本文でAskar氏は、ターミナル系のショートカット（Ctrl+Shift+Alt+` で新規ターミナル、F6 でフォーカス移動、Ctrl+Shift+V でターミナルへのペースト）を組み合わせれば、攻撃者が制御するテキストをターミナルにペーストさせるシナリオも実現可能だと補足しています。

攻撃チェーン——Jupyter Notebookから拡張機能インストール、github.devトークン窃取へ

Askar氏が公開したPoCの中核は、悪意あるGitHubリポジトリにJupyter Notebook（.ipynb）とローカルワークスペース拡張機能を組み合わせて配置し、被害者がgithub.dev経由でそのNotebookを開いた瞬間に攻撃が完結する設計です。各ステップで使われるVSCodeの正規機能は以下の通りです。

第1段階として、Notebook内のMarkdownセルに <img src="data:foobar" onerror="..."> 形式のタグを置くことで、webview iframe内で任意のJavaScriptを実行できます。これはJupyter NotebookがHTMLとJavaScriptのレンダリングを許可しているための正規挙動で、隔離されたwebviewオリジン内での実行に留まる前提のものです。

第2段階として、リポジトリ直下に .vscode/extensions.json を配置し、攻撃者の拡張機能を「推奨拡張機能」として登録します。github.devは、推奨拡張機能が定義されたワークスペースを開くと「この拡張機能をインストールしますか？」という通知を画面右下にポップアップさせる挙動を持ちます。webview内のJavaScriptはこのポップアップが現れるのを待ち、Ctrl+Shift+A（「Notifications: Accept Notification Primary Action」のデフォルトキーバインド）を偽造 did-keydown として送出することで、通知のプライマリボタン（インストール）を自動でクリックします。

第3段階として、リポジトリ内の .vscode/extensions/ 配下に配置された拡張機能をローカルワークスペース拡張機能として読み込ませます。VSCode 1.89以降で導入されたこの機能は、信頼済みワークスペース内に限り、Marketplaceを経由せずローカルファイルから拡張機能をインストールできる仕組みです。github.dev/webワークスペースは常に信頼済み扱いになるため、第三者発行の拡張機能に対する「Trust Publisher」確認ダイアログ（VSCode 1.97で導入されたパブリッシャ信頼システム）も実質的にスキップされます。

第4段階として、このローカル拡張機能の package.json の contributes.keybindings セクションでカスタムキーバインド（例：Ctrl+F1）を登録し、workbench.extensions.installExtension コマンドに skipPublisherTrust: true オプションを付けて、攻撃者が公開した別の悪性拡張機能をMarketplaceからインストールさせます。webview側JavaScriptが続けて偽造 Ctrl+F1 キーイベントを送出することで、このコマンドが発火し、信頼ダイアログを経由せずに拡張機能がインストールされます。

第5段階として、インストールされた拡張機能が https://api.github.com/user/repos を呼び出してユーザーがアクセス可能な全リポジトリ（プライベート含む）を列挙し、github.devセッションが保持するOAuthトークンとともに攻撃者へ送信します。Askar氏のPoCでは、デモのため画面上に取得したトークンとリポジトリ一覧を表示する形で実証されていますが、攻撃者が運用するなら任意の外部エンドポイントへ静かに送信する形になります。

全工程は初回クリックから約1分以内で完了し、ユーザー側に追加操作は一切要求されません。github.devへの遷移に追加の確認やリポジトリ単位のCSRF的な保護がないため、インターネット上のあらゆるリンクから被害者を攻撃用ワークスペースへ誘導できます。

デスクトップVSCodeへの影響——リポジトリclone必要だがRCE到達可能

同じwebview実装の脆弱性はデスクトップ版VSCodeにも存在しますが、Askar氏によれば、デスクトップ版で攻撃を成立させるには被害者にリポジトリをcloneさせてNotebookを開かせる必要があり、ハードルは上がります。ただし、デスクトップVSCode上で拡張機能がインストールされた場合、拡張機能はElectron経由でNode.js API（child_process 等を含む）に制限なくアクセスできるため、結果として完全なリモートコード実行（RCE）に到達します。github.devは「ブラウザ内で完結するためRCEには直接到達しない代わりに1クリックで成立」、デスクトップ版は「クローン手順が要るがRCEまで到達」というトレードオフです。

Askar氏は、もしwebview内でMarkdownプレビュー側にXSS可能な経路があれば、リンクをクリックさせるだけでデスクトップ版のRCEも実現できる経路があったと指摘しています。実際にはVSCodeがMarkdownプレビューに対して script-src 'none' のContent Security Policyを適用し、レンダリングにDOMPurifyを使用していることで、この最悪ケースは防がれていると評価しています。「VSCodeはiframeだけに頼らず多層防御を効かせている」というのが研究者からの評価点で、これは記事の文脈として公平に紹介すべき部分です。

修正内容と公開状況——Issue Closed、PR #319700/#319704マージ済み、unreleased段階

本稿確認時点で、Microsoft VSCodeリポジトリでは本件への修正がすでに進行しています。Issue #319593はClosedとなり、修正PR #319700は release/1.122 ブランチへ、PR #319704は main ブランチへマージされています（#319704は #319700 のcherry-pick扱い）。アサインは mjbvz（VSCode開発者Matt Bierner氏）です。

cherry-pick PR #319704のタイトル「Confirm opening notebooks in serverless web sessions and skip accepting context for the installExtension command」から読み取れる修正の方向性は2つあります。第1に、serverless web sessions（github.dev等のブラウザ環境）でNotebookを開く際に確認ダイアログを表示するようにし、被害者の意図しない自動的なNotebook展開を防ぎます。これは攻撃チェーン第1段階（.ipynb 自動読み込み経由でのwebview JavaScript発火）に対するブレーキとして働きます。第2に、installExtension コマンドが「accepting context（自動受諾のコンテキスト）」をスキップするようにし、偽造キー入力を起点とした拡張機能の自動インストールを成立させないようにします。これは攻撃チェーン第2〜第4段階（推奨拡張機能通知の偽自動受諾、ローカルワークスペース拡張機能経由の skipPublisherTrust バイパス）を直接断ち切る修正です。

ただし、Issueには「unreleased（Patch has not yet been released in VS Code Insiders）」ラベルが付いており、修正コードはマージされたものの、利用者向けのInsidersビルド・安定版ビルドにはまだ反映されていない状態です。Milestoneは、Issue #319593 が1.124.0（2026年6月8日期限）、PR #319704 が1.122.1（release/1.122 系列）となっており、利用環境への配布タイミングはMicrosoft側のリリースサイクルに依存します。本ブログ読者の運用環境では、配布完了までの期間中、攻撃が成立し得る前提で防御策を取る必要があります。

完全公開の背景——研究者のMSRC評価とVSCode脆弱性対応への問題提起

本件で特異なのは、研究者が完全公開を選択した点と、その理由として明示的にMSRCの過去対応を挙げている点です。Askar氏のブログによれば、過去にVSCodeの別の脆弱性をMSRCに報告した際、(1) 脆弱性は静かに修正されたものの修正に対するクレジットがなかった、(2) セキュリティ影響なしと分類された、という経緯があったとされます。さらに、Askar氏は2025年5月のStarLabsによる別のVSCode XSS→RCE報告（こちらも「Ineligible」「Low severity」と分類されたもの）を引き合いに、MSRCのVSCode脆弱性に対する姿勢に改善が見られないという認識を示しています。

そのうえで、Askar氏は「VSCodeの研究者がPoCまで作り込む労力に対する敬意が払われない以上、自分が取れる数少ないレバーの一つとして、今後のVSCode脆弱性は完全公開を選ぶ」と表明しています。今回の公開も、MSRCには通知せず、GitHubのセキュリティ担当者へ公開1時間前に「礼儀として」連絡しただけ、と本人がブログで明記しています。同時にAskar氏は「VSCodeチームには修正策を検討する時間が必要だったことは認識しており、UI/UXとセキュリティのトレードオフが本質的に難しい問題であることは理解している」とも述べており、責任ある立場のニュアンスを残しています。

本ブログとしてはこの完全公開判断の是非には踏み込みませんが、研究者側からMSRC（特にVSCode部門）に対するこうした不満が継続的に表明されている事実は、VSCodeを業務利用する組織のリスク評価に関わる材料として記録すべきものと考えます。MSRCが「VSCodeはオープンソースのため脆弱性報奨金の対象外」「ブラウザベース機能はOut of Scope」とする運用は以前から知られており、これが研究者のインセンティブ構造を歪めて完全公開を増やしているとすれば、利用者側のリスクとしても無視できません。なお、本件においては結果的に公開からわずか1〜2日でVSCodeチームが release/1.122 への修正・main への cherry-pick まで到達しており、対応速度自体は迅速だった点は付記すべきでしょう。

Miasmaからの連続性——AI支援開発ツール攻撃面の連続露出

本ブログでは前回、Red Hat npmサプライチェーン攻撃「Miasma」を取り上げました。Miasmaの永続化機構は ~/.claude/settings.json（Claude Code）と .vscode/tasks.json の "runOn": "folderOpen" という、AI支援開発ツールの設定ファイルを利用したものでした。今回のwebview脆弱性は、VSCode本体の信頼境界そのものに存在する設計上の問題であり、攻撃者がリンクを1つクリックさせるだけで被害者の全GitHubリポジトリへの書き込み権限を握れます。サプライチェーン側（拡張機能、tasks.jsonによる永続化）と本体側（webview信頼境界）の両方から、AI支援開発ツールの攻撃面が同時期に露出している状況です。

さらに視野を広げると、2026年5月にはTeamPCPによるNx Console拡張機能侵害でGitHub内部リポジトリ約3,800件が窃取された事案も発生しており、VSCode拡張機能エコシステム自体が攻撃チェーンの常用経路になりつつあります。github.devのOAuth設計、VSCode webviewのキーイベント転送、拡張機能Marketplaceの信頼モデル、ローカルワークスペース拡張機能の信頼バイパス挙動——これらが個別の小さな仕様判断としては合理的でも、組み合わさったときに「1クリックで全リポジトリ侵害」という結果を生む構造的な問題があらためて可視化されたのが本件です。

公開版反映待ち期間の暫定対応

修正は release/1.122 および main ブランチへマージ済みですが、利用者向けビルドへの反映を待つ期間、組織・個人が取れる対応として、Askar氏が示した緩和策と、それを補強するいくつかの運用上の追加策があります。

第1に、github.devを一度でも利用したことがある場合、ブラウザに保存された github.dev ドメインのCookieとローカルサイトデータをクリアすることが推奨されます。Chrome系ブラウザの場合、URLバー左端のアイコン →「Cookieとサイトデータ」→「オンデバイスのサイトデータを管理」から、github.dev 関連の全ドメインのデータを削除します。これにより、次回 github.dev にアクセスする際に「拡張機能 GitHub Repositories がGitHubでサインインしようとしています」という確認ダイアログが表示されるため、不審なリンクから誤って攻撃を成立させる前に気付けます。

第2に、github.devを業務で使用していない、あるいは利用頻度が低い組織では、ブラウザ拡張機能や企業プロキシ側で github.dev ドメインへのアクセスをブロックする運用も検討に値します。特に、開発者がプライベートリポジトリへの書き込み権限を持つアカウントでgithub.devを過去に開いたことがある場合、ユーザー教育だけに頼るのではなく、技術的な遮断を併用する方が確実です。

第3に、github.devで過去にインストールした拡張機能の一覧を確認し、認識のないものを削除する作業も推奨されます。github.dev画面の拡張機能ビューから一覧を確認できます。

第4に、組織全体のGitHubアクセストークン・PAT・拡張機能ベースのOAuthトークンに対しては、修正が利用環境に反映されるまでの間、定期的なローテーションと不審なAPI呼び出し（/user/repos への突然の大量列挙等）の監視を強化することが望ましいです。GitHub組織管理者は、組織のセキュリティログ（OAuth app installation events、Personal access token activity）を改めて確認することを推奨します。

VSCode本体のアップデートに関しては、Issue #319593のラベル「unreleased」の状態が続く期間中は脆弱な状態が継続するため、利用者向けの VS Code Insiders または Stable リリースに反映されるまでは、各リリースノートをウォッチし、修正が反映された版が降りてきた時点で速やかに更新する運用が望ましいでしょう。

webview信頼境界とOAuthスコープ設計、それぞれの教訓

本件から取り出せる教訓は2層あります。技術的には、サンドボックス境界を postMessage で繋ぐ際、メッセージのソース（ユーザー入力か、untrusted webview内のスクリプトか）を識別する仕組みを欠くと、UX上の便宜のために設けた経路が攻撃チェーンの中核になり得る、ということです。VSCodeのケースでは「webviewにフォーカスがある状態でもキーボードショートカットを効かせたい」という極めて妥当なUX要求が、結果的に「webviewから本体のキーバインドを任意発火できる」という事態に繋がりました。同種の問題はElectronベースの開発者ツール一般に潜在する可能性があり、Markdownプレビュー・Notebookレンダリング・カスタムUIを多用する他のIDE/エディタの監査でも参考になる視点です。

運用・設計上は、強力すぎるOAuthトークンを長寿命で発行する設計そのもののリスクが浮き彫りになりました。github.devが「現在開いているリポジトリだけ」にスコープを絞った短寿命トークンを使う設計だったなら、本件の被害はそのリポジトリの読み書きに限定されていました。クラウドIDEやブラウザベース開発ツールが普及するなかで、「OAuthトークンの最小権限化」「リポジトリスコープごとの一時資格情報」が改めて重要なセキュリティ原則として再認識されるべき事例です。

本ブログでは、Miasma（Red Hat npm経由のサプライチェーン攻撃）、ClickFix偽Claudeインストーラー、GlassWorm、Cline・Trivy、偽OpenAI Privacy Filter、と続けてAI支援開発ツール・パッケージマネージャ周辺のセキュリティ事案を取り上げてきました。VSCode webview脆弱性はこの系譜に「IDE本体の信頼境界そのものへの直接攻撃」という新軸を加えるもので、AI開発ワークフローのセキュリティを考えるうえで重要な事例です。今後CVE付与、Insiders/安定版へのパッチ降下動向、MSRCのVSCode脆弱性対応運用について、継続的なウォッチが必要でしょう。

関連記事

ソース

一次情報・公式情報

製品ベンダー情報

  • 本記事執筆時点で、MicrosoftおよびGitHubからの独立した公式セキュリティアドバイザリは未発行（修正はGitHub上のIssue/PR経由で進行）

参考情報

slug: vscode-github-dev-webview-1click-token-theft

コメント

タイトルとURLをコピーしました