2026年4月22日，一款伪装成Bitwarden官方CLI的恶意npm包@bitwarden/cli@2026.4.0上线了整整93分钟。在这93分钟里，任何通过npm拉取该CLI的开发者，都会得到一个带后门的替代品——它的真正目的不是窃取密码库，而是将开发者机器变成攻击GitHub账户的跳板。
事件始末：从官方包到后门
Bitwarden在发现漏洞后迅速下架了恶意包，并声称没有证据表明攻击者访问了最终用户的密码库数据或破坏了生产系统。但安全研究公司JFrog的深入分析揭示了更危险的真相：恶意负载对Bitwarden密码库毫无兴趣，而是系统性地收集GitHub令牌、npm令牌、SSH密钥、Shell历史、AWS/GCP/Azure凭证、GitHub Actions密钥以及AI工具配置文件。这些凭证控制着团队如何构建、部署和访问基础设施。
分析显示，恶意包在安装时通过重写preinstall钩子和bw二进制入口点，加载了Bun运行时并启动混淆后的负载。这意味着，即使组织未在Bitwarden中存储任何密码，运行被篡改的CLI后，其CI管道、云账户和部署自动化中的所有凭证都会被窃取。
攻击链：一个凭证打开无数扇门
一旦获得GitHub令牌，恶意软件可以验证令牌有效性、枚举可写仓库、列出GitHub Actions密钥、创建分支、提交工作流、等待执行、下载制品并清理痕迹。一个被窃取的令牌即可通过自动化链条，转化为对整个组织自动化基础设施的持久访问。
安全公司Socket指出，该攻击利用了Bitwarden CI/CD管道中一个被攻陷的GitHub Action，这与Checkmarx研究人员追踪的供应链攻击模式一致。Bitwarden官方也确认事件与Checkmarx活动相关联。
信任瓶颈：官方身份不再安全
npm的信任发布模型（Trusted Publishing）用基于OIDC的CI/CD认证替代长期有效的npm发布令牌，本意是减少凭据泄漏风险。但Bitwarden事件表明，信任链的薄弱环节在于触发发布的工作流本身。如果攻击者能攻陷发布工作流，即使使用了OIDC，“官方”标签依然附着在恶意包上。
GitHub允许通过环境设置要求审核者批准后才能部署工作流，SLSA框架则要求消费者验证来源是否匹配预期参数。但Bitwarden事件显示，除非来源验证成为消费者默认行为，否则攻击者将反复利用工作流层的漏洞。
加密行业的镜鉴：供应链攻击愈演愈烈
该事件在结构上与加密行业著名的Bybit事件高度相似：攻击者通过被感染的开发者工作站，篡改了Web UI（Bybit）或npm包（Bitwarden），然后触达受害者的操作流程。在加密、金融科技或托管环境中，这种路径可以从凭证存储直达签名发布者、云访问和部署系统，而无需触碰密码库条目。
Checkmarx在60天内披露了被攻陷的GitHub Actions工作流和OpenVSX插件，Cloud Security Alliance警告TeamPCP活动正积极攻陷开源项目和CI/CD组件。Sonatype数据显示，2025年单年新增超过45.46万个恶意包，累计总数突破120万。Bitwarden事件再次确认，发布工作流和包注册表已成为主要攻击面。
市场影响与防范建议
对加密项目方和开发者团队而言，此次事件敲响警钟：
- 供应链安全需从“信任官方”转向“验证来源”：应实施SLSA 2+级别来源验证，在CI/CD环境中使用短期凭证和手动审批。
- 最小权限原则：GitHub令牌、API密钥等应遵循最小必要权限，并定期轮换。
- 监控异常行为：在CI管道中部署行为检测规则，警惕非预期的工作流或包发布。
- 教育开发者：安装任何依赖（尤其是通过npm）前，检查包的SHA256校验和，并优先使用官方提供的安全安装方式（如Bitwarden的二进制下载）。
此次事件最深刻的影响在于重新定义了“官方”的含义。在攻击者持续攻陷工作流的当下，一个带有“官方”标签的包可能比其发布流程本身更不可信。对于整个加密与区块链行业——其基础设施高度依赖自动化CI/CD和GitHub Actions——这不仅仅是一次安全警告，而是整个信任模型的根本挑战。