Bitwarden CLI npm package compromised to steal developer credentials

Bitwarden CLI Compromise: A Case Study in Supply Chain Risk

On April 22, 2026, between 5:57 PM and 7:30 PM ET, a malicious version of the @bitwarden/cli package, specifically 2026.4.0 (for which a CVE is being issued), was available on npm. Developers who downloaded it during that 90-minute window likely had their environments and credentials compromised. Bitwarden quickly responded by revoking compromised access and deprecating the malicious release. This crucial step confirmed no end-user vault data or production systems were affected, reassuring their user base.

For developers, however, the impact was significant, forming part of a broader campaign by a threat actor known for similar supply chain attacks. This incident demonstrates a clear escalation in operational sophistication, exemplifying MITRE ATT&CK T1195.002: Compromise Software Supply Chain.

Exploiting GitHub Actions in the CI/CD Pipeline

The attack vector was a compromised GitHub Action within Bitwarden's CI/CD pipeline. Specifically, the checkmarx/ast-github-action was abused. Crucially, attackers didn't simply guess credentials; they exploited a trusted build process to inject malicious code.

The attack chain involved several key stages:

1. CI/CD Compromise: The threat actor gained control of a GitHub Action within Bitwarden's CI/CD pipeline, enabling them to modify the package before its publication to npm.
2. Malicious Injection: They injected malicious code into the @bitwarden/cli package, specifically modifying the preinstall script and the CLI entry point. This execution via a preinstall hook is a common technique, aligning with MITRE ATT&CK T1059.007: Command and Scripting Interpreter: JavaScript.
3. Loader Script: This preinstall script then launched a loader script, bw_setup.js.
4. Bun Runtime: The bw_setup.js script checked for the Bun runtime. If absent, it downloaded Bun, ensuring the malware could execute reliably by installing its required runtime regardless of the victim's system configuration.
5. Credential Theft: Once Bun was ready, it launched an obfuscated JavaScript file, bw1.js. This core credential-stealing malware acted as a multi-cloud harvester, designed to grab npm tokens, GitHub authentication tokens, SSH keys, and AWS, Azure, and Google Cloud credentials. It even targeted AI coding tool configurations like Claude and Cursor. This targets sensitive data, a clear instance of MITRE ATT&CK T1552.001: Unsecured Credentials: Credential Files.
6. Exfiltration: The stolen data was encrypted using AES-256-GCM. The primary exfiltration route was to audit.checkmarx[.]cx, a domain impersonating Checkmarx, specifically targeting the audit.checkmarx[.]cx/v1/telemetry endpoint. As a fallback, the malware created public GitHub repositories under the victim's account, committing the encrypted data there, a method consistent with MITRE ATT&CK T1567.001: Exfiltration Over Web Service: Exfiltration to Code Repository. These repositories often used a Dune-themed naming scheme (<word>-<word>-<3 digits>) and contained the string "Shai-Hulud: The Third Coming." The use of the __decodeScrambled obfuscation routine with seed 0x3039 and the presence of gzip+base64 components are overlapping indicators that firmly link this incident to previous TeamPCP malware campaigns, demonstrating MITRE ATT&CK T1027: Obfuscated Files or Information.
7. Self-Propagation: The malware then acted as an npm worm. It used stolen npm credentials to identify other packages the victim could publish, injecting malicious code and pushing new compromised versions downstream. This self-propagation mechanism demonstrates MITRE ATT&CK T1588.006: Supply Chain Compromise for further distribution. It also used GitHub tokens to inject malicious Actions workflows into CI/CD pipelines, establishing persistent access. Shell RC persistence was also observed, aligning with MITRE ATT&CK T1546.004: Boot or Logon Autostart Execution: .bash_profile and .bashrc.

Beyond data exfiltration, this credential theft aimed to establish a foothold for cascading supply chain compromises. The malware included geographic evasion, terminating execution if the system locale was Russia, which offers insight into the actor's operational security protocols.

Consequences of Developer Compromise

Developers who installed 2026.4.0 during the exposure window must assume their systems are compromised. The implications extend beyond a simple password rotation, requiring several specific actions:

• Credential Rotation: Immediate rotation of all npm tokens, GitHub tokens, SSH keys, and cloud credentials used on the affected system is essential. This includes secrets configured for CI/CD pipelines and developer environments.
• System Rebuild: The compromised system itself should be treated as untrustworthy. A full wipe and rebuild is often the most secure remediation.
• Supply Chain Risk: Stolen npm tokens mean any packages maintained by the victim could have been re-infected and republished. A thorough audit of npm packages and GitHub repositories for unauthorized changes or newly created public repositories is highly recommended.

The malware's capability to inject malicious GitHub Actions workflows grants attackers persistent access to CI/CD pipelines. This capability establishes a direct vector for further supply chain attacks, impacting downstream users and an organization's software delivery process.

Strengthening Defenses Against Supply Chain Attacks

Bitwarden's incident response contained the immediate threat by revoking access and deprecating the malicious package. However, this incident highlights a systemic issue: software supply chain defenses are still largely reactive.

Discussion on Hacker News proposed a "min-release-age" for npm packages: implement a cooldown period before a new package version becomes widely available. If a malicious package is uploaded, this cooldown gives security teams and automated scanners a window to detect and remove it before it spreads. While not a complete solution, this represents a practical architectural shift that could significantly reduce the impact of rapid compromises.

We also need to re-evaluate trust models for CI/CD environments. Ideally, a compromised GitHub Action should be prevented from publishing malicious packages. This calls for several critical shifts. First, the principle of least privilege must be rigorously applied to CI/CD jobs. This means limiting permissions to only what is strictly necessary for a task. For instance, if a build component is compromised, strong isolation ensures it cannot laterally move or access unrelated secrets, thereby containing the blast radius of an attack.

Second, once a software build is finalized, its artifacts should be treated as immutable. Any subsequent modification must trigger a complete re-verification process. This prevents post-build tampering and ensures the integrity of the released package. Third, enhanced telemetry and anomaly detection within CI/CD pipelines are crucial. This involves actively monitoring for unusual activities such as unexpected file downloads (like the Bun runtime in this case), atypical script executions, or unauthorized attempts to modify package manifests. Such behavioral analysis can flag suspicious activity before it escalates.

Finally, while npm's trusted publishing aims to secure the publication process, this incident demonstrates that the upstream build environment itself remains a critical attack surface. This compromise, believed to be the first time a package using NPM trusted publishing has been affected, underscores that even with robust publishing mechanisms, the integrity of the build pipeline must be continuously verified. We can no longer assume inherent trust in these environments.

This incident's implications reach far beyond Bitwarden and npm, exposing vulnerabilities inherent across the entire software supply chain. The threat actor's actions indicate a persistent and evolving threat, with increasingly sophisticated methods. A purely reactive approach, addressing each incident in isolation, is unsustainable. Instead, proactive, architectural defenses are essential, designed to assume compromise at every stage and limit potential damage. While a "min-release-age" is a valuable initial step, it's just one component of a broader defense strategy.