Bitwarden CLI supply chain attack exposed secrets through a poisoned npm release

A malicious npm release briefly compromised Bitwarden’s command-line client this week, but the incident was narrower than some early reports suggested. Bitwarden says the affected package was @bitwarden/[email protected], it was available through npm only between 5:57 p.m. and 7:30 p.m. ET on April 22, and there is no evidence that Bitwarden vault data, production systems, or the main Bitwarden codebase were compromised.

The bigger risk fell on developers and CI/CD systems that installed that package during the short exposure window. Socket says the release contained a malicious file named bw1.js and ties the compromise to the broader Checkmarx supply chain campaign, where attackers abused CI/CD paths and GitHub Actions to inject malware into trusted software releases.

BEST SPRING 2026 DEALS

Editor's Choice

Private Internet Access

Access content across the globe at the highest speed rate.

70% of our readers choose Private Internet Access

70% of our readers choose ExpressVPN

ExpressVPN

Browse the web from multiple devices with industry-standard security protocols.

Nord VPN

Faster dedicated servers for specific actions (currently at summer discounts)

Bitwarden has already deprecated the bad npm release and pushed users toward 2026.4.1. The company also says only users who installed the npm package during the affected window are impacted, which means regular Bitwarden users, browser extension users, and users who did not pull the CLI from npm in that period are not part of this incident.

What happened in the Bitwarden CLI compromise

Socket’s analysis says the attackers compromised @bitwarden/[email protected] by injecting malicious logic into the npm package contents. The payload harvested secrets from local machines and build environments, then attempted to spread further by targeting npm publish permissions and GitHub Actions workflows.

Public reporting from Endor Labs, SafeDep, and others points to a poisoned publish path tied to the same Checkmarx campaign. The suspected route was a compromised GitHub Action or related CI/CD workflow step, which let attackers tamper with the package before it reached npm rather than by modifying Bitwarden’s normal source repository in a visible way.

That distinction matters. Bitwarden says the issue affected the npm distribution mechanism for the CLI during that limited window, not the integrity of the legitimate Bitwarden CLI codebase or stored vault data.

Why the malware was so dangerous

Socket describes the malicious payload as one of the more capable npm supply chain implants seen recently. It reportedly targeted GitHub tokens, npm tokens, AWS credentials, Azure and GCP credentials, SSH keys, CI secrets, and developer configuration files, then exfiltrated the results through attacker-controlled infrastructure.

Researchers also say the malware tried to create public GitHub repositories under victim accounts, inject malicious workflow files, republish writable npm packages with new hooks, and establish persistence through shell profile changes. That means organizations that installed the package need to treat it as a full credential exposure event, not just a bad dependency update.

Bitwarden itself makes the same practical point in more cautious language. Its guidance tells affected users to rotate secrets, review GitHub activity and CI workflows, and perform cleanup steps immediately.

What is confirmed so far

The table above reflects Bitwarden’s official statement and public research published after the incident.

What affected users should do now

• Uninstall @bitwarden/[email protected] immediately if you installed it from npm during the affected window.
• Clear the npm cache and temporarily disable npm install scripts during cleanup. Bitwarden specifically recommends npm cache clean --force and npm config set ignore-scripts true.
• Rotate any secrets that may have touched the affected machine or build job, including GitHub tokens, npm tokens, cloud credentials, API keys, and SSH keys.
• Review GitHub repositories for unauthorized public repos, suspicious workflow files, unusual commits, and unexpected automation activity.
• Check shell startup files and build runners for persistence artifacts or signs of Bun-based execution.
• Upgrade to @bitwarden/[email protected] only after cleanup is complete.

Why this attack stands out

This case shows how supply chain attacks are moving away from obvious package typos and toward trusted release pipelines. Attackers no longer need to fool developers into installing a fake package name if they can poison a real package during the publish process.

It also shows how quickly a short-lived malicious release can become a serious enterprise event. Even a 93-minute window can expose developer workstations, CI/CD jobs, cloud accounts, and downstream packages if automated installs or privileged tokens are in place.

For Bitwarden, the good news is that the company says the damage did not reach its vault infrastructure or general user base. For engineering teams, the warning is clear: any trusted package in a build pipeline can become a delivery vehicle if release automation is not locked down tightly enough.

FAQ