\1 Bitwarden CLI Compromised: 5 Steps to Secure Your Vault
←Back to Blog
Reading time: 7 minutes  |  Last verified: August 24, 2026  |  Category: Security Alerts

By Tim O. · April 22, 2026 · 7 min read

Bitwarden CLI Compromised: Supply Chain Attack Steals Developer Secrets

A malicious version of Bitwarden's official CLI package sat on npm for about 90 minutes on April 22, 2026, stealing GitHub tokens, SSH keys, cloud credentials, and shell history from developers who installed it during that window. Your vault encryption is probably fine. Everything around it might not be.

Key takeaways
  • The affected package is @bitwarden/cli@2026.4.0. A malicious copy was briefly distributed through the npm delivery path on April 22, 2026, from 5:57 to 7:30 PM ET, in connection with the Checkmarx incident. The compromised GitHub Action was checkmarx/ast-github-action.
  • The payload steals GitHub/npm tokens, SSH keys, .env files, shell history, GitHub Actions secrets, and cloud credentials. It does not target Bitwarden vault data directly.
  • This sits in the broader Checkmarx/TeamPCP supply-chain campaign that also hit Trivy, LiteLLM, and Checkmarx KICS across npm, PyPI, and Docker Hub.
  • If you installed the affected version during that window, assume all credentials accessible to that environment are compromised. Read Bitwarden's official statement.

Is the Bitwarden vault safe? Yes. The April 2026 CLI incident targeted developer environment credentials (SSH keys, GitHub tokens, cloud secrets), but Bitwarden's zero-knowledge AES-256 vault encryption remains unbreached. The malicious npm package @bitwarden/cli@2026.4.0 stole credentials stored outside the vault, not vault contents.

If you installed 2026.4.0

Bitwarden says the malicious package was on npm for about 90 minutes and has been removed. If you installed @bitwarden/cli@2026.4.0 during that window, rotate credentials now. Start with Bitwarden's official statement and SecurityWeek's write-up.

What happened

Security firm Socket reported that @bitwarden/cli@2026.4.0, Bitwarden's official command-line interface package on npm, was briefly replaced by a malicious build. Malicious code was published in a file called bw1.js included in the package contents.

Bitwarden's own statement describes a malicious package briefly distributed through the npm delivery path on April 22, 2026, for about 90 minutes (5:57 to 7:30 PM ET), in connection with the Checkmarx supply-chain incident. The compromised GitHub Action was checkmarx/ast-github-action, not a Bitwarden-owned Action. That Checkmarx campaign also hit Trivy, Checkmarx KICS, LiteLLM, and other developer tools.

According to JFrog's analysis reported by The Hacker News, the rogue version of the Bitwarden CLI package performed credential exfiltration on every system that installed it:

Is your Bitwarden vault safe?

Probably yes, but you need to understand the distinction.

Bitwarden's vault uses AES-256 encryption with a zero-knowledge architecture. Your master password decrypts your vault locally. Bitwarden's servers (and this compromised CLI package) never have access to your plaintext vault contents. The ETH Zurich research from February 2026 identified 12 theoretical attack vectors against Bitwarden's encryption, but none of them are relevant to this specific compromise.

This attack targeted the developer environment, not the vault. The malware harvested credentials that existed outside the vault: tokens in environment variables, SSH keys on disk, cloud credentials in config files. If you stored your Bitwarden master password or API key in a .env file or passed it as a shell argument (and many CI/CD scripts do exactly this), that specific credential is compromised and needs immediate rotation.

The distinction that matters: Bitwarden's vault encryption was not breached. A malicious CLI package reached npm through the Checkmarx Action used in the delivery path, and the malware targeted every other credential on the system except the vault contents. The vault is the one thing that was properly encrypted. Everything around it was not.

The bigger picture: TeamPCP's supply chain campaign

This is not an isolated incident against Bitwarden. TeamPCP has been running a multi-month, multi-ecosystem campaign that has hit some of the most trusted names in developer security tooling.

The timeline:

The pattern is consistent: TeamPCP targets CI/CD pipelines at security companies, injects credential stealers into trusted packages, then uses the stolen tokens to propagate to downstream dependencies. Each compromised package becomes a vector for further compromise. Stolen npm tokens let the attackers publish malicious versions of every package the victim maintains.

I wrote about a similar supply chain failure at Lovable earlier this week, where a BOLA vulnerability exposed 8 million users' source code and database credentials. The common thread: the tools developers trust with their credentials are becoming the primary attack vector for stealing them.

What to do right now: 5 steps

Step 1: Check if you installed the compromised version

Run this in your terminal:

npm ls @bitwarden/cli 2>/dev/null | grep "2026.4.0"

If it returns a match, you installed the compromised version. Also check your CI/CD pipeline configurations, GitHub Actions workflows, and any Docker images that include the Bitwarden CLI.

Step 2: Rotate all exposed credentials immediately

Assume everything accessible to the compromised environment has been exfiltrated:

Step 3: Change your Bitwarden master password

If you used the Bitwarden CLI in any automated script that passed your master password as an argument or environment variable, change your master password now. Use our password generator to create a new one: 20+ characters, fully random. Then store the recovery information in a separate, encrypted location.

If you only use the Bitwarden browser extension or desktop app (not the CLI), your master password was not exposed through this specific attack.

Step 4: Audit for unauthorized access

Step 5: Pin your dependencies

Stop installing packages by version range. Pin every dependency to an exact version and verify the integrity hash. For GitHub Actions, pin to specific commit SHAs instead of tags. Tags can be overwritten (as TeamPCP demonstrated with Trivy and Checkmarx). Commit SHAs cannot.

# Instead of this:
- uses: bitwarden/cli-action@v2

# Do this:
- uses: bitwarden/cli-action@a1b2c3d4e5f6  # pin to verified SHA

If you're reevaluating your password manager after this incident, our best password managers comparison covers security architecture and how the major options handle vault encryption.

Why supply chain attacks keep hitting password tools

Two public Bitwarden-related security stories landed in 2026, and they are not the same kind of event. In February, ETH Zurich research demonstrated 12 attacks against Bitwarden under a compromised-server model. In April, this npm delivery-path incident put a malicious CLI package on the public registry for about 90 minutes. LastPass had its own breach cascade in 2022-2023 that's still generating lawsuits and settlements. Dashlane patched downgrade vulnerabilities after the same ETH Zurich research.

Password managers are high-value targets precisely because they aggregate credentials. A successful attack on a password manager's distribution pipeline reaches millions of users who have concentrated their entire credential portfolio in one tool. The TeamPCP campaign specifically targets security tools because compromising a security tool gives attackers access to every secret that tool was designed to protect.

When I analyzed 50,000 breached passwords, the finding that mattered most was that 73% followed predictable patterns. Supply chain attacks bypass password strength entirely. It doesn't matter if your password is 32 random characters when the tool that manages it ships a credential stealer in its build pipeline.

The defense is layered: use a password manager (the vault encryption still works), but don't store credentials in plaintext .env files, don't pass secrets as shell arguments, pin your dependencies to verified commits, and treat every package update as a potential attack vector until proven otherwise.

Test any passwords you're concerned about with our password strength checker, and generate replacements with our password generator for anything that needs rotation after this incident.

Credential security after the Bitwarden CLI compromise

Your developer credentials need a vault that doesn't depend on a build pipeline

The Bitwarden CLI compromise exposed every credential on the system except the ones inside an encrypted vault. That's the argument for storing API keys, SSH passphrases, cloud tokens, and service credentials in a dedicated password manager, not in .env files, not in shell history, and not in CI/CD environment variables. NordPass offers zero-knowledge XChaCha20 encryption with no CLI package dependency in its consumer product.

Affiliate link. SPG earns a commission at no extra cost to you.

Try NordPass Free

Affiliate link. We earn a small commission if you upgrade, at no cost to you.

Technical indicators (IOCs)

If you're running incident response on this compromise, these are the indicators to check against your logs and environments:

Sources: Bitwarden statement on the Checkmarx supply-chain incident, SecurityWeek, Socket, The Hacker News (JFrog), Checkmarx KICS analysis.

TM
Tim O.

Tim O. is a DevSecOps engineer and the researcher behind the analysis of 50,000+ breached passwords. He writes about password security, credential management, and the intersection of AI and cybersecurity at SafePasswordGenerator.net.

Related reading