Bloom Security 揭示“扩展复活”漏洞,影响 VS Code Marketplace 超 50 万次下载
Bloom Security 披露“Extension Resurrection”漏洞,攻击者可利用扩展包中的“影子依赖”发布恶意扩展,影响超 50 万次下载。Open VSX 和微软已分别于 2026 年 2 月和 6 月完成修复。

奥斯汀,得克萨斯州 — 开发者环境日益依赖扩展、插件和自动化工具,这为供应链攻击创造了新的机会,而此类攻击并不一定涉及软件发布商被入侵。Bloom Security 发现了一个影响微软 Visual Studio Code Marketplace 和 Eclipse 基金会 Open VSX 市场的扩展包弱点。
该公司将这一技术称为“Extension Resurrection”(扩展复活)。其研究发现,攻击者可能声称拥有合法扩展包所引用的不存在扩展的命名空间,在这些身份下发布恶意代码,并让该扩展随受信任的捆绑包自动安装。
Bloom 在两个市场上识别出超过 750 个受影响的扩展包,合计下载量超过 500,000 次。Open VSX 和微软在收到 Bloom 的披露后均确认并修补了该漏洞。
信任问题
扩展包旨在简化开发环境的配置。开发者无需逐个安装工具,而是可以安装包含多个扩展的包,用于格式化、调试和测试等任务。
安全问题的根源在于,开发者实际上信任了整个捆绑包。Bloom 发现,某些扩展包包含对相关市场上不存在扩展的引用。该公司将这些引用称为“影子依赖”(Shadow Dependencies)。
这种情况可能发生在扩展包在不同市场之间镜像,但其中一个捆绑扩展未被镜像时,或者当现有扩展包引用的扩展被删除时。即使扩展本身不存在,扩展包仍保留该引用。
Bloom 调查了攻击者是否能够填补这些空白。
认领缺失的扩展
研究人员扫描了两个市场的扩展包。在 Open VSX 上,321 个扩展包中有 94 个包含至少一个影子依赖。在 VS Code Marketplace 上,4,179 个扩展包中有 677 个包含至少一个。
Bloom 还发现,受影响的 VS Code Marketplace 扩展包中,有 60 个引用了与未注册发布者关联的影子依赖。
研究人员随后测试了能否重新创建缺失的扩展。一个 Open VSX 测试涉及 mohsen1 命名空间下的 prettify-json。市场最初拒绝了该尝试,因为其内部索引保留了对该扩展的引用,尽管该扩展从未发布过。
Bloom 发现,增加版本号可以允许发布该扩展。由于扩展包通过 ID 引用捆绑扩展,而不固定到特定版本,新发布的扩展可以满足依赖关系。
这意味着,安装原始受信任扩展包的开发者可能会收到新发布的扩展,而无需单独选择它。
自动更新提高了风险
问题不一定止于新安装。Bloom 发现,几周、几个月甚至几年前安装受影响扩展包的开发者,可能通过更新收到恶意扩展。
扩展包不会将其捆绑扩展固定到特定版本。它们的自动更新配置由包内扩展继承,且默认启用自动更新。
Bloom 表示,受影响扩展包的合计下载量超过 500,000 次。该公司还指出了在 VS Code 及兼容 IDE(如 Cursor、Kiro、Windsurf、Antigravity、VSCodium 和 Eclipse Theia)中运行的扩展可用的权限。
这些扩展以 Node.js 主机访问权限运行,可以读写文件、生成子进程并发出出站网络请求。因此,Bloom 将恶意扩展安装描述为在功能上等同于在开发者机器上执行远程代码。
弥补缺口
Bloom 确定了此攻击背后的两个弱点:市场未能充分验证捆绑扩展和声明的依赖确实存在,以及现有软件引用的命名空间可能仍可注册。
该公司于 2026 年 2 月 5 日向 Open VSX 披露了该问题。Eclipse 基金会通过将风险命名空间分配给 open-vsx 账户,并实施检查以防止扩展包引用不存在的扩展和依赖来回应。
Bloom 于 2 月 17 日向微软报告了该问题。微软最初将其评估为“中等”严重性,在提供额外证据后重新打开了案例。微软后来确认,针对扩展复活的保护措施已分阶段引入,覆盖管理员操作(2025 年 10 月)和用户操作(2026 年 6 月)。
对于组织而言,Bloom 的研究强化了将开发者工具视为企业攻击面一部分的必要性。安全团队应保持对已安装扩展和扩展包的可见性,审查其配置和自动更新设置,并持续评估开发者环境中运行的软件的能力和风险。
核心教训很直接:信任一个扩展包也意味着信任它以后可能安装的所有内容。在依赖关系可以自动更改的环境中,一次性的安装决策可能不会保持为一次性决策。
