Bitwarden CLI Incident: Is Your Password Manager Still Safe?

When a password manager hits the headlines, the first instinct is usually to ask whether to switch. With the Bitwarden CLI incident of 22 April 2026, the details matter, because the impact was narrower than the early coverage suggested. The incident affected developers who installed a specific command-line tool through npm within a short window. The encrypted vaults that hold the passwords were untouched, so switching providers is unnecessary for almost every Bitwarden user. If you use the Bitwarden CLI in a build pipeline and pulled the affected version, however, you do need to act.

What happened on 22 April 2026?

Between 23:57 and 01:30 CEST, a tampered version of @bitwarden/cli carrying version number 2026.4.0 was published through the official npm channel. The trigger was a compromised GitHub Action from the Checkmarx ecosystem that Bitwarden uses in its own build workflow. Checkmarx itself was a victim of the broader campaign. An embedded payload (bw1.js) was bundled into the tampered version and ran automatically during npm install. It downloaded a Bun interpreter and used it to execute an obfuscated JavaScript file that systematically harvested secrets from the developer’s environment.

Bitwarden confirmed the incident in an official statement. The affected package was pulled within hours and replaced with version 2026.4.1. BleepingComputer and Endor Labs have reconstructed the technical sequence.

Who is affected and who isn’t?

The directly affected group is small. It comes down to people who ran npm install -g @bitwarden/cli and pulled version 2026.4.0 inside the roughly 90-minute window. According to Bitwarden’s own analysis, the package was downloaded around 334 times during that window.

The Bitwarden browser extension, mobile apps, and desktop clients are not affected, because they are not distributed through npm. Self-hosted Bitwarden servers are likewise unaffected, unless they happen to pull the Bitwarden CLI through the same build pipeline. The Web Vault and Bitwarden’s cloud infrastructure were not targeted, according to the vendor. Anyone who installed the CLI before 22 April and didn’t update during the window is also in the clear.

What wasn’t compromised?

According to Bitwarden’s official statement, the investigation found no evidence of access to vault data or production systems. Master passwords, stored logins, notes, attachments, and TOTP seeds inside Bitwarden vaults remain unchanged and accessible. The zero-knowledge architecture was not breached, and the Bitwarden cloud’s authentication servers were not part of the attack.

The separation between tool and vault is the central point when assessing this incident. The Bitwarden CLI is an application developers use in build pipelines, server provisioning, and scripts to retrieve secrets from their own vault or to automate audit tasks. The fact that this application was tampered with for a short window says little about the security of the vault that holds the actual passwords.

Which secrets should you rotate?

If you installed @bitwarden/[email protected] through npm during that window, treat anything the malware could reach in your developer environment as compromised. Endor Labs and Palo Alto Unit 42 have reconstructed the targets. The malware harvested npm publish tokens, GitHub Personal Access Tokens and CI secrets, SSH keys from the default directory, cloud credentials for AWS, Azure, and GCP from environment variables, configuration files for AI tools, and shell history contents.

The remediation steps follow from there.

• Upgrade the CLI to 2026.4.1. Run npm uninstall -g @bitwarden/cli followed by npm install -g @bitwarden/[email protected] to swap the tampered version for the re-release.
• Clear the npm cache with npm cache clean --force so the tampered package can’t reappear from a local cache.
• Rotate every secret that was stored on or reachable from the affected system. That includes npm tokens, GitHub Personal Access Tokens, cloud credentials for AWS, Azure, and GCP, and SSH keys.
• Audit GitHub activity, CI workflows, and connected logins for unauthorized access or changes since 22 April.
• Temporarily disable npm install scripts with npm install --ignore-scripts during the cleanup phase to prevent reinfection.

Bitwarden explicitly recommends these steps in its own statement. If you don’t run the Bitwarden CLI, or if you installed it outside the attack window, you can skip this section.

How does the incident fit into the Shai-Hulud wave?

The Bitwarden CLI incident isn’t an isolated event. It belongs to a broader wave of supply chain attacks on the npm ecosystem tracked under the name Shai-Hulud. The pattern is similar each time. Attackers compromise either a developer account or a build step of a downstream tool (here, the GitHub Action checkmarx/ast-github-action), inject malicious code into the normal release flow, and let the package ship through official channels. Palo Alto Unit 42 has been tracking this wave with rolling updates since early 2026.

There is a lesson here for anyone who consumes software from package repositories. Trust in npm, PyPI, Maven Central, or Cargo doesn’t rest only on the repository itself, but on every link in the package’s supply chain. A tampered third-party GitHub Action can be enough to poison a trusted release. This form of supply chain attack isn’t new (SolarWinds 2020, xz-utils 2024), but the frequency is rising, and increasingly the targets are security tools themselves. The irony is hard to miss.

Should you switch from Bitwarden?

The short answer is no, certainly not because of this incident. Bitwarden runs a bug bounty program and publishes audit reports. The server code and clients are open source, which speeds up the response to incidents like this. The 22 April attack hit a third-party build tool inside the publishing pipeline, not the vault and not Bitwarden’s own infrastructure. 1Password, NordPass, and Proton Pass would face a comparable risk in the same constellation.

The takeaway is structural rather than vendor-specific. Anyone deploying Bitwarden inside an SME with its own infrastructure has the self-hosting option, which keeps the vault and the admin interface entirely inside the company’s own Swiss environment. That path is covered in detail in the password manager comparison for SMEs in Switzerland. Self-hosting shifts patch and backup responsibility onto your own IT team, but it also removes third-party pipelines from the trust path.

What does the incident mean for SMEs in Switzerland?

For most SMEs, the incident is a reason to take stock rather than to migrate. Three questions are worth working through.

• Check whether your development or DevOps team uses the Bitwarden CLI in build pipelines. If so, audit the installed versions on build servers, in CI container images, and on individual workstations.
• Inventory the npm tools in your build pipeline. Which third-party Actions, which packages with preinstall scripts, and which global npm installs are actually running? npm ls -g --depth=0 on every build machine is a starting point.
• Define a runbook for incidents like this one. Decide in advance who notifies the team, who rotates which secrets, and who audits GitHub activity. A half-page document costs little to write and pays for itself when something happens.

From a regulatory standpoint, the incident is also a chance to review the nDSG reporting obligation. If you processed personal data on an affected build server and can show the malware had access to that data, the incident should be reported to BACS. In the more likely case that the malware only grabbed build secrets and no customer data was affected, a report is usually not required, although internal documentation is still worth keeping.

The Bitwarden CLI incident is an instructive example of an attack class that vault technology cannot mitigate. Supply chain hygiene can. Defense starts with patch management, with the choice of third-party tools in your own pipeline, and with an inventory of the secrets that live in developer environments. For a password manager to protect an organization structurally, the tooling ecosystem around it deserves the same scrutiny as the vault itself.