Bitwarden CLI 被投毒：Checkmarx 供应链攻击的延伸

今天 HN 上另一条让人心里发紧的，是 Bitwarden CLI 被投毒的事。

Socket 的研究团队发现，Bitwarden CLI 的 npm 包 @bitwarden/[email protected] 被植入了恶意代码。Bitwarden 是全球排名前三的密码管理器，服务超过 1000 万个人用户和 5 万多家企业。这次是它连续第二次被同一个供应链攻击链击中——上次是 Checkmarx。

攻击的入口很熟悉：通过被污染的 GitHub Action 入侵 Bitwarden 的 CI/CD 流水线。恶意代码被嵌入在 bw1.js 文件里。

但这个载荷比 Checkmarx 那次更完整、更激进。

它用的 C2 端点完全一样：audit.checkmarx.cx/v1/telemetry，经过 __decodeScrambled 混淆。但这次的窃取范围更大：GitHub token、AWS 凭证、Azure token、GCP 凭证、npm 配置、SSH 密钥、Claude 和 MCP 配置文件。它甚至把 Bun v1.3.13 解释器从 GitHub releases 下载到目标机器上运行。

然后它开始传播：偷取 npm token 来找可以写包的仓库，往别人的包里注入 preinstall hook；往 GitHub 仓库注入 Actions workflow 来捕获 repo secret。

嗯，最让人不安的不是"Bitwarden 被黑了"，而是整个攻击链的完整性和持续性。

Checkmarx 被攻击后，攻击者并没有停止。他们继续寻找下一个目标，找到了 Bitwarden，用同样的手法、更完整的载荷再次得手。这意味着：这不是一个偶然的失误，而是一个持续的、有组织的供应链攻击运动。

而且这次的载荷有一个很有意思的细节：它带有"俄罗斯 locale 自毁开关"。如果系统语言以 "ru" 开头，它会静默退出。这是典型的 APT 手法：攻击者在自己的基础设施上测试时，不希望误伤自己人。

从工程角度看，这次事件最有价值的教训，是"CI/CD 是供应链中最脆弱的一环"。

攻击者不需要攻破 Bitwarden 的代码仓库，不需要攻破 Bitwarden 的服务器，他们只需要攻破一个 GitHub Action。而这个 Action 的权限，足以在构建时往 npm 包里注入恶意代码。CI/CD 流水线的权限模型，本质上就是"信任构建环境"，而构建环境恰恰是最容易被攻击的环节。

Socket 给出的修复建议很具体：

• 立即从开发系统和构建环境中移除受影响的包
• 轮换所有可能被暴露的凭证，包括 GitHub token、npm token、云凭证、SSH 密钥、CI/CD secret
• 检查 GitHub 是否有未授权的仓库创建，特别是那些 Dune 主题命名的仓库（{word}-{word}-{3digits} 模式）
• 审查 shell profile 是否被修改（~/.bashrc 和 ~/.zshrc）
• 查找锁文件 /tmp/tmp.987654321.lock 和出站连接到 audit.checkmarx.cx

从更大的角度看，我觉得这次事件真正提醒我们的，是另一件更根本的事：当 CI/CD 流水线的权限足够大时，"供应链安全"就不再是"依赖包安不安全"的问题，而是"构建环境本身安不安全"的问题。而这件事，目前几乎没有开发者在主动防御。

所以今天真正值得记住的，不是"Bitwarden 被黑了"，而是另一句更关键的话：CI/CD 是供应链中最脆弱的一环。攻击者不需要攻破你的代码，他们只需要攻破你的构建。而你的构建环境，很可能比你的代码更容易被攻破。