All posts
Security Supply Chain April 2026 by Hany Fahim

The Bitwarden CLI Compromise: When the Lock Becomes the Vector

On April 22, 2026, a malicious version of @bitwarden/cli was live on npm for 93 minutes before it was pulled. It was part of a supply chain campaign that has been quietly escalating since 2025 — and this time, it targeted the tool built specifically to protect your credentials.

93 min
Window before takedown
3rd wave
Shai-Hulud campaign
0
End-user vault records exposed

We wrote about the Trivy supply chain attack last month. Between March 19 and 23, 2026, attackers compromised Aqua Security’s CI/CD pipeline and delivered backdoored container images to developers for four days.

That wasn’t the end of the campaign.

On April 22, 2026, at 5:57 PM ET, a malicious version of @bitwarden/cli landed on npm — version 2026.4.0, published under the official @bitwarden namespace, indistinguishable from any legitimate release. It was live for 93 minutes before it was pulled. According to Bitwarden’s community forum, several hundred developers downloaded it during that window.

Those downloads are not the full story.

What actually happened

The attackers didn’t guess anyone’s password. BleepingComputer reports that the attackers “appear to have used a compromised GitHub Action in Bitwarden’s CI/CD pipeline to inject malicious code into the CLI npm package.” Bitwarden told BleepingComputer the incident was “linked to the Checkmarx supply chain attack, with a compromised Checkmarx-related development tool enabling abuse of the npm delivery path.”

Bitwarden was clear in their disclosure: no end-user vault data was accessed, no production systems were compromised. The attack was narrow and targeted. It was aimed at developers, not at the millions of people using Bitwarden to store their personal passwords.

That narrowness is part of what makes it interesting.

What the worm collected

The malicious package arrived in two stages. A preinstall hook fired automatically — no user interaction required — downloading the Bun JavaScript runtime, which then executed a 10 MB obfuscated second-stage payload. The campaign used “Shai-Hulud: The Third Coming” as the description string in the public GitHub repositories it created to exfiltrate stolen data — a reference to the sandworms of Frank Herbert’s Dune and an explicit callback to two prior campaigns that used the same naming convention.

The credential harvest was extensive. Aikido’s analysis lists: npm tokens, SSH keys, environment variables and shell history, AWS and GCP credentials, and cloud secrets from AWS SSM Parameter Store, AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager. BleepingComputer additionally lists GitHub authentication tokens among the credential types stolen in this attack. For any developer running the Bitwarden CLI in a CI/CD pipeline — which is an entirely normal, sensible thing to do — that environment almost certainly held many of the above.

But the attack didn’t stop at collection.

Stolen tokens were exfiltrated by creating public GitHub repositories under the victims’ own accounts, named with randomized Dune vocabulary — Aikido gives examples like fremen-sandworm-441 and harkonnen-melange-7. Other infected machines could then discover and reuse those tokens. If a stolen npm token had publish rights, it could be used to push further compromised versions to that developer’s own packages — extending the campaign to everyone downstream who installed those packages.

This is a worm in the original sense. It propagates.

The irony is the point

A password manager’s CLI tool briefly became a credential thief. I want to sit with that for a moment, because it says something important about how we think about supply chain risk.

We talk a lot about securing the software we write and the services we run. We think less carefully about the security tools themselves — the scanners, the secret managers, the CI/CD integrations. These tools run with elevated privileges. They see credentials other services don’t. They’re trusted by default because their whole purpose is to make us more secure.

That trust is exactly the attack surface.

In March 2026, attackers attributed to a group called TeamPCP hit Trivy, Checkmarx’s GitHub Actions, and LiteLLM in a similar CI/CD compromise pattern. The April Bitwarden attack uses the same C2 infrastructure (audit.checkmarx[.]cx/v1/telemetry) and the same malware patterns. Socket Research Team writes that “the shared tooling strongly suggests a connection to the same malware ecosystem, but the operational signatures differ in ways that complicate attribution” — the possibilities being the same operators, a splinter group, or a separate actor on shared infrastructure. What isn’t in dispute is the target selection: each victim sits deep in developer pipelines, runs with elevated trust, and is rarely scrutinized.

Why the download count understates it

The headline number counts direct installs of @bitwarden/cli@2026.4.0 during the 93-minute window. It doesn’t count:

  • CI/CD pipeline runs that installed the package as part of an automated build
  • Downstream installs of packages subsequently published with stolen npm tokens
  • Systems where the worm’s self-propagating dead-drop mechanism spread credentials further

A single infected CI/CD environment can hold tokens for your entire infrastructure. An npm token with publish rights can propagate the worm to your own packages and their users. The initial infection count is a floor, not a ceiling.

The campaign history

The “Third Coming” label points to a history worth understanding.

September 2025 (original wave): A CISA advisory and Unit 42 analysis documented the original Shai-Hulud campaign: hundreds of npm packages compromised, credentials harvested via post-install hooks and exfiltrated to public GitHub repositories.

November 2025 (“Second Coming”): The scope expanded dramatically — approximately 800 packages and over 25,000 GitHub repositories. The campaign hit packages from Zapier, ENS Domains, PostHog, and Postman. The attackers labeled this wave “Sha1-Hulud: The Second Coming” in the description of the repositories used for exfiltration. A new capability emerged: pre-install execution rather than post-install, which fires during package installation without any user action. Wiz noted that this wave “may involve different threat actors” using the same tooling and naming convention.

April 2026 (“Third Coming”): Narrower targeting, higher value. Rather than compromising many packages broadly, this wave targeted specific security and developer tools that run with elevated privilege in CI/CD pipelines. The exfiltration repos carried the description “Shai-Hulud: The Third Coming.”

The direction across waves, regardless of who’s running them at any given point, is toward higher-privilege targets with smaller blast radii that stay under the radar longer.

What you can actually do

The honest version of this section is that none of these recommendations would have stopped every developer who downloaded @bitwarden/cli@2026.4.0 in that 93-minute window. Someone compromised the CI/CD pipeline of a security-focused company. That is a hard problem. But there are practices that reduce your exposure.

Enforce a minimum package release age. npm, pnpm, yarn, and bun all support mechanisms to require that a package version be a certain number of days old before your build system installs it. A seven-day cooldown would have protected everyone who didn’t update in the first 93 minutes — which is most teams in most pipelines. The trade-off is that you don’t get same-day patch installs, but for tools like Bitwarden CLI the version you’re running today was probably installed weeks ago anyway.

Pin dependencies and use lock files. A lock file won’t prevent a compromised version from being published, but it makes unauthorized changes visible. An unexpected change to your lock file in a PR is worth investigating.

Audit the tools in your pipeline for the access they hold. Which tools in your CI/CD have npm publish rights? Which have credentials that reach production? What is the blast radius if any one of them is compromised? This is less about finding problems and more about knowing what’s there. You can’t scope down access you haven’t mapped.

Use short-lived credentials where you can. Long-lived npm tokens that accumulate in pipeline environments are what make worm propagation valuable. Tokens that expire frequently narrow the window in which stolen credentials remain useful.

Rotate credentials if you installed the affected version. If you installed @bitwarden/cli@2026.4.0 between 5:57 and 7:30 PM ET on April 22, 2026, treat every credential present in that environment as potentially exposed — npm tokens, GitHub tokens, SSH keys, and cloud credentials.

We’ll add the caveat we always add: none of this is a guarantee. If you’re the kind of team that already runs Bitwarden CLI in your CI/CD, you’re already thinking carefully about security. And you still would have been affected. That’s the nature of supply chain attacks. The question isn’t whether you can make yourself immune — you can’t — it’s whether you can make a compromise visible faster and limit what an attacker can do with what they find.

The Bitwarden vault itself was not compromised in this incident. If you use Bitwarden as a password manager for personal or business credentials, your data was not at risk. This post concerns only developers who used the CLI tool in CI/CD pipelines.

We’ve been writing about this campaign because we use these tools too, and we don’t think the right response is to pretend otherwise. If you’re working through your own threat model or want to compare notes on what we’ve learned, we’re easy to reach.

Sources: