2026 年 4 月，安全研究团队 Socket 与 JFrog 联合披露了一起针对 Bitwarden CLI 的供应链攻击事件。攻击者通过入侵 Bitwarden 官方的 GitHub Actions CI/CD 流程，成功在 @bitwarden/cli 2026.4.0 版本中植入恶意代码，导致所有在 4 月份安装该版本的开发者面临凭证泄露风险。该攻击被确认与持续活跃的 Checkmarx 供应链攻击活动（又称 TeamPCP campaign）存在关联，意味着攻击者的目标是横向扩散至更多依赖项，而非单纯的单点入侵。
攻击链路详解
本次攻击的核心在于攻击者对 Bitwarden 自动化构建流程的渗透。Bitwarden CLI 作为一款开源密码管理器，其发布流程依赖 GitHub Actions 自动化完成构建、签名与 npm 包发布。攻击者正是在这一环节找到突破口，通过篡改工作流文件或窃取 runner 环境的凭证，将恶意代码注入到正式发布的安装包中。整个过程不涉及对源代码仓库的直接修改，而是利用了 CI/CD 链条的信任模型，使得最终产出的二进制文件携带官方签名与元数据，极大增加了被检测的难度。
恶意包的技术实现分为多个阶段。首先，攻击者替换了原本合法的 CLI 入口点，取而代之的是一个自定义的加载器 bw_setup.js。该文件通过 npm 的 preinstall 脚本钩子在包安装时自动触发，无需用户执行任何额外操作。加载器随后会检查目标系统是否已安装 Bun 运行时，如未安装则从 GitHub 下载，以此规避基于行为特征的静态检测。核心 payload 存储在混淆后的 bw1.js 文件中，解混淆后可观察到三个并行运行的凭证采集器，分别针对文件系统、Shell 环境与 GitHub Actions runner。
文件系统采集器的目标清单极为广泛：SSH 密钥（~/.ssh/ 目录）、.git-credentials、.npmrc、.env 文件、Shell 历史记录、以及 AWS、GCP、Azure 的云凭证存储。Shell 采集器则明确调用 gh auth token 提取 GitHub CLI 凭证，并扫描进程环境变量中的令牌模式。GitHub Actions runner 采集器专门针对 CI/CD 环境中的 secrets，能够读取工作流文件中配置的敏感信息。更值得关注的是，攻击者显式针对 AI 编码助手的配置文件进行扫描，包括 ~/.claude.json 与 ~/.kiro/settings/mcp.json，反映出攻击者对 AI 工具链暴露密钥的风险认知。
窃取的凭证在传输前经过混合加密处理，使用 AES-256-GCM 结合 RSA 加密确保数据安全。数据外传的首选目标域名为 `audit [.] checkmarx [.] cx，该域名故意伪装成合法的 Checkmarx 基础设施以降低警惕。若该外传路径被网络层阻断，恶意代码会回退至使用 GitHub 本身作为隐匿通道，将加密后的数据以仓库 Blob 的形式暂存于受害者的自有账户中，这一设计使得流量分析难以发现异常。
主动式防御与应急响应
面对此类供应链攻击，单纯依赖安装后检测往往为时已晚。组织需要在多个层面建立纵深防御机制：在 CI/CD 流程层面，所有工作流文件应实施代码审查与分支保护策略，禁止直接推送至主分支；GitHub Actions 的 runner 环境应采用临时性凭证而非长期 secrets，并在每次执行后自动销毁；工作流中的第三方 Action 应锁定至特定版本而非使用 @master 或 @latest 动态标签，防止依赖项被劫持。在包管理层面，可引入软件成分分析工具对 npm/pypi 包的安装前进行哈希校验，或使用 Socket 等平台提供的依赖安全扫描服务实时监控异常行为。
针对已暴露环境的应急响应，建议按以下优先级执行。第一步是立即卸载受污染包并清理本地缓存：执行 npm uninstall -g @bitwarden/cli 与 npm cache clean --force，确保移除所有残留工件。第二步是凭证轮换，应优先处理高价值凭证，包括 GitHub 个人访问令牌、npm 发布令牌、所有云服务商的访问密钥（AWS Access Key、GCP Service Account、Azure SAS Token），以及任何在受感染终端上使用过的 SSH 私钥。第三步是网络层面阻断，在边界防火墙或 EDR 中将 audit.checkmarx.cx 域名及 IP 94.154.172.43 加入黑名单。第四步是审计 CI/CD 运行记录，检查是否存在异常的仓库访问、新建分支、或未经授权的工作流触发。第五步是审查本地 AI 工具配置，清理 ~/.claude.json、~/.kiro/settings/mcp.json 等文件中可能存在的 API 密钥。
长期供应链安全实践
此次事件再次验证了「信任链即攻击面」这一安全原则的的现实意义。即使是拥有良好安全声誉的开源项目，一旦其供应链的某一环节被攻破，所造成的危害将沿着依赖链条向下游扩散。Bitwarden CLI 事件并非孤例，同一时期 Checkmarx 团队还披露了针对 Trivy、Checkmarx KICS、LiteLLM 等安全工具的类似攻击，表明攻击者正系统性地瞄准开发者工具链。
构建长期供应链安全能力需要从三个维度入手。技术层面应在 CI/CD 中实施依赖冻结（lockfile pinning）与构建可重现性验证，确保每次构建产出可追溯至明确的源码版本。流程层面应建立供应链安全基线，将第三方依赖的来源、完整性校验、更新管理纳入常规安全审计。人员层面则需加强开发者安全意识培训，使其理解供应链攻击的典型手法与风险后果，尤其是在使用全局安装的开发工具时保持审慎。只有当供应链安全成为组织级的基础设施能力，而非单点的应急响应，才能有效应对日益复杂的上游攻击。
资料来源：Cyber Kendra 报道披露了 Bitwarden CLI 2026.4.0 版本的攻击技术细节与 Checkmarx 供应链活动的关联。