What Happened
On April 22, 2025, attackers published a malicious version of the Bitwarden CLI password manager (version 2026.4.0) to the npm registry. The compromised package was available for about 1.5 hours before detection and removal. The attack, linked to the TeamPCP group, exploited unauthorized access through a GitHub Action in Bitwarden's CI/CD pipeline to inject malicious code into the official build process.
The payload targeted credentials across multiple platforms, including GitHub tokens, npm tokens, AWS credentials, and GCP credentials. Because Bitwarden CLI is a password manager, users who installed the compromised version potentially exposed the very secrets they were trying to protect.
Timeline
April 22, 2025
- Unauthorized access gained via compromised GitHub Action
- Malicious version 2026.4.0 published to npm registry
- Package available for download during the compromise window
- Detection occurred approximately 1.5 hours after publication
- Malicious package removed from npm registry
The rapid detection window limited exposure, but any automated CI/CD pipeline that pulled dependencies during this period could have ingested the compromised package.
Which Controls Failed or Were Missing
Pipeline Authentication and Authorization
The attack succeeded because the GitHub Action had sufficient privileges to publish packages without additional verification. Your CI/CD pipeline should enforce separation of duties—no single compromised credential should enable both code modification and package publication.
Credential Scope and Rotation
The GitHub Action possessed credentials with publishing rights to npm. These credentials were either long-lived or not properly scoped to specific operations. When attackers compromised the Action, they inherited full publishing capability.
Build Artifact Signing
The malicious package was accepted by npm without cryptographic verification that it originated from an authorized build process. Without artifact signing, the registry had no mechanism to distinguish legitimate builds from attacker-controlled ones.
Dependency Integrity Monitoring
Organizations consuming Bitwarden CLI lacked real-time alerting when a new version appeared outside normal release cadences. The 1.5-hour window suggests detection happened through manual observation or user reports rather than automated anomaly detection.
Secrets Detection in CI/CD
The compromised Action had access to multiple credential types (GitHub, npm, AWS, GCP). This indicates insufficient secrets compartmentalization—credentials for different systems were accessible within the same execution context.
What the Relevant Standards Require
NIST 800-53 Rev 5: SA-10 (Developer Configuration Management)
This control requires organizations to "protect the integrity of changes to the system, system component, or system service." For CI/CD pipelines, this means:
- Cryptographically signing build artifacts
- Maintaining an audit trail of all configuration changes
- Restricting modification rights to authorized personnel and processes
The Bitwarden incident violated SA-10 by allowing unauthorized publication without integrity verification.
OWASP ASVS v4.0.3: Requirement 14.2.3
"Verify that all components are signed and that signature verification is enforced before deployment." The compromised package reached npm without signature verification, directly violating this requirement.
PCI DSS v4.0.1: Requirement 6.3.2
"An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management."
Organizations subject to PCI DSS must maintain an inventory that would flag unexpected version changes. The sudden appearance of version 2026.4.0 outside a documented release should have triggered investigation.
ISO 27001: Control 8.31 (Separation of Development, Test and Production Environments)
Publishing credentials should never exist in the same security context as build execution. The compromised GitHub Action had both code execution and credential access, violating the separation principle.
Lessons and Action Items for Your Team
Implement Multi-Party Authorization for Package Publication
Configure your CI/CD pipeline to require approval from a separate system before publishing. Use GitHub's environment protection rules to mandate manual approval for production deployments, or implement a separate signing service that validates build provenance before releasing credentials.
Adopt Sigstore for Artifact Signing
Sign every build artifact with Sigstore's cosign tool. Configure your package registries to reject unsigned packages. This creates cryptographic proof that artifacts originated from your authorized build pipeline:
cosign sign --key cosign.key package@sha256:digest
cosign verify --key cosign.pub package@sha256:digest
Scope CI/CD Credentials to Specific Operations
Your GitHub Actions should use OIDC tokens with audience and subject claims, not long-lived secrets. For npm publishing, generate automation tokens scoped to specific packages and set them to expire after each release.
Monitor Registry Activity for Anomalies
Set up alerts for package publications that occur:
- Outside your normal release schedule
- Without corresponding Git tags
- With version numbers that skip your sequential pattern
- During off-hours for your team's timezone
Audit Third-Party Actions Before Use
The GitHub Action that was compromised became a trusted component of the pipeline. Review the source code of every Action you use. Pin Actions to specific commit SHAs rather than mutable tags:
- uses: actions/checkout@a12345abcdef # Pinned to commit
# NOT: actions/checkout@v2 # Mutable tag
Compartmentalize Secrets by Environment
Store AWS credentials, GCP credentials, and registry tokens in separate secret management systems. A compromised build job should never have access to production cloud credentials. Use workload identity federation instead of static credentials wherever possible.
Implement Dependency Lock Files with Hash Verification
Use package-lock.json with integrity hashes. Configure your package manager to reject installations where the downloaded artifact doesn't match the recorded hash. This prevents substitution attacks even if a malicious package reaches the registry.
Establish a Software Bill of Materials (SBOM) Process
Generate SBOMs for every build and store them in a tamper-evident log. When an incident occurs, you can immediately identify which systems consumed the compromised version. Tools like Syft or SPDX can automate SBOM generation in your pipeline.
The Bitwarden incident demonstrates that supply chain attacks don't require sophisticated zero-days—they exploit the trust relationships in your build pipeline. Your CI/CD system is a privileged environment that deserves the same security rigor you apply to production infrastructure.
