2026年4月22日，密码管理器Bitwarden的官方CLI包（@bitwarden/cli@2026.4.0）在npm上被恶意版本替换，持续了93分钟。所有在此期间通过npm安装该CLI的用户，都将收到一个内置后门的版本。Bitwarden在发现后迅速移除恶意包，并声称无证据表明攻击者访问了终用户密码库或生产系统。
攻击目标：基础设施凭证而非密码
安全研究公司JFrog的分析显示，攻击者对Bitwarden密码库兴趣不大，而是精准瞄准了开发者和运维人员最敏感的资产：GitHub token、npm token、SSH密钥、Shell历史记录、AWS/GCP/Azure凭证、GitHub Actions Secrets以及AI工具配置文件。这些凭证控制着团队的构建、部署和基础设施访问权限。
具体而言，GitHub token可被用于仓库访问、工作流滥用、秘密列取和横向移动；npm Token可发布恶意包或篡改发布流程；云凭证则可能暴露整个云工作负载、存储和部署系统。值得注意的是，Shell历史记录中可能包含粘贴的密码、内部主机名和工作流细节，进一步放大攻击面。
安装即攻陷：从开发者设备到自动化管道
Bitwarden的服务覆盖超过5万家企业和1000万用户。该CLI被官方描述为“强大、全功能”的密码管理工具，且npm被列为推荐的安装方式之一——尤其适合已熟悉该注册表的用户。这种定位恰好将CLI部署在高价值基础设施凭证的集中之地。
JFrog分析揭示了恶意包的运行机制：它在安装阶段（preinstall hook）和运行时（bw二进制入口点）都植入了加载器，会获取Bun运行时并启动混淆的有效载荷。这意味着，即使组织没有在运行CLI时触及任何存储的密码，恶意软件也能系统性地收集控制其CI管道、云账户和部署自动化的凭证。
安全公司Socket指出，该攻击疑似利用了Bitwarden CI/CD管道中一个被攻陷的GitHub Action，与Checkmarx研究人员追踪的模式一致。Bitwarden也证实了本次事件与更广泛的Checkmarx供应链攻击行动相关。
信任瓶颈：官方包审批流程的脆弱性
Npm已建立“可信发布”（trusted publishing）模型来应对此类风险：用基于OIDC的CI/CD身份验证替代长期有效的发布Token，移除攻击者劫持注册表发布的最常见途径。但Bitwarden事件表明，真正的难题在于工作流层——如果攻击者能够攻陷发布工作流本身，即使使用了可信发布，带有“官方”标签的包仍然是恶意的。
GitHub的环境设置允许组织要求审核人签署才能执行工作流；SLSA框架更进一步，要求消费者验证出处是否匹配预期的仓库、分支、标签、工作流和构建配置。然而在现实中，出处验证尚未成为默认的消费者行为，导致官方包名称被赋予了超出其发布过程所能保证的信任。
一次令牌，多扇门：对加密项目的启示
在加密货币行业，类似Bybit事件的结构性类比已经出现：攻击者通过损坏的开发者工作站污染了可信的上游接口，进而触及目标的操作流程。不同之处在于Bybit涉及篡改的Safe Web UI，而Bitwarden涉及篡改的官方npm包。在加密、金融科技或托管环境中，这条攻击路径可以从凭证存储指向发布签名者、云访问和部署系统，而无需触及任何密码库条目。
根据Sonatype统计，2025年仅一年就发现了超过45.46万个新的恶意包，累计总数已超过120万个。而在2026年3月至4月的60天内，Checkmarx披露了被攻陷的GitHub Actions工作流和OpenVSX插件；JFrog记录了被攻陷的Trivy GitHub Action导出LiteLLM发布Token并造成恶意PyPI发布；Axios披露了通过被攻陷维护者账户发布的恶意npm版本。Bitwarden事件进一步确认了发布工作流和包注册表已成为首要攻击面。
市场影响：加密基础设施安全需要根本性重构
Bitwarden事件对加密项目的直接影响是：如果开发者或运维人员的设备在安装官方CLI期间被植入后门，其GitHub、云平台及自动化管道的凭证将面临泄露风险。对于持有大量数字资产的交易所、DeFi协议和托管机构而言，这些凭证往往是访问签名节点、部署合约、管理多签钱包的“关键钥匙”。一旦被窃取，攻击者可能发起未授权的交易、提现或部署恶意合约。
本次事件加速了行业内对“官方”含义的重新定义。当前，可信发布只在注册表中证明了发布者的身份，而SLSA要求消费者验证出处是否匹配预期参数。如果出处验证成为默认行为，“官方”将意味着“由正确的工作流在正确约束下构建”，届时攻击者即便攻陷了Action，也无法满足所有出处约束，其恶意包会在落地前被自动消费者拒绝。然而，短期内更可能的情况是攻击者继续利用工作流缺陷、行动依赖和维护者邻近凭证进行低摩擦攻击，加密项目需尽快升级CI/CD安全策略，包括实施严格的出处验证、部署环境手动批准、标签保护和分支限制。