4 月 22 日，npm 平台上出现了一个名为@bitwarden/cli@2026.4.0的恶意版本，该包在长达 93 分钟的时间内伪装成 Bitwarden 官方命令行工具进行分发。任何在此期间通过 npm 下载该工具的用户，实际上接收到的均是一个植入后门的非法替代品。Bitwarden 在发现漏洞后迅速移除了相关包并发布声明，确认目前尚无证据表明攻击者获取了最终用户的加密数据或破坏了生产系统，但此次事件暴露了软件供应链中极为隐蔽的风险点。

Bitwarden 作为服务于超过 50,000 家企业及 1,000 万用户的安全巨头，其官方文档将该命令行界面描述为“功能强大、使用便捷”的基础设施管理工具，广泛用于自动化工作流程中的身份验证。午方 AI 了解到，正是由于开发者习惯通过 npm 这一官方渠道进行自动化安装，使得该工具恰好处于包含高价值基础设施敏感信息的系统核心位置。攻击者利用这一信任机制，运行被篡改的命令行界面，在不触碰已存储密码的前提下，系统性地收集用于控制持续集成管道、云账户及部署自动化流程的凭证信息。

Bitwarden 确认此次事件与 Checkmarx 发起的供应链攻击活动有关，这揭示了即便在 npm 引入基于 OIDC 的认证机制取代传统发布令牌后，发布逻辑本身仍存在安全隐患。虽然 npm 通过可靠发布机制阻断了劫持注册系统的常见途径，但触发发布操作的工作流程和相应动作却可能成为新的突破口。GitHub 的环境设置虽允许组织要求审核人员签字确认，SLSA 框架也要求验证凭证来源是否与预期参数相符，但许多组织尚未对这些执行环节进行充分审查。

JFrog 的分析指出，一旦恶意软件获取 GitHub 令牌，攻击链将自动展开：验证令牌有效性、列出可写仓库目录、获取 GitHub Actions 中的敏感信息、创建新分支并提交代码，待执行完毕后下载结果文件并清除痕迹。午方 AI 监测到，若开发者的笔记本电脑安装了被篡改的官方包，该设备便成为从本地凭证存储库到 GitHub 访问权限的桥梁，攻击者可借此访问 GitHub 上的任何资源。在加密货币、金融科技或托管服务领域，这种攻击路径甚至能直接延伸至发布签名器、云访问权限及部署系统，完全无需触及加密数据本身。

尽管 Bitwarden 已确认事件与 Checkmarx 攻击活动相关，但攻击者如何获取发布流程访问权限的具体根源尚未公开。对于防御者而言，此次事件的核心启示在于重新定义“官方”这一概念的内涵。可靠的发布机制虽会为每个包附加来源验证信息，但 SLSA 框架规定的更高标准——即验证凭证是否来自正确的仓库、分支、工作流程及构建参数——尚未成为消费者的默认行为。若攻击者破坏发布操作却无法满足所有来源验证要求，其发布的包应被自动化系统自动拒绝。

然而，短期现实却令人担忧。在过去 60 天内，至少有 4 起攻击事件表明，攻击者利用发布工作流程、操作依赖关系及维护者凭证，能相对轻松地获取高价值敏感信息。每一起新事件都在公开技术手册中增添了利用持续集成输出窃取令牌、劫持维护者账户及滥用可靠发布机制等新手段。除非来源验证从可选措施转变为默认行为，否则那些带有“官方”标签的包名所蕴含的信任价值，将远远超出其发布流程所能证明的合理性，供应链安全防线恐将继续面临严峻挑战。