GitHub 浏览器版 VSCode 编辑器现严重漏洞安全研究人员短通知披露引伦理争议此次漏洞披露引发了关于安全研究人员对供应商的期望以及他们应在漏洞公布前多久通知供应商的疑问。一名研究人员表示GitHub 基于浏览器的 VSCode 编辑器存在一个漏洞在某些情况下可能导致开发者令牌被盗。本周Ammar Askar 在博客中披露了这一问题显然 GitHub 的所有者微软已经解决了该问题。但这也引发了关于 DevOps 安全的疑问以及研究人员的指控即由于微软不重视漏洞发现他认为在公开披露所发现的漏洞前只需给微软短时间通知是合理的。首先是这个漏洞github.com 的用户可能没有意识到当他们访问任何仓库时只需更改 URL 就可以切换到 github.dev 及其基于浏览器的 VSCode 版本。Askar 在博客中表示因为浏览器版的 VSCode 功能相当强大。“你可以查看仓库中的所有文件即使是私有仓库可以发送拉取请求甚至可以进行提交。”Enderle Group 的负责人、IT 顾问 Rob Enderle 也认同以这种方式进入 VSCode 是“执行快速任务的极其有用的战术工具”。在任何 GitHub 仓库中只需按下“.”键你就能立即获得一个基于浏览器的 VS Code 界面而无需在本地克隆数 GB 的数据。这非常适合快速进行 PR 审查、快速编辑文档或者在不中断工作流程的情况下即时浏览代码。不过要记住它完全在浏览器沙盒中运行没有计算后端、没有终端也无法执行代码。他补充说对于任何繁重的任务或实际编译开发者仍然需要本地工作站的原始计算能力或者像 Codespaces 这样的完整云环境。Askar 指出问题在于 github.com 通过 POST 方式将 OAuth 令牌发送到 github.dev从而实现了这一功能该令牌允许它代表你与 GitHub 进行交互。“该令牌的作用范围并不局限于你所交互的特定仓库这意味着它可以完全访问你有权限访问的其他所有仓库。”他在博客中写道“这个令牌的存在以及这个 Web 应用几乎运行着 VSCode 百万行 TypeScript 代码库的事实使其成为任何研究 VSCode 漏洞的人的绝佳目标。”Askar 称威胁行为者可以使用 Jupyter notebook一种用于创建和共享计算文档的 Web 应用程序在仓库中安装扩展该应用程序能够在跳过发布者信任检查的情况下安装恶意本地工作区扩展。在他的概念验证中Askar 表示一旦他的有效负载运行新安装的扩展将获取 GitHub API 令牌运行查询以获取开发者有权限访问的私有仓库然后打印出回复和令牌。Askar 表示VSCode 的桌面版本也存在此漏洞不过更难利用因为威胁行为者需要说服受害者克隆他们的仓库并打开包含 Webview 脚本有效负载的笔记本。“当然”他补充道“如果你黑客在 Webview 中有其他跨站脚本攻击XSS并且能让受害者打开你实际上就可以在他们的计算机上实现远程代码执行RCE。”他在一封电子邮件中表示这个漏洞“极其严重。互联网上的任何网站都可能将你重定向到一个 github.dev 链接这可能会为攻击者提供一个令牌使其能够读取和修改你的代码仓库。如果有人能说服一个流行软件项目的维护者点击一个链接他们就可以对该项目进行任何修改。”Enderle 表示这意味着“我们必须开始以严格、隔离的零信任参数来对待开发者端点因为显然我们不能依赖供应商的自满来保护我们”。GitGuardian 的首席开发者倡导者 Dwayne McDaniel 补充说这个问题再次提醒我们除非你确切知道链接会带你去哪里否则永远不要点击任何链接。短时间通知事情变得复杂起来。由于之前向微软披露 VSCode 漏洞时经历不愉快漏洞已修复但 Askar 未得到认可这次他只提前一小时通知 GitHub 他将公布这一新发现。微软采取了 Askar 所说的“权宜之计”修复措施即在开发者在 Web VSCode 中打开笔记本时添加确认提示并禁止通过命令跳过可信发布者要求。伦理问题Askar 的短时间通知引发了一个伦理问题负责任的研究人员在公开披露漏洞之前应该提前多久通知供应商如今大多数信息安全专家都认为必须提前通知否则威胁行为者可能会迅速利用漏洞。不仅如此如果不给予合理的通知研究人员还可能损害自己的声誉。有经验的研究人员通常会给供应商至少 30 天的时间来创建和分发补丁。就供应商而言他们通常会创建漏洞赏金计划或与漏洞赏金计划合作以奖励研究人员的工作。不幸的是一些供应商并不总是认可研究人员的工作或者低估漏洞可能造成的损害。事实上上个月微软就与一位知名的网络安全研究人员就一起此类事件公开争吵。权力失衡当被问及对 Askar 最新发现的看法时微软发言人表示“我们重视安全研究社区在加强我们的产品、服务和更广泛的技术生态系统安全方面所发挥的关键作用。虽然独立研究人员自行决定何时以及如何公布他们的发现但我们仍致力于迅速评估报告的问题调动适当的工程和安全响应资源并尽快提供缓解措施、指导和保护以帮助保护我们的客户。”Askar 告诉我们在与软件供应商协调披露CVD和完全披露之间需要找到平衡。但他补充说存在权力失衡的问题。“安全研究人员可能会在一个问题上投入无数小时确保开发出良好的概念验证并提供重现问题的所有步骤。他们希望至少能得到对自己努力的认可这可以用于提升他们的安全记录或者在最好的情况下获得金钱赏金奖励。”然而他补充道“如果安全供应商不遵守他们的承诺公开披露是安全研究人员为数不多的选择之一如果他们不想搁置自己发现的漏洞或在黑市上出售它们。这会迫使供应商公开承认安全问题通常比任何私下沟通都能更快地解决问题。”Enderle 表示这给企业带来了问题“当供应商的官僚作风惩罚负责任的披露时会疏远安全社区并导致零日漏洞公开披露最终让企业客户承担后果。”相关标签GitHub、版本控制系统、软件开发、漏洞、安全、端点保护
GitHub 浏览器版 VSCode 现漏洞，研究人员短通知披露引发安全伦理争议
发布时间：2026/6/5 1:34:01
GitHub 浏览器版 VSCode 编辑器现严重漏洞安全研究人员短通知披露引伦理争议此次漏洞披露引发了关于安全研究人员对供应商的期望以及他们应在漏洞公布前多久通知供应商的疑问。一名研究人员表示GitHub 基于浏览器的 VSCode 编辑器存在一个漏洞在某些情况下可能导致开发者令牌被盗。本周Ammar Askar 在博客中披露了这一问题显然 GitHub 的所有者微软已经解决了该问题。但这也引发了关于 DevOps 安全的疑问以及研究人员的指控即由于微软不重视漏洞发现他认为在公开披露所发现的漏洞前只需给微软短时间通知是合理的。首先是这个漏洞github.com 的用户可能没有意识到当他们访问任何仓库时只需更改 URL 就可以切换到 github.dev 及其基于浏览器的 VSCode 版本。Askar 在博客中表示因为浏览器版的 VSCode 功能相当强大。“你可以查看仓库中的所有文件即使是私有仓库可以发送拉取请求甚至可以进行提交。”Enderle Group 的负责人、IT 顾问 Rob Enderle 也认同以这种方式进入 VSCode 是“执行快速任务的极其有用的战术工具”。在任何 GitHub 仓库中只需按下“.”键你就能立即获得一个基于浏览器的 VS Code 界面而无需在本地克隆数 GB 的数据。这非常适合快速进行 PR 审查、快速编辑文档或者在不中断工作流程的情况下即时浏览代码。不过要记住它完全在浏览器沙盒中运行没有计算后端、没有终端也无法执行代码。他补充说对于任何繁重的任务或实际编译开发者仍然需要本地工作站的原始计算能力或者像 Codespaces 这样的完整云环境。Askar 指出问题在于 github.com 通过 POST 方式将 OAuth 令牌发送到 github.dev从而实现了这一功能该令牌允许它代表你与 GitHub 进行交互。“该令牌的作用范围并不局限于你所交互的特定仓库这意味着它可以完全访问你有权限访问的其他所有仓库。”他在博客中写道“这个令牌的存在以及这个 Web 应用几乎运行着 VSCode 百万行 TypeScript 代码库的事实使其成为任何研究 VSCode 漏洞的人的绝佳目标。”Askar 称威胁行为者可以使用 Jupyter notebook一种用于创建和共享计算文档的 Web 应用程序在仓库中安装扩展该应用程序能够在跳过发布者信任检查的情况下安装恶意本地工作区扩展。在他的概念验证中Askar 表示一旦他的有效负载运行新安装的扩展将获取 GitHub API 令牌运行查询以获取开发者有权限访问的私有仓库然后打印出回复和令牌。Askar 表示VSCode 的桌面版本也存在此漏洞不过更难利用因为威胁行为者需要说服受害者克隆他们的仓库并打开包含 Webview 脚本有效负载的笔记本。“当然”他补充道“如果你黑客在 Webview 中有其他跨站脚本攻击XSS并且能让受害者打开你实际上就可以在他们的计算机上实现远程代码执行RCE。”他在一封电子邮件中表示这个漏洞“极其严重。互联网上的任何网站都可能将你重定向到一个 github.dev 链接这可能会为攻击者提供一个令牌使其能够读取和修改你的代码仓库。如果有人能说服一个流行软件项目的维护者点击一个链接他们就可以对该项目进行任何修改。”Enderle 表示这意味着“我们必须开始以严格、隔离的零信任参数来对待开发者端点因为显然我们不能依赖供应商的自满来保护我们”。GitGuardian 的首席开发者倡导者 Dwayne McDaniel 补充说这个问题再次提醒我们除非你确切知道链接会带你去哪里否则永远不要点击任何链接。短时间通知事情变得复杂起来。由于之前向微软披露 VSCode 漏洞时经历不愉快漏洞已修复但 Askar 未得到认可这次他只提前一小时通知 GitHub 他将公布这一新发现。微软采取了 Askar 所说的“权宜之计”修复措施即在开发者在 Web VSCode 中打开笔记本时添加确认提示并禁止通过命令跳过可信发布者要求。伦理问题Askar 的短时间通知引发了一个伦理问题负责任的研究人员在公开披露漏洞之前应该提前多久通知供应商如今大多数信息安全专家都认为必须提前通知否则威胁行为者可能会迅速利用漏洞。不仅如此如果不给予合理的通知研究人员还可能损害自己的声誉。有经验的研究人员通常会给供应商至少 30 天的时间来创建和分发补丁。就供应商而言他们通常会创建漏洞赏金计划或与漏洞赏金计划合作以奖励研究人员的工作。不幸的是一些供应商并不总是认可研究人员的工作或者低估漏洞可能造成的损害。事实上上个月微软就与一位知名的网络安全研究人员就一起此类事件公开争吵。权力失衡当被问及对 Askar 最新发现的看法时微软发言人表示“我们重视安全研究社区在加强我们的产品、服务和更广泛的技术生态系统安全方面所发挥的关键作用。虽然独立研究人员自行决定何时以及如何公布他们的发现但我们仍致力于迅速评估报告的问题调动适当的工程和安全响应资源并尽快提供缓解措施、指导和保护以帮助保护我们的客户。”Askar 告诉我们在与软件供应商协调披露CVD和完全披露之间需要找到平衡。但他补充说存在权力失衡的问题。“安全研究人员可能会在一个问题上投入无数小时确保开发出良好的概念验证并提供重现问题的所有步骤。他们希望至少能得到对自己努力的认可这可以用于提升他们的安全记录或者在最好的情况下获得金钱赏金奖励。”然而他补充道“如果安全供应商不遵守他们的承诺公开披露是安全研究人员为数不多的选择之一如果他们不想搁置自己发现的漏洞或在黑市上出售它们。这会迫使供应商公开承认安全问题通常比任何私下沟通都能更快地解决问题。”Enderle 表示这给企业带来了问题“当供应商的官僚作风惩罚负责任的披露时会疏远安全社区并导致零日漏洞公开披露最终让企业客户承担后果。”相关标签GitHub、版本控制系统、软件开发、漏洞、安全、端点保护
