OpenVSX 生态近日曝出一起面向开发者的供应链安全事件。安全研究人员指出，已知恶意软件 GlassWorm 向 OpenVSX 注册表投放了 73个有害扩展，其主要目标是窃取开发者的加密钱包数据、访问令牌、SSH 密钥以及开发环境相关信息。更值得警惕的是，其中6个扩展已经转变为活跃恶意载荷，意味着攻击者并非只是“埋点”，而是已开始执行实质性窃密行动。
攻击伪装性极强：先发布“干净版本”，再推送恶意更新
根据 Socket 的报告，这批恶意扩展并非一开始就嵌入明显恶意代码，而是采用了一种更具隐蔽性的延迟激活模式。攻击者先上传看似正常、甚至几乎与知名扩展完全一致的“克隆版”插件，在建立一定安装量和信任度后，再通过后续更新下发恶意代码。
这种模式明显提高了检测难度。研究人员表示，这些扩展通常会冒充真实条目，名称、描述甚至图标都高度相似，普通开发者在安装时如果不仔细核对发布者名称和唯一标识符，很容易误装。对依赖插件提升开发效率的 Web3 与基础设施开发者而言，这类攻击尤其危险，因为他们的本地环境往往保存着钱包、私钥管理工具配置、云凭证及代码仓库访问权限。
GlassWorm攻击范围持续扩大
报道显示，GlassWorm 最早于 2025年10月 被发现，初期通过不可见 Unicode 字符隐藏恶意代码，以窃取加密钱包数据和开发者凭据。此后，该攻击活动已从单一投放渠道扩展至 npm 包、GitHub 仓库、Visual Studio Code Marketplace 以及 OpenVSX 等多个开发者常用平台。
到了 2026年3月中旬，这场攻击出现了一轮更大规模扩散，波及数百个仓库和数十个扩展，因规模异常而引起多个研究团队关注，并在早期阶段协助拦截部分活动。如今 OpenVSX 事件再次表明，攻击者正在不断优化战术，从粗放式恶意投放，转向更像正规软件维护流程的“潜伏—更新—激活”路径。
三种恶意投递方式暴露供应链风险
研究人员在这 73个扩展 中发现了三种主要恶意代码投递方法。第一种是在程序运行时从 GitHub 获取第二个 VSIX 包，并通过命令行方式完成安装；第二种是加载针对不同平台编译的模块，例如 .node 文件，这些模块包含核心恶意逻辑，并可继续拉取更多载荷；第三种则是使用高度混淆的 JavaScript，在运行时解码后下载并安装恶意扩展，同时配合加密或备用 URL 提高存活率。
从攻击设计来看，GlassWorm 并不局限于窃取单一钱包文件，而是试图尽可能全面地获取开发者工作站的高价值资产，包括访问令牌、SSH 密钥、开发环境信息以及与加密资产相关的数据。这意味着，一旦受害者是参与托管、DeFi 协议、代币发行平台或链上基础设施的团队成员，后果可能外溢至项目代码库、CI/CD 流程甚至资金控制层。
并非孤立事件：注册表与开发工具链持续承压
这起 OpenVSX 事件并非孤例。报道提到，4月22日，npm 注册表曾在 93分钟 内托管一个恶意版本的 Bitwarden CLI，包名为官方名称下的 @bitwarden/cli@2026.4.0。安全公司 JFrog 发现，该恶意载荷可窃取 GitHub 令牌、npm 令牌、SSH 密钥、AWS 与 Azure 凭证，以及 GitHub Actions 密钥等敏感信息。
JFrog 分析指出，这个被劫持的软件包篡改了安装钩子与二进制入口点，在安装阶段和运行阶段都会加载 Bun 运行时并执行混淆载荷。Bitwarden 方面记录显示，其拥有超过50,000家企业客户和1,000万用户。Socket 认为，这起事件与更大规模的攻击活动相关，且已获 Bitwarden 确认关联。
这些案例共同反映出一个关键问题：攻击者正在系统性利用软件注册表从“发布”到“审查”之间的时间差。只要恶意内容能在短时间内上线，就有机会借助自动化安装、依赖更新和开发者信任机制迅速扩散。
对加密行业的市场影响
从市场角度看，此类安全事件对加密行业的影响并不只体现在单个钱包失窃。首先，攻击目标已明显从普通用户转向开发者、基础设施提供商和代码供应链，这意味着风险更接近行业核心资产。开发者一旦中招，可能连带影响协议升级、热钱包管理、私有仓库、运维权限甚至项目发布流程。
其次，事件可能加剧市场对 Web3 基础设施安全性的担忧。对于依赖开源工具链构建产品的项目方、交易平台和托管服务商来说，插件市场、包管理器与代码仓库不再只是效率工具，也正在成为攻击者获取资金入口的前沿阵地。这类事件短期内通常会推动行业加强审计、凭证轮换和终端隔离，长期则可能促使更多机构重新评估开发环境中的密钥管理方式。
值得注意的是，Sonatype 发现，2025年约有454,600个新的恶意软件包进入各类注册表。随着攻击者开始瞄准加密托管、DeFi 和代币发行平台，供应链安全已成为影响市场信心与机构采用的重要变量。
开发者当前应如何应对
对于安装过这 73个被标记 OpenVSX 扩展 的开发者，Socket 建议立即执行所有密钥与凭证轮换，并彻底清理开发环境。由于还有 67个扩展处于休眠状态，后续是否会被统一激活，成为市场和安全社区接下来关注的重点。同时，OpenVSX 是否会针对扩展更新引入更严格的审查控制，也将影响类似事件的再发生概率。
总体来看，GlassWorm 事件再次提醒加密行业：真正高价值的攻击面，正在从链上应用界面转向链下开发基础设施。对于持有大量权限、掌握关键部署流程的开发者而言，插件和依赖管理的每一次点击，都可能成为安全防线中最脆弱的一环。