开源插件市场的"沉睡炸弹"：73个恶意扩展正在苏醒

「开发者以为自己在装语言包，实际上在给攻击者留后门。」——这是Socket研究团队对最新供应链攻击的总结。

2026年4月，Open VSX插件市场被挖出73个"沉睡扩展"（sleeper extension）。它们像定时炸弹一样潜伏在开发者的工作流里，等待被激活的那一刻。这不是孤立事件：一个月前，同一攻击组织GlassWorm刚刚部署了72个恶意扩展。两波攻击，同一个目标——软件开发者。

什么是"沉睡扩展"？一场精心设计的信任骗局

攻击者的玩法很直白：先发布一个看起来完全正常的插件，等下载量涨起来、评分稳住了，再推送恶意更新。

具体操作上，他们会注册全新的GitHub账号，克隆热门工具。比如这次发现的假"Turkish Language Pack"（土耳其语语言包）：图标直接复制正版，描述一字不差，只改了一个发布者名字。开发者肉眼根本分不清。

这种"先养号、后收割"的模式，核心是利用了开源市场的信任机制。扩展市场依赖下载量和评分判断可靠性，攻击者用时间换空间，把自己刷成"看起来靠谱"的样子。

4月这波73个扩展里，至少6个已经被激活，开始向安装者投递恶意载荷。

攻击升级：从"代码里藏毒"到"远程拉取"

3月的攻击版本还比较直接：恶意代码写在扩展的依赖项里，利用VS Code的扩展机制静默安装加载器。安全扫描工具只要查依赖树，大概率能发现异常。

4月的新变种变了策略。扩展本身几乎是个空壳——它只负责一件事：去外部服务器拉取真正的恶意代码。

这意味着什么？静态代码分析基本失效。你下载扩展时，里面干干净净；运行之后，它才现场下载payload。传统的安全扫描工具很难在"安装阶段"就拦截。

GlassWorm的演进路径很清晰：第一波测试市场反应，第二波优化逃逸能力。这种迭代速度对安全团队是巨大压力。

两种执行路径：攻击者的技术选项

根据Socket研究团队的披露，这次攻击主要用了两种手法：

第一种，扩展作为"薄加载器"（thin loader）。安装后首次激活时，向硬编码的远程地址请求恶意代码，直接内存执行，不落盘。

第二种，利用VS Code的Webview API。扩展创建一个隐藏的Webview窗口，在里面运行JavaScript payload，绕过主进程的安全限制。

两种方法都指向同一个设计思路：把"恶意"和"扩展"解耦。扩展只是入口，真正的攻击逻辑在云端随时更新。这让溯源和封禁变得困难——你封了一个下载地址，攻击者换另一个就行。

开发者能做什么？三条实操建议

Socket团队给出的防御建议很具体，没有泛泛而谈：

第一，核对发布者命名空间（publisher namespace）。正版"Turkish Language Pack"的发布者是Microsoft，恶意版改成了看起来相似但不同的名字。安装前多花10秒点进发布者主页，看历史项目、GitHub关联、账号创建时间。

第二，看下载量曲线。沉睡扩展的典型特征是"突然冒出来的高评分"——下载量可能只有几百，但评分接近5星。正常的热门工具下载量通常是数万起步，评分分布也更真实。

第三，延迟更新策略。如果某个扩展已经安装，收到更新提示时可以先观望24-48小时。供应链攻击的激活往往集中在更新推送后的短时间内，社区通常能快速反馈异常。

为什么这件事值得警惕？

2026年3月：72个恶意扩展被发现。
2026年4月：73个新扩展，手法升级。
两次攻击间隔不到30天。

这不是随机黑客的业余尝试，而是有组织、有节奏的资源投入。Open VSX作为VS Code的开源替代插件市场，安全审核机制比官方市场更宽松，正在成为攻击者的重点目标。

更深层的问题是：现代开发工作流建立在"信任链"之上——你信任IDE，IDE信任扩展市场，扩展市场信任发布者。GlassWorm的攻击精准打击了这个链条里最薄弱的环节：发布者身份验证。

145个恶意扩展，两波攻击，同一个目标人群。当开发工具本身成为攻击向量，防御的边界就被彻底重新定义了。