天塌了！Cursor和Windsurf用户零日漏洞曝光，一键劫持，数百万开发者开源插件噩梦，网友：零信任太重要了

背后真相：插件权限和“信任危机”

究竟怎么回事？

如今基于AI的编辑器严重依赖扩展程序来实现最基本的功能。语法高亮、代码检查和调试等功能并非硬编码到编辑器中，而是由扩展程序来提供。

这些扩展程序每个都以完全权限在开发者的机器上运行。这意味着，只要有一个扩展程序被攻陷，就可能导致安装它的任何人全面控制机器。 

图片

Oren Yomtov是Koi Security这家提供软件配置和扩展程序安全平台的公司的安全研究员，他无意中发现了这噩梦般的场景。

Koi Security 的安全研究员 Oren Yomtov 在研究 OpenVSX 的构建流程时，发现了这处致命缺陷。

在一篇博文中，Yomtov解释道，OpenVSX 是一个开源插件市场，支撑着 Cursor、Windsurf、VSCodium 等编辑器的插件生态。

该漏洞不仅允许攻击者接管单个扩展程序，更可能引发一场 供应链灾难：掌控整个市场。通过该漏洞，攻击者可冒用受信任的 @open-vsx 账户推送恶意更新。

一开始，Yomtov 以为是误报——毕竟这段代码已经运行多年，被数千万用户使用。但他在实验室中成功复现了整个攻击流程：模拟攻击完美执行，这场“不可想象”的安全事故就这样被证实。

看似不可想象的突然变成了现实：一场悄无声息的全面的安全灾难近在眼前。

漏洞：经典“Pwn 请求”的变体

要了解该漏洞的工作原理，首先需要了解扩展程序是如何进入OpenVSX的。

如果你想将扩展程序发布到OpenVSX，有两个选择：

1. 自行上传到OpenVSX。

2. 通过创建合并请求，将该扩展程序添加到extensions.json文件中的列表，请求扩展程序自动发布。 

图片

Yomtov说：“问题就出在夜间构建上。”

OpenVSX 每晚都会运行一个自动化流程，获取社区提交的扩展程序的最新版本，构建它们，然后发布到OpenVSX市场。本意是为了让开发者的工作更轻松，但在这里它却引入了一个严重缺陷。

要自动发布扩展程序，开发者只需提交一个简单的合并请求，将其添加到公开列表中即可。此后，OpenVSX接手任务：提取代码、安装依赖项、构建扩展程序，并使用属于受信任的@open-vsx帐户的强大秘密令牌来发布。

图片

该令牌本应保持隐藏状态，只有受信任的基础架构才能看到。然而，由于构建过程会运行来自公共代码库的任意代码，任何扩展程序的开发者都可以编写恶意更新，悄无声息地获取令牌。

更令人担忧的是，他们无需直接提交恶意扩展程序。他们可以将代码隐藏在依赖项中，甚至隐藏在依赖项的依赖项中，系统会在夜间构建期间自动执行这些代码。之后，窃取令牌就轻而易举。

有了该令牌，攻击者不仅可以控制自己的扩展程序，还可以发布更新、覆盖现有的扩展程序，并悄无声息地劫持整个市场。

影响规模：数百万开发者的一场供应链噩梦

若能访问@open-vsx帐户的令牌（密钥），攻击者就可以制造一场全球供应链噩梦。Yomtov解释道：“该令牌是超级管理员凭证。它可以发布新的扩展程序，覆盖现有的扩展程序，并冒充生态系统中的任何发布者。”

之后，破坏几乎变得毫不费力。每当开发者安装扩展程序，或者编辑器在后台自动更新扩展（这种情况不断发生），攻击者的有效载荷就会悄无声息地传递到他们的机器上。没有警报，没有提示，毫无怀疑，全面接管。

那么，这个有效载荷能做什么呢？“几乎无所不能，”Yomtov说。VS Code及其分支中的扩展程序以Node.js进程的形式运行，这意味着它们可以访问文件、启动其他程序、发出网络请求并执行任意代码。

对流行扩展程序（比如Python 插件）进行恶意更新，可能会悄然安装键盘记录程序、窃取浏览器 cookie、窃取源代码、感染构建版本，或在整条开发管道中植入后门。

这方面曾有零星的案例：VS Code扩展程序窃取SSH密钥或加密钱包。但这绝不是漏网之鱼，而是一场全面的接管，整个生态系统遭到供应链攻击。就像SolarWinds那样，只不过针对的是开发者工具。

虽然Cursor、Windsurf和VSCodium等桌面编辑器受到的影响最为严重，但就连Gitpod或StackBlitz等基于浏览器的环境也可能受到影响，这取决于受感染扩展程序的集成程度。

零信任警醒：假设每个扩展程序是不可信的

我们询问Yomtov用户和组织应该从这起事件中吸取什么教训。他的回答很直接：“假设每个扩展程序都是不可信的，除非证明是可信赖的。”

扩展程序可能看起来像是无害的附加组件，但实际上，它们是功能强大的软件组件，通常由个人编写，以全面权限运行，会在无人监督的情况下自动更新。

Yomtov说：“这与从npm或PyPI中拉取软件包没什么不同，通常甚至更糟糕。如果你不会盲目信任拥有root 权限访问你系统的GitHub 代码库，也不会信任扩展程序。”

为了保护我们自己，Yomtov建议组织将扩展程序视为其攻击面的一部分，运用与针对任何其他依赖项相同的规程。这意味着：

1. 维护一份真实的清单，记录已安装的扩展程序、安装在哪些机器上以及由谁安装。

2. 根据扩展程序的构建者、维护方式以及实际功能来评估风险。

3. 对允许的扩展程序执行明确的策略，并在出现异常情况时采取行动。

4. 持续监控，因为扩展程序可能会悄无声息地更新，并在一夜之间引入新的风险。

Koi的研究团队继续发现易受攻击的扩展程序和主动恶意的扩展程序，不仅出现在 OpenVSX或微软的市场中，甚至出现在其他扩展程序市场（比如Chrome Web Store）中。

Yomtov说：“生态系统的发展速度比护栏更快。在这种情况改变之前，最安全的假设是零信任。除非你仔细审查并密切关注，否则每个扩展程序都是潜在的后门。”

还好，漏洞已修复

Yomtov和Koi Security团队很负责任，向维护OpenVSX项目的Eclipse基金会披露了该漏洞。在随后的几周，他们与维护人员密切合作，验证该问题，设计可靠的修复方案，并确保补丁得到正确实施和部署。

目前，得益于此次合作，该漏洞已被修复，对于每天依赖该市场的数百万开发者来说，已经恢复安全，也是是一件幸事。

但这起事件也敲响了警钟：零信任，即便是看起来可信赖的基础架构也需要持续审查，如果它掌握着整个开发生态系统的密钥，更应如此。