4月22日，安全社区经历了一场惊心动魄的93分钟——Bitwarden的官方命令行界面（CLI）npm包@bitwarden/cli@2026.4.0被恶意版本替换。任何在这段时间内通过npm安装该CLI的用户，都会收到一个带有后门的替代品。Bitwarden在发现后迅速删除了该包，并声明称未发现攻击者访问最终用户密码库或破坏生产系统的证据。但安全分析公司JFrog的深入调查显示，这个后门的目标远不止密码库本身。
攻击细节：凭证收割机而非密码盗贼
JFrog分析发现，恶意载荷对Bitwarden密码库毫无兴趣，而是专注于窃取GitHub令牌、npm令牌、SSH密钥、Shell历史、AWS凭证、GCP凭证、Azure凭证、GitHub Actions密钥以及AI工具配置文件。这些正是管理团队构建、部署和访问基础设施的关键凭证。恶意包通过重写preinstall钩子和bw二进制入口点，加载Bun运行时并启动混淆后的有效载荷。攻击不仅在安装时触发，还在运行时持续运作——也就是说，即使你从未在密码库中存储密码，后门仍会系统地收集你CI管道、云账户和部署自动化系统的凭证。
Bitwarden为超过5万家企业客户和1000万用户提供服务，其CLI被官方文档描述为“强大、功能完备”的密码库管理工具，常被集成到自动化工作流中（通过环境变量进行认证）。npm是官方推荐的首选安装方式。正是这种自动化使用场景、开发者电脑安装与官方npm分发的结合，使CLI恰好位于高价值基础设施凭证的集中地。
信任链瓶颈：官方标识不再可靠
安全公司Socket指出，此次攻击很可能是利用了Bitwarden CI/CD流水线中一个被攻破的GitHub Action，这与Checkmarx研究人员追踪的供应链攻击模式一致。Bitwarden已确认该事件与更广泛的Checkmarx活动有关。这意味着，攻击者并未直接篡改源码仓库，而是攻陷了发布流水线本身。
npm的“信任发布”（trusted publishing）模型本意是用基于OIDC的CI/CD认证替代长期有效的npm发布令牌，以减少令牌泄露风险。但Bitwarden事件表明，即使采用信任发布，问题只向上移动到工作流层的完整性。如果攻击者能够利用发布工作流本身，那么“官方”标签仍然会伴随恶意包出现。GitHub的环境设置允许要求审批者签署才能部署，但SLSA框架进一步要求消费者验证来源是否匹配预期参数（仓库、分支、标签、工作流、构建配置）。然而，除非来源验证成为消费者的默认行为，否则官方包名将承受超出其发布流程所能保障的信任。
一钥开多门：从开发者笔记本到基础设施门户
一旦恶意软件获得一个GitHub令牌，它可以验证令牌、枚举可写仓库、列出GitHub Actions密钥、创建分支、提交工作流、等待执行、下载产物然后清理——形成自动化的横向移动链。开发者笔记本上安装的受污染官方包，变成从本地凭证存储到GitHub访问权限的桥梁，再通过GitHub令牌触及组织内整个自动化基础设施。这与Bybit事件的攻击路径高度相似：攻击者通过被攻破的开发者工作站，污染了受信任的上游接口，最终到达受害者的运营流程。区别在于Bybit涉及被篡改的Safe Web UI，而Bitwarden涉及被篡改的官方npm包。
在加密货币、金融科技或托管环境中，这条路径可以从凭证存储直达发布签名者、云访问和部署系统，而无需触碰任何密码库条目。
近期同类事件：供应链攻击进入加速期
仅在60天内，安全行业已观察到多起关联事件：Checkmarx披露被攻破的GitHub Actions工作流和OpenVSX插件；JFrog记录了Trivy GitHub Action被攻破导致LiteLLM发布令牌失窃并用于恶意PyPI发布；Axios披露通过被攻破的维护者账户传播的恶意npm版本在两小时内流通。Sonatype统计显示，仅2025年新增恶意包就超过45.46万个，累计总量已超120万个。Bitwarden事件是这一链条的最新环节，证实了发布工作流和包注册表已成为首要攻击面。
市场影响与教训
对于加密货币和区块链企业而言，此次事件敲响了警钟：即使是安全工具本身也可能成为攻击入口。开发者环境中的GitHub令牌、云凭证如被窃取，攻击者可进一步获得项目代码库的读写权限、篡改智能合约部署流程、窃取私钥管理系统的访问权。在DeFi和CeFi领域，这类凭证泄露往往意味着数字资产的实际损失。
更强的防御方向是重新定义“官方”的含义：信任发布附带来源数据，但更关键的是验证来源是否匹配预期构建参数。如果SLSA标准的自动验证成为默认消费行为，那么攻击者即使攻破Action却无法满足所有来源约束，所发布包将在落地前被自动化消费者拒绝。然而，更现实的近期趋势是反向的：攻击者已在60天内通过4起事件展示了攻破发布工作流、Action依赖和维护者凭证的低摩擦高回报。除非来源验证成为默认行为而非可选策略，否则官方包名将继续承载超出其发布流程保障的信任。
企业应审查自身信任链：确保CI/CD流水线采用OIDC信任发布并施加分支保护、手动审批；监控GitHub Actions中使用的第三方Action来源；对开发者机器实施运行时安全监控，防止安装时后门窃取本地凭证。毕竟，一次93分钟的官方包污染，可能导致无数基础设施的长期沦陷。