一個撳擊嘅陰謀：VS Code 漏洞點樣一Click偷晒你全部GitHub權限

2026年6月2號，安全研究員 Ammar Askar 掟出一個全副武裝嘅概念驗證攻擊程式，將一個撳擊變成完整嘅 GitHub 帳戶奪取。目標唔係咩鬼祟嘅第三方網站——而係 github.dev，微軟自己嘅瀏覽器版 VS Code 編輯器。只要開一個精心設計嘅 Repository 連結，受害人就不知不覺咁交出一個 OAuth Token，俾攻擊者有晒讀寫權限去掂佢所有掂得到嘅 Repo，包括私人嘅 。

成條攻擊鏈唔使 30 秒就完成，除咗嗰最初嘅一撳之外，完全唔需要受害人再有任何互動。呢單嘢冇申請 CVE 編號，成個標準漏洞披露流程被直接繞過 。

披露背後嘅信任破裂

Askar 今次直接繞過微軟安全回應中心（MSRC）掟 PoC 出街，係刻意而為。佢通知咗 GitHub 一個舊相識，一個鐘頭之後就公開咗攻擊程式 。原因係：佢之前回報過一個 VS Code 漏洞，微軟竟然靜靜雞修復咗，提都冇提佢個名 。

佢好坦白咁話，對再走 MSRC 嗰套流程「完全冇興趣」。之前嗰個 Bug 最初係報去 GitHub 嘅 HackerOne 計劃，對方明確話呢個唔關佢哋事，叫佢自己去搵 MSRC——呢種官僚嘅交波遊戲，結果就係個發現既冇賠償，又冇人認頭 。

攻擊點運作：四層攻擊鏈

呢個 Exploit 將三個漏洞結合成一條天衣無縫嘅攻擊鏈，繞過晒 github.dev 所有安全邊界。

1. Webview 鍵盤事件轉發

VS Code 嘅 Webview——即係用嚟隔離 Jupyter Notebook、Markdown 預覽嗰啲沙箱——本應係安全隔間。但為咗令鍵盤快捷鍵喺入面可以用，編輯器會將沙箱入面嘅按鍵事件轉發去主編輯器程序 。

2. 模擬按鍵注入

攻擊者 Repository 入面嘅惡意 Jupyter Notebook，會由沙箱 Webview 發出模擬鍵盤事件（Ctrl+Shift+A、Ctrl+F1）射入 VS Code 主視窗 。呢啲按鍵會靜靜雞觸發「安裝 Extension」指令，仲會繞過嗰個正常情況下會攔住唔受信任 Extension 嘅發行者驗證對話框 。

3. 本機工作區 Extension 信任

攻擊者嘅 Repository 入面，有個預先封裝好嘅 VS Code Extension，放喺 .vscode/extensions 資料夾。因為 github.dev 將跟住工作區一齊送嚟嘅 Extension 視為隱含信任，呢個惡意 Extension 安裝嗰陣完全唔會有任何權限提示 。

4. OAuth Token 外洩

一旦行起咗，呢個惡意 Extension 就拿足 github.dev 執行環境嘅權限。呢個環境入面有個 GitHub OAuth Token，係 github.com 喺你開任何 Repository 嗰陣，靜靜雞 POST 去 github.dev 嘅。最攞命嘅係，呢個 Token 唔係只限你開緊嗰個 Repo——佢係拎住你成個 GitHub 帳戶嘅完整權限 。Extension 抽走 Token，再問 GitHub API 拎受害人嘅私人 Repository 清單，然後將 Token 同 Repo 資料一齊送走俾攻擊者 。

結果：攻擊者得到晒受害人掂得到嘅所有公共同私人 Repository 嘅完整讀寫權限，一切只係靠一個連結撳擊 。

微軟嘅回應

微軟喺 2026 年 6 月 2 號確認咗呢個漏洞，表明已經為佢哋嘅服務——即係 github.dev 同 VS Code for the Web——做咗緩解措施 。

6 月 3 號，微軟推出咗伺服器端修正，包括喺開瀏覽器版 Notebook 嗰陣加咗信任確認步驟，同埋攔截安裝 Extension 嘅指令接受任意呼叫者資訊 。去到 6 月 4 號，再部署咗額外嘅 Webview 事件處理限制 。

微軟話呢個問題唔影響 VS Code Desktop 。不過，背後呢種模式——對工作區 Extension 信任有餘但驗證不足——對任何會喺本機開唔信任 Repository 嘅 VS Code 用家嚟講，都係一個值得擔心嘅隱憂。

呢次有咩咁唔同

呢條 Exploit 鏈有三點值得留意。

第一，攻擊面係一個 URL。受害人唔使下載檔案、唔使開終端機、唔使批准任何權限。一個去 github.dev 嘅瀏覽器連結就係唯一嘅先決條件。

第二，Token 嘅權限範圍大到得人驚。github.com 傳俾 github.dev 嘅 OAuth Token 並唔係局限喺你睇緊嗰個 Repository。佢拎住你成個 GitHub 嘅權限，即係話攻擊者如果搞掂一個做緊公開開源項目嘅開發者，就可以同時攞到呢個開發者公司私人 Repository 嘅憑證 。

第三，工作區信任掉轉咗嚟用。令到本機開發好順暢嘅功能——信任跟住項目送嚟嘅 Extension——竟然變成咗俾惡意Payload自動執行嘅機制。

OpenClaw AI 代理：五個零日身份冒充漏洞

喺另一單平行披露入面，研究員公佈咗 OpenClaw AI 代理框架嘅五個零日漏洞，攻擊者可以利用呢啲漏洞冒充受信任名單上面嘅用戶，騎劫跨平台嘅 AI 代理權限 。

根本原因喺架構度：OpenClaw 支援 15 個唔同嘅頻道 Adapter——Telegram、Slack、Discord、WhatsApp 等等——而每個 Adapter 都獨立咁實現自己嗰套 Allowlist 授權同 Webhook 驗證機制 。用嚟做 Allowlist 判斷嘅安全關鍵身份欄位，例如可以俾人睇到嘅顯示名稱，喺平台層面係可以任改嘅，而且每個 Adapter 將呢啲欄位解析做穩定用戶 ID 嘅方式都唔一致 。

因為冇一個中央政策執行層，攻擊者可以：

• 喺一個頻道冒充受信任名單嘅用戶，就咁改個顯示名同授權身份一樣就得 。
• 利用唔同頻道 Extension 之間不一致嘅身份解析，繞過信任檢查——呢啲檢查喺某個頻道可能Work，但喺另一個頻道就Fail 。
• 騎劫 AI 代理嘅權限——呢啲權限通常包括 Shell 存取、API 金鑰同檔案系統權限——完全唔使任何有效憑證 。

一份 2026 年 6 月 3 號嘅 arXiv 安全分析指出，漏洞橫跨多個架構層面（執行政策、閘道、頻道、沙箱、瀏覽器、插件、提示），而最主要嘅結構模式係每層每個呼叫點都自己管自己嘅信任，而唔係統一嘅政策邊界 。分析發現，呢啲分散嘅架構弱點可以組合成完整嘅未經認證遠端程式碼執行路徑 。

新加坡網絡安全局（CSA）喺 2026 年 5 月底發出咗一份警示，提醒關於未修復嘅漏洞、薄弱嘅存取控制，同埋 ClawHub 市集上面惡意第三方技能嘅風險 。

---

給香港開發者嘅溫馨提示： 短期內喺瀏覽器掂任何 github.dev 連結之前都要打醒十二分精神。長遠嚟講，呢單嘢提醒緊我哋，就算係官方工具，只要設計上對工作區嘅信任過度寬鬆，都有機會俾人利用。AI 代理框架嘅安全設計更加唔可以靠每個頻道各自為政，一定要有中央化嘅身份驗證同政策執行。