Inside the Bitwarden CLI Supply Chain Attack: 90 Minutes That Compromised Developer Secrets

April 22, 2026. A developer somewhere kicks off a CI job that begins, like thousands of others that day, with npm install -g @bitwarden/cli. The job pulls down version 2026.4.0, the package the team has been using for months. The build proceeds. Tests pass. The pipeline finishes green.

What the developer does not know — what nobody outside Bitwarden's incident response team knows yet — is that the package they just installed has been silently exfiltrating every cloud token, SSH key, and AI tooling configuration on the runner to a public GitHub repository.

This is the third incident in the Shai-Hulud supply chain campaign, and it is, in many ways, the most instructive one we have seen this year. Not because the technique is novel — it is not — but because the victim is a security-conscious vendor with strong engineering practices, and it still happened. And because everything the worm targeted on those CI runners is exactly the type of identity Cremit refers to as a Non-Human Identity (NHI).

This post breaks down what happened, maps the attack to the NHI Kill Chain we have been writing about all month, and gives you a checklist you can run in the next ten minutes to know whether you were affected.

What Happened, Timed to the Minute

The compromised package — @bitwarden/cli@2026.4.0 — was live on the public npm registry for roughly 90 minutes. According to Bitwarden's official statement, the malicious build was published at 5:57 PM ET on April 22, 2026 and removed by 7:30 PM ET the same evening.

In that window, the package was downloaded into an unknown number of CI pipelines, developer laptops, and container builds. The npm registry reports @bitwarden/cli averages roughly 250,000 downloads per month — installs are concentrated during business hours, which is exactly when the malicious version was live.

Bitwarden's investigation found no evidence that vault data, production systems, or end-user credentials were accessed. The compromise was confined to the npm distribution path. That distinction matters: the password manager itself was not breached. The build pipeline that ships the password manager's CLI was.

The Attack Chain, Decomposed

The technique is straightforward, which is part of what makes it dangerous. Each individual step is something a mature engineering organization is supposed to defend against, and each step succeeded anyway.

Stage 1 — Initial access via Checkmarx. The Shai-Hulud campaign's third wave initially propagated through a compromised Checkmarx-related developer tool. Once installed in a developer or CI environment, the tool harvested credentials — including, in some cases, the npm publish tokens used by package maintainers.

Stage 2 — GitHub Actions workflow compromise. With access to a maintainer's tokens, the attackers were able to inject a malicious workflow step into Bitwarden's release automation. This is the leverage point: control of a single GitHub Actions runner with publish-scoped credentials is enough to ship a backdoored package to every consumer of that package globally.

Stage 3 — Malicious npm publish. The attackers built and published @bitwarden/cli@2026.4.0 containing a credential-stealing payload, then waited for the registry to do what registries do — fan it out to every CI system on Earth that does not pin versions.

Stage 4 — The worm propagates. The payload contained three collectors targeting:

• Cloud provider tokens — Azure, AWS, GCP service principals and access keys
• Developer platform tokens — GitHub PATs, npm publish tokens
• Host secrets — SSH keys, shell history, environment variables
• AI tooling configuration — MCP server configs, AI agent credentials

Collected secrets were exfiltrated to public GitHub repositories — a deliberate choice that gives the campaign self-propagation. Any developer or scanner that picks up those repos and re-uses the leaked tokens potentially extends the campaign one more hop.

The NHI Kill Chain View

Three of the kill chain stages we have been documenting this month line up precisely with what made this incident possible. None of them are about a vulnerability in cryptography or a zero-day in a runtime — they are about how organizations operate identities over time.

Ghost Key. The npm publish token used to ship @bitwarden/cli is a Non-Human Identity. Like every NHI, it has no face attached to it — no Slack handle to ping when something looks off, no laptop to wipe when its owner leaves. When that token was used by the attacker, the publish event from a different runner in a different timeframe almost certainly looked statistically similar to a legitimate release. (Read more about Ghost Keys.)

Drifted Key. Publish tokens accumulate scope and reach over time. A token that was originally minted to ship a single internal tool ends up publishing to a top-level public scope years later, often without anyone reviewing whether the original constraints still hold. The further a key drifts from its original purpose, the larger the blast radius when it is finally captured. (Read more about Drifted Keys.)

Unattributed Key. The worm's payload exfiltrated cloud tokens from CI runners. In most organizations, those tokens are not mapped to a specific workload, service owner, or rotation policy. When the leak is detected, the rotation playbook becomes archaeology — you have to figure out what the token does before you can safely revoke it. That delay is the campaign's oxygen.

The point of the kill chain framing is not to assign blame. It is to show that the same identity-management gaps that get exploited in slow, opportunistic attacks are also the gaps that get exploited in 90-minute supply chain bursts. They are the same problem.

MITRE ATT&CK Mapping

The Question This Incident Forces

The cleanest framing of the post-incident discourse has been some version of: "Bitwarden vaults are safe; users do not need to take action." That framing is technically accurate and, I think, dangerously incomplete.

Most of the secrets that were exfiltrated by the worm never lived in a Bitwarden vault to begin with. They lived on CI runners as environment variables. They lived in ~/.aws/credentials files on developer laptops. They lived in the metadata of GitHub Actions workflows. The NHIs that operate your software supply chain do not live in your password manager, and "the password manager is fine" is not the same statement as "your software supply chain is fine."

This is the structural lesson of the Shai-Hulud campaign across all three waves: the attack surface is not where the value is stored. It is where the value moves.

What to Check in the Next Ten Minutes

The window of compromise is well-defined, which makes the immediate response much more tractable than for most supply chain attacks. Run through this list:

1. Did anything install `@bitwarden/cli` between 5:57 PM and 7:30 PM ET on April 22, 2026?

# Check CI logs for installs in the affected window
grep -r "@bitwarden/cli" /var/log/ci/  # adjust path to your CI log root

# On individual machines, check npm install timestamps
npm list -g @bitwarden/cli --json

2. Are you pinning `@bitwarden/cli` in lockfiles? If yes, you are likely safe — your lockfile rejected the malicious version unless you ran npm update during the window. If no, treat any install during the window as compromised.

3. If you were affected, rotate everything in the worm's collection scope. Specifically:

• All AWS access keys present on the affected runner
• All Azure service principal credentials
• All GCP service account keys
• All GitHub PATs (especially fine-grained tokens with packages:write)
• All npm publish tokens
• SSH keys present in ~/.ssh/
• Any AI tooling credentials (Anthropic, OpenAI, MCP server tokens)

4. Audit your public GitHub footprint for newly-pushed repositories containing structured credential dumps. The worm exfiltrates to public repos — search GitHub for repository names matching the campaign's exfiltration patterns and confirm none originate from your accounts.

5. Going forward: pin npm dependencies and verify provenance. npm provides provenance attestations for packages built in compliant CI. @bitwarden/cli@2026.4.0 did not have a valid provenance attestation; future malicious builds in the same shape will not either.

How Cremit Argus Fits

Cremit's Argus platform indexes the public-facing surface of the developer ecosystem — public GitHub, public package registries, paste sites — looking for secrets that match the patterns and attribution metadata of the customers it protects. The Shai-Hulud campaign's exfiltration choice (public GitHub repositories) is exactly the surface Argus monitors.

The detection arrives, in the best case, before the attacker has had time to use the credentials. In the worst case, it gives you the rotation list you would otherwise have to derive from logs after the fact.

If your organization ships software through any public package registry, see how Argus surfaces credential leaks before they propagate further down the chain.

Related reading

• The NHI Kill Chain — Public Key — the series introduction
• Ghost Keys — NHIs without owners
• Drifted Keys — keys that outgrow their original scope
• Aged Keys — keys that should have been rotated and were not

Sources: [Bitwarden community statement](https://community.bitwarden.com/t/bitwarden-statement-on-checkmarx-supply-chain-incident/96127), [The Hacker News reporting](https://thehackernews.com/2026/04/bitwarden-cli-compromised-in-ongoing.html), [BleepingComputer technical breakdown](https://www.bleepingcomputer.com/news/security/bitwarden-cli-npm-package-compromised-to-steal-developer-credentials/), [OX Security analysis of Shai-Hulud](https://www.ox.security/blog/shai-hulud-bitwarden-cli-supply-chain-attack/), [SecurityWeek coverage](https://www.securityweek.com/bitwarden-npm-package-hit-in-supply-chain-attack/).