2026年4月22日，知名密码管理工具Bitwarden的命令行界面（CLI）官方npm包@bitwarden/cli@2026.4.0被恶意篡改。在短短93分钟内，通过npm安装该版本的开发者实际上部署了一个带有后门的替身程序。Bitwarden发现后立即下架了恶意包，并声明未发现用户保险库数据泄露或生产系统受损。
恶意载荷的目标并非密码
安全研究公司JFrog对恶意载荷进行了深入分析，发现攻击者对Bitwarden的保险库数据毫无兴趣，而是将矛头对准了开发者和基础设施团队的高价值凭证：GitHub tokens、npm tokens、SSH密钥、shell历史记录、AWS/GCP/Azure凭证、GitHub Actions secrets以及AI工具配置文件。这些正是控制团队构建、部署和访问基础设施的关键资产。
JFrog分析显示，恶意包在安装阶段和运行时均触发了攻击：它重写了preinstall钩子和bw二进制入口点，加载Bun运行时并执行混淆载荷。这意味着即使用户没有主动运行Bitwarden CLI，只要安装了包，恶意代码就会静默收集系统凭证。
信任链的断裂点：CI/CD流程
安全公司Socket指出，此次攻击很可能利用了BitwardenCI/CD流水线中被攻陷的GitHub Action，这与Checkmarx团队跟踪的供应链攻击模式一致。Bitwarden证实该事件与Checkmarx的广泛攻击活动有关。
这一事件暴露了一个严峻问题：尽管npm推出了基于OIDC的可信发布模型，用短期身份认证取代长期发布token，但发布流程本身的完整性才是更薄弱的环节。攻击者无需篡改源代码仓库，只需攻陷CI/CD工作流或依赖的Action，就能通过“官方”路径发布恶意包。可信发布只能证明包来自授权的发布流程，却无法保证该流程本身是安全的。
一个token通往多扇门
JFrog详细描述了令牌被窃取后的连锁反应：恶意代码获取GitHub token后，可验证令牌有效性、枚举可写仓库、列出GitHub Actions secrets、创建分支、提交工作流并等待执行，从而下载产物并抹除痕迹。一个被感染的开发者笔记本通过单个token变成了进入整个组织自动化基础设施的桥梁。
这种攻击模式与加密领域此前发生的Bybit事件（被篡改的Safe前端UI）结构高度相似：都是通过攻陷可信上游接口，最终到达受害者操作流程。对于加密、金融科技或托管类企业而言，攻击路径可以从凭证存储直达发布签名者、云访问和部署系统，而无需触碰保险库中的任何密码。
供应链攻击愈演愈烈
Bitwarden事件并非孤例。在2026年3月至4月的60天内，Checkmarx披露了被攻陷的GitHub Actions工作流和OpenVSX插件；JFrog记录了通过Trivy GitHub Action窃取LiteLLM发布token进而发布恶意PyPI包的事件；Axios披露了通过维护者账户被攻陷发布恶意npm版本的事件。Sonatype统计，仅在2025年就发现了超过45.46万个新的恶意包，累计总数已超过120万。
这张事件表清楚表明：发布工作流和包注册表已成为主要攻击面。官方包名所携带的信任，越来越多地超过了其发布流程实际所能保证的安全水平。
对加密货币行业的启示
对于依赖自动化部署、CI/CD和多个云服务的加密项目而言，此次事件敲响了警钟：必须重新定义“官方”的含义。SLSA框架要求消费者验证出处来源是否匹配预期的仓库、分支、工作流和构建参数。但当攻击者可以攻陷工作流层时，即使满足所有出处约束，输出仍然是恶意包。
除非出处验证成为默认的消费者行为，而非常规可选的策略层，否则官方包名将继续承载超出其流程合理性范围的信任。Bitwarden事件是一个清晰的信号：信任上游软件包时，不仅要验证其签名，更要审视其整个发布流程的安全性。对于加密资产托管、智能合约部署等关键场景，应尽可能采用手动审批的部署环境、标记保护规则和分支限制，并对CI/CD工作流进行定期安全审计。