Home
AI
Blog

Bitwarden CLI Got Hacked: What the Supply Chain Attack Means for You

basanta sapkota
93 minutes. That's all it took.

On April 22, 2026, somebody slipped a malicious version of the Bitwarden CLI onto npm. Between 5:57 PM and 7:30 PM ET, anyone who ran npm install picked up a package that quietly vacuumed up their GitHub tokens, SSH keys, cloud credentials, and shell history. All of it got shipped off to an attacker-controlled server before most people even realized something was wrong. 334 users downloaded it before Bitwarden yanked it.

Now, if you self-host Vaultwarden or lean on the Bitwarden CLI for your workflows, pay attention. Not because your vault passwords got stolen. They didn't. The attack went after something arguably scarier: every secret around your vault. Your CI/CD tokens. Those .env files you probably forgot about. Private SSH keys just sitting on disk. The stuff most of us never bother to encrypt because we figure... Who's going to get to those?

Turns out, somebody did.

Key Takeaways

  • Bitwarden CLI version 2026.4.0 got compromised through a supply chain attack on its npm distribution pipeline. April 22, 2026, between 5:57 PM and 7:30 PM ET.
  • Your vault data is safe. Bitwarden's zero-knowledge AES-256 encryption held. The malware went after developer environment credentials, not vault contents.
  • 334 users grabbed the bad package. If you were one of them, assume every credential on system is burned.
  • This is part of a broader campaign by a threat actor called TeamPCP who already hit Trivy, Checkmarx KICS, and LiteLLM.
  • You need to act now if affected. Check your installed version, rotate exposed secrets, audit your GitHub account for weird activity.
  • Vaultwarden users who don't touch the official Bitwarden CLI npm package? Not directly affected. But don't get comfortable. This is a loud wake-up call about supply chain security.

What Actually Happened

Short version. Attackers broke into a GitHub Action in Bitwarden's CI/CD pipeline. They used that foothold to push a rogue version of @bitwarden/cli to npm. Version 2026.4.0. Inside was a nasty little file called bw1.js rigged to run through a preinstall hook.

You didn't even have to use the CLI. The second npm install ran, the malware was already doing its thing. [JFrog's analysis, covered by The Hacker News], breaks down what the credential stealer grabbed:

  • GitHub and npm authentication tokens
  • Your .ssh directory. Yeah, your private keys
  • .env files full of API keys, database passwords, service tokens
  • Shell history, which means every command you've ever typed, including any credentials you passed as arguments like we all know we shouldn't but sometimes do anyway
  • GitHub Actions secrets and cloud provider credentials across AWS, Azure, and GCP
  • Config files for AI coding tools like Claude, Cursor, Codex CLI, and Aider

All that stolen data got encrypted with AES-256-GCM and sent to audit.checkmarx[.]cx. A domain designed to look like it belonged to the legitimate security company Checkmarx. Clever, right? And as a backup exfiltration method, the malware committed stolen data to GitHub repos created under the victim's own account, using Dune-themed naming patterns like word-word-3digits.

Here's where it gets really ugly. If the malware found GitHub tokens, it used them to inject malicious GitHub Actions workflows into the victim's repositories. One infected developer machine could cascade into a compromise across every single project those tokens had access to. Think about for a second.

Bitwarden moved fast. They revoked the compromised access, deprecated the malicious npm release, and confirmed no production systems or customer vault data were touched. A CVE is being issued. Their [official statement on the community forums] has the full rundown.

One thing worth calling out. Bitwarden never actually released version 2026.4.0. Their latest legitimate CLI version before all this was 2026.3.0. The attackers published 2026.4.0 directly through the hijacked pipeline, completely bypassing normal release processes.

![Diagram showing the Bitwarden CLI supply chain attack flow from compromised GitHub Action to malicious npm package to credential theft]

TeamPCP's Bigger Campaign

This wasn't a one-off. The Bitwarden CLI compromise is just the latest punch in a multi-month campaign by a threat actor known as TeamPCP. And their playbook is consistent. Honestly kind of elegant, in a deeply unsettling way. Compromise CI/CD pipelines at trusted projects. Inject credential stealers into published packages. Use the stolen tokens to spread further.

The timeline tells the story:

  1. February 2026. TeamPCP's hackerbot-claw account starts scanning GitHub for exploitable CI/CD workflows.
  2. March 19. Trivy, Aqua Security's vulnerability scanner, gets popped. All 76 trivy-action tags hijacked.
  3. March 23. Checkmarx KICS GitHub Action compromised. Every single one of its 35 tags overwritten.
  4. March 24. LiteLLM, a popular LLM proxy library, gets hit on PyPI. Malicious versions 1.82.7 and 1.82.8 pushed out.
  5. April 21: Malicious pgserve packages show up on npm with a self-propagating worm bounces between npm and PyPI.
  6. April 22: Bitwarden CLI. Same GitHub Actions vector.

The string "Shai-Hulud: The Third Coming" turned up in the malicious Bitwarden package, tying it back to the same campaign. And here's a curious detail: the malware quits execution on systems where the locale corresponds to Russia.

If you've been following the recent [Axios npm supply chain attack], you're probably seeing the pattern. Npm's publishing infrastructure remains a massively high-value target. The publish step is where everything falls apart for most open-source projects.

Are Vaultwarden Users Affected?

I know this is what a lot of self-hosters want answered. So here it is.

Vaultwarden itself was not compromised. Full stop. Vaultwarden is a separate, community-developed server implementation written in Rust. It doesn't touch npm.Still doesn't depend on any of Bitwarden's npm packages. Completely independent codebase.

But. If you use the official Bitwarden CLI tool alongside your Vaultwarden instance for automated backups, scripting, managing your vault from the terminal, whatever, and you happened to install it via npm during that 93-minute window? Then your environment credentials are at risk.

Installed through other channels? The standalone binary download, snap, your distro's package manager? You're fine. Only the npm distribution path was affected.

How to Check If You're Affected

Run this:

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

If it spits back a match, you installed the bad version. Also check your CI/CD pipeline configs and any Docker images bundling the Bitwarden CLI.

No output? Probably clear. But if you want to be really thorough:

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

What to Do Right Now If You're Affected

Don't sit on this. Seriously.

1. Nuke the compromised package and clean your cache

npm uninstall -g @bitwarden/cli
npm cache clean --force
npm config set ignore-scripts true  
# temporarily disable install scripts

2. Rotate every single credential that machine could access

This is the part nobody wants to do. But you have to. Assume everything is burned:

  • GitHub tokens. Revoke and regenerate at github.com/settings/tokens
  • npm tokens. Revoke at npmjs.com/settings/tokens. Then go check nobody published anything under your account you didn't put there
  • SSH keys. Generate fresh key pairs. Update them everywhere. Yes, everywhere
  • Cloud credentials. Rotate AWS access keys, Azure service principals, GCP service account keys
  • .env secrets: Every API key, every database password, every service token. All of them
  • Bitwarden API key: If it was sitting in an environment variable, rotate it now

3. Audit your GitHub for unauthorized changes

Look for repositories you didn't create. TeamPCP makes repos with a word-word-3digits naming pattern and sticks "Checkmarx Configuration Storage" in the README. Go through your GitHub Actions workflow run history too. Look for unexpected workflow files or artifacts that shouldn't be there.

4. Change your Bitwarden master password

If your master password was ever passed as a CLI argument or stored in an environment variable, and let's be honest, automation scripts do this all the time, change it. If you only ever use the browser extension or desktop app, your master password wasn't exposed through this attack.

5. Install the fixed version

npm install -g @bitwarden/cli@2026.4.1

Protecting Yourself Going Forward

This attack pattern isn't slowing down. If anything it's picking up speed. Here's what actually helps:

Pin your dependencies. Stop using latest or loose version ranges. Lock to specific, verified versions. I know it's annoying. Do it anyway.

Set a minimum release age. Tools like npm, pnpm, and yarn support this. A 24-48 hour delay on new releases gives people time to catch malicious packages before they hit your build.

Use lockfiles and verify checksums. Always commit your package-lock.json. Verify integrity hashes.

Audit your CI/CD pipeline permissions. Least-privilege access. Rotate tokens frequently. Require multiple approvers for publish environments. Treat your publish pipeline like the keys to the kingdom, because it is.

Monitor for unexpected package changes. Tools like [Socket] scan for suspicious behavior in dependencies.

For Vaultwarden users specifically, just download the Bitwarden CLI as a standalone binary instead of pulling it through npm. That removes this entire attack surface from your workflow. You might also want to check out our post about [detecting npm supply chain attacks] for more hardening ideas.

The Real Lesson

A security researcher said something about this incident that I can't stop thinking about. "The publish step is the weakest link." And they're absolutely right. Code review, branch protection, signed commits? None of it matters if an attacker can just hijack the automated release process and skip past all of it.

Credit where it's due. Bitwarden's response was solid. Detection in under two hours, immediate containment, transparent communication. Only 334 downloads got through. That's about as clean as incident response gets. But the fact this happened at all, to a security-focused company, tells you something uncomfortable about where software supply chain security stands in 2026.

Your vault is safe.So passwords are fine. But the infrastructure you use to manage, deploy, and automate around those passwords? That's the target now. And it deserves the same level of protection you give the vault itself.

Check your systems. Rotate your secrets if you need to. And for the love of everything... Pin your dependencies.

Sources

  1. The Hacker News — Bitwarden CLI Compromised in Ongoing Checkmarx Supply Chain Campaign
  2. Bitwarden Community Forums — Bitwarden Statement on Checkmarx Supply Chain Incident
  3. Purple Shield Security — Bitwarden CLI Compromised in Supply Chain Attack. Business Risks
  4. Safe Password Generator — Bitwarden CLI Compromised. 5 Steps to Secure Your Vault
  5. OX Security — Shai-Hulud. Bitwarden CLI Supply Chain Attack Analysis
  6. Hacker News Discussion — Bitwarden CLI Compromised Thread
  7. Arctic Wolf — TeamPCP Supply Chain Attack Campaign Targets Trivy, Checkmarx KICS, and LiteLLM
  8. Reddit r/selfhosted — Bitwarden CLI Has Been Compromised Discussion

Post a Comment