VS Code零日漏洞遭直接公开：点击链接窃取令牌，所有GitHub仓库全沦陷

最近一起安全事件让开发者圈炸了锅：知名代码编辑器 Visual Studio Code（VS Code）及其在线版本 github.dev 被曝存在一个严重的 零日漏洞。攻击者只需引诱你点击一个链接，就能悄无声息地窃取你的 GitHub 令牌，从而读取、写入你名下所有仓库——包括那些被严加保护的私有仓库。

更令人意外的是，发现该漏洞的安全研究员 Ammar Askar 在向 GitHub 相关团队通报后仅仅一小时，就毫无保留地在互联网上公开了完整的利用代码。没有等待 90 天，没有走任何负责任披露流程，甚至连微软官方安全响应中心（MSRC）的工单都没建。他给出的理由很简单：上一次和 MSRC 打交道的经历，让他彻底寒了心。

致命弱点：一个链接就能“抄家”

漏洞核心藏在 GitHub 提供的浏览器版编辑器 github.dev 中。当你从 GitHub 仓库页面点击“.”或手动将网址中的 github.com 换成 github.dev 时，系统会启动一个轻量级、完全跑在浏览器里的 VS Code 实例。

为了能让你在线查看代码、提交 PR、甚至直接提交 Commit，GitHub 会通过一个 OAuth 令牌将权限下放给 github.dev。问题在于：这个令牌的作用域远超你的预期——它不是仅限于当前打开的那个仓库，而是拥有你账号下所有可访问仓库的完整读写权限（公开库、私有库一个不漏）。

于是，攻击思路就变得异常清晰：

1. 攻击者找一个你能访问的仓库（甚至可以是公开仓库），悄悄修改其中的 .vscode/extensions.json 文件，推荐一个恶意 VS Code 扩展。
2. 给你发送一个链接，例如 https://github.dev/某仓库。
3. 你在浏览器中点击并打开该链接，系统自动拉起 github.dev 并尝试加载推荐的扩展。

接下来是这波攻击最“精妙”的部分：如何绕过 VS Code 的扩展安装确认弹窗？

研究人员发现，攻击者可以在仓库中植入一个精心构造的 Jupyter Notebook 文件（.ipynb）。当你在 github.dev 中打开该文件时，其中隐藏的恶意 HTML 代码会悄悄在后台自动触发键盘快捷键——直接“按下”确认安装按钮。整个过程用户完全无感知，恶意扩展就被顺利装上。

一旦恶意扩展入驻，它就能读取当前会话中的 OAuth 令牌，并将其发回给攻击者。从那一刻起，你的 GitHub 账号就彻底暴露了。

点一下链接，你的代码仓库就可能沦为别人的后花园。

信任崩盘：为什么研究员选择“裸奔式”公开？

按理说，这种级别的漏洞应当通过正规途径提交给微软，等待修复后再低调公布。但 Ammar Askar 显然不打算再给 MSRC 任何“体面”的机会。

他在公开报告中直接表示：“总结一下我上一次向 MSRC 报告 VS Code 漏洞的体验——简直糟糕透顶。他们悄悄修复了我指出的问题，却连一个致谢名单都没给我。而且还标记为没有安全影响。” 那次经历让他下定决心：以后在 VS Code 中发现的任何安全漏洞，都会直接全量公开，不再走任何协调流程。

同时他还引用了一份近期由 Starlabs 团队提交的 XSS 漏洞报告，微软安全响应中心同样以“低严重性”、“不符合要求”为由冷处理。Askar 感叹：“看起来 MSRC 在处理 VS Code 相关漏洞方面并没有任何进步。”

有意思的是，他特意强调自己并不怪 VS Code 的开发团队。他理解工程师们需要在用户体验与安全之间做出艰难权衡。他的怒火只对准微软的安全响应流程，并认为彻底公开是目前唯一能“撬动”这个流程的杠杆。

“我肯定 VS Code 团队希望能有更多时间找到平衡点。对团队成员，我表示歉意，但这已经是少数能影响 MSRC 和改进安全态势的手段之一了。” —— Ammar Askar

⚔️ 这不是孤例：另一个“破窗者”Chaotic Eclipse

类似的故事并不罕见。安全研究员 Chaotic Eclipse 曾连续发布 6 个 Windows 零日漏洞，包括 MiniPlasma、BlueHammer、RedSun、UnDefend、YellowKey 和 GreenPlasma，全都是在微软不知情或未修复的情况下直接公开，其中三个已被确认在野外被利用过。

微软在第六次被公开后，一度搬出“数字犯罪部门”威胁采取法律行动，却在遭遇全网声讨后悄悄收回了强硬表态。拿律师函吓唬安全研究员，从来不是建立信任的方式。

这种模式正在从孤例变成一种趋势：当研究团队花费大量时间精力挖出漏洞、做成可用的 PoC（概念验证代码），而厂商却悄悄打补丁、不给学分、甚至不屑一顾时，继续配合披露的意愿自然会消失殆尽。用 Askar 的原话说：“安全研究员的努力不应被轻视，更不应该被视为理所当然。”

微软需要修补的不是代码，而是信任

截至目前，微软尚未对此漏洞发布官方补丁或临时缓解措施。在微软推出有效修复方案之前，普通开发者和企业团队应提高警惕：请勿轻易点击来历不明的 github.dev 链接，也尽量不要在不受信任的仓库中打开在线版 VS Code。

毕竟，你可能不会想到——一次简单的点击，就可能把全部私密代码拱手让人。

资讯来源：综合自 Ammar Askar 公开披露报告、Starlabs 安全分析及 BleepingComputer、SecurityWeek 等相关报道