2026年4月22日，一个伪装成Bitwarden官方命令行工具（CLI）的恶意包出现在npm注册表中，包名为@bitwarden/cli@2026.4.0。在短短93分钟内，任何通过npm安装该CLI的用户都会收到一个植入了后门的版本。Bitwarden迅速发现并移除了该恶意包，并表示没有证据表明攻击者访问了终端用户的密码库数据或破坏生产系统。
攻击目标：基础设施密钥而非密码库
安全研究公司JFrog分析后发现，该恶意载荷对Bitwarden密码库本身并不感兴趣。它瞄准的是更广泛的凭证类型：GitHub令牌、npm令牌、SSH密钥、Shell历史记录，以及AWS、GCP、Azure的云凭证，甚至包括GitHub Actions密钥和AI工具配置文件。这些凭证控制着团队构建、部署和访问基础设施的方式。
具体而言，攻击脚本在安装时和运行时均会执行。它修改了预安装钩子和bw二进制入口点，加载Bun运行时并执行混淆后的有效载荷。即便开发者从未在CLI中输入过任何密码，恶意程序依然能系统地收集环境中所有高价值凭证。
事件根源：CI/CD流水线遭入侵
安全公司Socket指出，此事件似乎源于Bitwarden的CI/CD管道中一个被攻破的GitHub Action，这与Checkmarx研究人员追踪的供应链攻击模式一致。Bitwarden随后确认，该事件与Checkmarx披露的更大规模供应链活动相关。Checkmarx曾在60天内披露了多个被攻破的GitHub Actions工作流和OpenVSX插件。
Bitwarden为超过5万家企业和1000万用户提供服务，其CLI被广泛用于自动化工作流中。官方文档将npm列为最简便的安装方式，但正是这种“官方”身份使得恶意包能轻易绕过传统信任检查。
信任链条的薄弱环节
npm的“可信发布”（Trusted Publishing）模型本意是通过OIDC替换长期有效的令牌，但该事件表明，如果发布工作流本身被攻破，“官方”徽章依然会自动附加到恶意包上。GitHub的环境设置允许手动审批，SLSA框架也要求消费者验证来源元数据，但这一标准尚未成为默认行为。
JFrog的分析显示，攻击者一旦获得GitHub令牌，就能自动验证令牌、枚举可写仓库、列出Actions密钥、创建分支、提交工作流、执行并下载产物，最终清除痕迹。一个被感染的开发者笔记本电脑成为从本地凭证到整个自动化基础设施的跳板。
加密货币与金融领域的关联
在加密货币和金融科技领域，类似的供应链攻击模式曾导致重大损失。Bybit事件中，攻击者通过破坏开发者工作站篡改Safe Web UI，最终盗取资金。Bitwarden攻击结构类似，只是入口换成了npm包。对于使用Bitwarden管理私钥、API密钥或部署凭证的加密项目而言，一个看似无害的CLI更新就可能让攻击者获得对整个开发运维系统的控制权，而无需触及密码库本身。
Sonatype统计显示，仅2025年就发现了超过45.46万个新恶意包，累计总数超过120万。Bitwarden事件是这一趋势的最新例证：发布工作流和包注册表已成为主要攻击面。
市场影响分析
此次事件对加密货币行业有直接警示意义。许多Web3团队依赖Bitwarden、1Password等工具管理开发密钥和基础设施凭证，如果这些工具本身成为攻击向量，后果不堪设想。事件将加速行业对“可信发布”和“SLSA来源验证”的采纳，同时也可能推动安全团队重新评估内部依赖策略——从“信任官方来源”转向“信任可验证的构建过程”。短期内，用户可能减少对npm官方包的盲目信任，转而使用签名校验或镜像仓库。对于Bitwarden而言，尽管未造成实质性数据泄露，但品牌声誉受损，企业客户可能会要求更严格的审计。
最终，这93分钟的攻击提醒我们：在供应链安全领域，“官方”并不等于“安全”。除非验证来源匹配预期的仓库、分支、工作流和构建参数成为默认消费行为，否则下一个“官方”包仍可能成为潜伏的炸弹。