What Actually Happened to @bitwarden/[email protected]

The Bitwarden CLI was compromised as part of a newly discovered, ongoing supply chain campaign linked to Checkmarx, according to findings from JFrog and Socket. The affected package version was @bitwarden/[email protected], and the malicious code was embedded in a file called bw1.js, which was included in the package contents.

Here's where it gets really unsettling: the attack appears to have leveraged a compromised GitHub Action inside Bitwarden's CI/CD pipeline — consistent with the same pattern seen across other affected repositories in this broader campaign.

So this wasn't some random rogue actor slipping code into a fringe package. This was a trusted, widely-used password management tool's CLI getting poisoned through its own build pipeline.

How the Malicious Code Actually Worked

The malicious code was executed via a preinstall hook, resulting in the theft of local, CI, GitHub, and cloud secrets. Exfiltrated data was sent to the domain "audit.checkmarx[.]cx" — a domain impersonating Checkmarx — and to a GitHub repository as a fallback if the primary method failed.

Think of it like this: the moment a developer ran npm install, the damage was already done — before the package even finished installing. Here's the full chain of what the malware did:

  • It launched a credential stealer targeting developer secrets, GitHub Actions environments, and AI coding tool configurations — including Claude, Kiro, Cursor, Codex CLI, and Aider.
  • Stolen data was encrypted with AES-256-GCM before being exfiltrated to the impersonating Checkmarx domain.
  • If GitHub tokens were found, the malware used them to inject malicious Actions workflows into repositories and extract CI/CD secrets from those pipelines too.

That last part is what makes this so dangerous. It's not just "your machine is compromised." It's "every repository your token can touch is now potentially compromised."

The Ripple Effect: One Developer, Countless Pipelines

StepSecurity put it plainly: a single developer with @bitwarden/[email protected] installed could become the entry point for a broader supply chain compromise, with the attacker gaining persistent workflow injection access to every CI/CD pipeline that developer's token could reach.

That's the nightmare scenario. And honestly, it's one that a lot of teams don't think about until it's too late. Your pipeline trust model assumes that the packages feeding into it are clean. When they're not, the blast radius is enormous.

NPM Trusted Publishing Compromised for the First Time

Security researcher Adnan Khan identified the malicious workflow used to publish the rogue Bitwarden CLI and noted that this appears to be the first time a package using NPM trusted publishing has been compromised.

That's a milestone nobody wanted. NPM trusted publishing was meant to be a stronger, safer distribution mechanism. Its compromise here signals that even hardened supply chain controls aren't immune when upstream GitHub Actions are themselves the attack vector.

The "Shai-Hulud: Third Coming" Signature

OX Security identified the string "Shai-Hulud: The Third Coming" embedded in the package, suggesting this could be the next phase of a supply chain attack campaign that first came to light the previous year.

OX Security's Security Research Team Lead observed that user data is being publicly exfiltrated to GitHub, often going undetected because security tools typically don't flag outbound data being sent there. This makes the risk significantly more dangerous — anyone searching GitHub can potentially find and access those credentials, meaning sensitive data is no longer in the hands of a single threat actor but exposed to anyone.

And just like in the previous Checkmarx incident, the stolen data was exfiltrated to public repositories created under victim accounts, using a Dune-themed naming scheme in the same format: --<3 digits>. There's also an interesting operational note: the malware was designed to quit execution on systems whose locale corresponded to Russia.

Who's Behind It and How Attribution Gets Complicated

The threat actor known as TeamPCP is suspected to be behind the latest attack. As of the time of writing, TeamPCP's X account had been suspended for violating the platform's rules.

Socket noted that shared tooling strongly suggests a connection to the same malware ecosystem, but operational signatures differ in ways that complicate attribution — pointing to either a different operator using shared infrastructure, a splinter group with stronger ideological motivations, or an evolution in the campaign's public posture.

Bitwarden's Official Response

Bitwarden confirmed the incident and clarified that it stemmed from the compromise of its npm distribution mechanism following the Checkmarx supply chain attack, but emphasized that no end-user vault data was accessed.

Bitwarden's statement confirmed that the malicious package was distributed through the npm delivery path for @bitwarden/[email protected] only during a window between 5:57 PM and 7:30 PM ET on April 22, 2026. The investigation found no evidence that end-user vault data was accessed or at risk, and no production data or production systems were compromised. Once detected, compromised access was revoked, the malicious npm release was deprecated, and remediation steps were initiated immediately.

The issue affected only the npm distribution mechanism during that limited window — not the integrity of the legitimate Bitwarden CLI codebase or stored vault data. Users who did not download the package from npm during that window were not affected. A CVE for Bitwarden CLI version 2026.4.0 is being issued in connection with the incident.