What Happened
On April 22, 2026, the @bitwarden/cli npm package was compromised with malicious code aiming to steal developer credentials. This package was available from 5:57 PM to 7:30 PM ET. During this 93-minute window, any developer installing or updating the package received malware designed to exfiltrate credentials.
The attack was executed through a compromised GitHub Action in Bitwarden's CI/CD pipeline. The threat actor group TeamPCP, known for a similar attack on Checkmarx, injected malicious code into the build process. The malware exfiltrated stolen data by creating public GitHub repositories under victim accounts, using the victim's infrastructure as the exfiltration channel.
Timeline
- 5:57 PM ET - Malicious
@bitwarden/clipackage published to npm registry via compromised CI/CD pipeline. - 5:57 PM - 7:30 PM ET - Credential-stealing malware distributed to developers.
- 7:30 PM ET - Malicious package removed from distribution.
- Post-incident - Investigation reveals compromised GitHub Action as the injection point, linking the attack to TeamPCP.
Which Controls Failed or Were Missing
Pipeline Integrity Verification: The CI/CD pipeline lacked controls to detect a compromised GitHub Action. There was no validation of the action's integrity before executing with publish privileges.
Artifact Signing and Verification: The package was not cryptographically signed to detect unauthorized modifications. Proper signing would have prevented the malicious package from reaching the npm registry.
Least Privilege in CI/CD: The GitHub Action had excessive privileges to publish packages. Enforcing the principle of least privilege would have limited its access.
Runtime Monitoring: There was no mechanism to detect unexpected network calls, file system access, or credential-harvesting behavior in the build artifacts.
Dependency Pinning for Actions: The GitHub Action was likely a third-party dependency with a floating version reference, allowing the compromised version to be pulled automatically.
What the Standards Require
NIST 800-53 Rev 5 SA-10 (Developer Configuration Management) requires configuration management during development, implementation, and operation. A compromised GitHub Action indicates a failure in maintaining configuration management over CI/CD components.
NIST 800-53 Rev 5 SA-15 (Development Process, Standards, and Tools) mandates a documented development process that includes security requirements for development tools. Your CI/CD pipeline and its GitHub Actions are part of these tools.
ISO 27001 Annex A.8.31 (Separation of Development, Test and Production Environments) requires controls to separate and secure environments. This principle extends to ensuring build processes cannot inject malicious code into production artifacts.
PCI DSS v4.0.1 Requirement 6.3.2 states that the security of custom software must be maintained throughout its lifecycle, including securing the build and deployment pipeline.
SLSA Framework Level 2 requires verifiable provenance for build artifacts. The Bitwarden incident would have been detectable with SLSA Level 2 or higher, as it would show unexpected GitHub Action execution.
Lessons and Action Items for Your Team
Pin all GitHub Actions to commit SHAs. Review workflow files in your repositories. Replace uses: actions/checkout@v3 with uses: actions/checkout@a12a3943b4bdde767164f792f33f40b04645d846. This prevents an attacker from affecting your builds by moving tags or branches.
Implement package signing and verification. If you publish packages, sign them using Sigstore or GPG. Configure your CI/CD pipeline to verify that published artifacts match the generated builds. Document expected signing key fingerprints and monitor for changes.
Apply least privilege to CI/CD credentials. Audit every secret and token in your GitHub Actions, GitLab CI variables, or Jenkins credentials. Each credential should have the minimum necessary scope. Publishing tokens should only allow specific packages, not all packages under your organization.
Monitor your published artifacts for unexpected changes. Set up automated checks to verify published packages against known-good builds. For npm packages, compare file hashes. For container images, compare layer digests. Alert on any mismatch.
Review your GitHub Actions dependencies quarterly. Treat third-party actions like any other dependency. Maintain an inventory of actions used, their maintainers, and the last review date. Remove unnecessary actions. For critical workflows, consider forking trusted actions into your organization.
Implement build provenance. Generate and publish SLSA provenance for your artifacts. Tools like slsa-github-generator for GitHub Actions or in-toto for other CI systems create signed records of your build process.
Separate publish credentials from build credentials. Your build process should not have automatic publish access. Implement a two-stage pipeline: the build stage produces signed artifacts, and a separate publish stage—potentially requiring manual approval—pushes to the registry.
The 93-minute window of the malicious Bitwarden package highlights the rapid spread of supply chain attacks. Your detection and response capabilities must operate on the same timescale. If you cannot detect a compromised build within minutes, implement preventive controls to make such compromises impossible.
