On Apr. 22, a malicious version of Bitwarden’s command-line interface appeared on npm under the official package name @bitwarden/[email protected]. For 93 minutes, anyone who pulled the CLI through npm received a backdoored substitute for the legitimate tool.
Bitwarden detected the compromise, removed the package, and issued a statement saying it found no evidence that attackers accessed end-user vault data or compromised production systems.
Security research firm JFrog analyzed the malicious payload and found it had no particular interest in Bitwarden vaults. It targeted GitHub tokens, npm tokens, SSH keys, shell history, AWS credentials, GCP credentials, Azure credentials, GitHub Actions secrets, and AI tooling configuration files.
These are credentials that govern how teams build, deploy, and reach their infrastructure.
| Targeted secret / data type | Where it usually lives | Why it matters operationally |
|---|---|---|
| GitHub tokens | Developer laptops, local config, CI environments | Can enable repo access, workflow abuse, secret listing, and lateral movement through automation |
| npm tokens | Local config, release environments | Can be used to publish malicious packages or alter release flows |
| SSH keys | Developer machines, build hosts | Can open access to servers, internal repos, and infrastructure |
| Shell history | Local machines | Can reveal pasted secrets, commands, internal hostnames, and workflow details |
| AWS credentials | Local config files, environment variables, CI secrets | Can expose cloud workloads, storage, and deployment systems |
| GCP credentials | Local config files, environment variables, CI secrets | Can expose cloud projects, services, and automation pipelines |
| Azure credentials | Local config files, environment variables, CI secrets | Can expose cloud infrastructure, identity systems, and deployment paths |
| GitHub Actions secrets | CI/CD environments | Can give access to automation, build outputs, deployments, and downstream secrets |
| AI tooling / config files | Project directories, local dev environments | Can expose API keys, internal endpoints, model settings, and related credentials |
Bitwarden serves over 50,000 businesses and 10 million users, and its own documentation describes the CLI as a “powerful, fully-featured” way to access and manage the vault, including in automated workflows that authenticate using environment variables.
Bitwarden lists npm as the simplest and preferred installation method for users already comfortable with the registry. That combination of automation use, developer-machine installation, and official npm distribution places the CLI exactly where high-value infrastructure secrets tend to live.
JFrog’s analysis shows the malicious package rewired both the preinstall hook and the bw binary entrypoint to a loader that fetched the Bun runtime and launched an obfuscated payload. The compromise is fired at install time and at runtime.
An organization could run the backdoored CLI without touching any stored passwords while the malware systematically collected the credentials governing its CI pipelines, cloud accounts, and deployment automation.
Security firm Socket says the attack appears to have exploited a compromised GitHub Action in Bitwarden’s CI/CD pipeline, consistent with a pattern Checkmarx researchers have been tracking.
Bitwarden confirmed that the incident is connected to the broader Checkmarx supply chain campaign.
The trust bottleneck
Npm built its trusted publishing model to address exactly this class of risk.
By replacing long-lived npm publish tokens with OIDC-based CI/CD authentication, the system removes one of the most common paths attackers use to hijack registry releases, and npm recommends trusted publishing and treats it as a meaningful step forward.
The harder surface is the release logic itself, such as the workflows and actions that invoke the publish step. Npm’s own documentation recommends controls beyond OIDC, such as deployment environments with manual approval requirements, tag protection rules, and branch restrictions.
| Layer in the trust chain | What it is supposed to guarantee | What can still go wrong |
|---|---|---|
| Source repository | The intended codebase exists in the expected repo | Attackers may never need to alter the main codebase directly |
| CI/CD workflow | Automates build and release from the repo | If compromised, it can produce and publish a malicious artifact |
| GitHub Actions / release logic | Executes the steps that build and publish software | A poisoned action or abused workflow can turn a legitimate release path malicious |
| OIDC trusted publishing | Replaces long-lived registry tokens with short-lived identity-based auth | It proves an authorized workflow published the package, not that the workflow itself was safe |
| npm official package route | Distributes software under the expected package name | Users may still receive malware if the official publish path is compromised |
| Developer machine / CI runner | Consumes the official package | Install-time or runtime malware can harvest local, cloud, and automation secrets |
GitHub’s environment settings let organizations require reviewers’ sign-off before a workflow can deploy. The SLSA framework goes further by asking consumers to verify that provenance matches expected parameters, such as the correct repository, branch, tag, workflow, and build configuration.
The Bitwarden incident shows that the harder problem sits at the workflow layer. If an attacker can exploit the release workflow itself, the “official” badge still accompanies the malicious package.
Trusted publishing moves the trust burden upward to the integrity of the workflows and actions that invoke it, a layer that organizations have largely left unexamined.
One token to many doors
For developer and infrastructure teams, a compromised release workflow exposes CI pipelines, automation infrastructure, and the credentials that govern them.
JFrog’s analysis shows that once the malware obtained a GitHub token, it could validate the token, enumerate writable repositories, list GitHub Actions secrets, create a branch, commit a workflow, wait for it to execute, download the resulting artifacts, and then clean up.
Obtaining the token creates an automated chain that transforms a single stolen credential into persistent access across an organization’s automation infrastructure.
A developer’s laptop that installs a poisoned official package becomes a bridge from the host’s local credential store to GitHub access to whatever that GitHub token can reach.
The Bybit incident is a close structural analogy. A compromised developer workstation let attackers poison a trusted upstream interface, which then reached the victim’s operational process.
The difference is that Bybit involved a tampered Safe web UI, while Bitwarden involved a tampered official npm package.
In crypto, fintech, or custody environments, that path can run from a credential store to release signers, cloud access, and deployment systems without ever touching a vault entry.
Within 60 days, Checkmarx disclosed compromised GitHub Actions workflows and OpenVSX plugins, while the Cloud Security Alliance warned that the TeamPCP campaign was actively compromising open-source projects and CI/CD automation components.
JFrog documented how a compromised Trivy GitHub Action exfiltrated LiteLLM’s publish token and enabled malicious PyPI releases, and Axios disclosed that two malicious npm versions circulated for roughly three hours through a compromised maintainer account.
Sonatype counted over 454,600 new malicious packages in 2025 alone, bringing the cumulative total to more than 1.2 million. Bitwarden joins a chain of incidents that confirms release workflows and package registries as the primary attack surface.
| Date / period | Incident | Compromised trust point | Why it matters |
|---|---|---|---|
| Mar. 23, 2026 | Checkmarx disclosed compromised GitHub Actions workflows and OpenVSX plugins | GitHub Actions workflows, developer tooling distribution | Shows attackers targeting upstream automation and trusted tooling channels |
| Within the same campaign window | Trivy / LiteLLM chain documented by JFrog | Compromised GitHub Action leading to token theft and malicious PyPI releases | Demonstrates how one poisoned automation component can cascade into package publication abuse |
| Mar. 31, 2026 | Axios malicious npm versions | Compromised maintainer account | Shows official package names can become attack vectors through account-level compromise |
| Apr. 22, 2026 | Bitwarden CLI malicious npm release | Official npm distribution path for a security tool | Shows a trusted package can expose infrastructure secrets without touching vault contents |
| 2025 total | Sonatype malware count | Open-source package ecosystem broadly | Indicates the scale of malicious-package activity and why registry trust is now a strategic risk |
The precise root cause is not yet public, as Bitwarden has confirmed a connection to the Checkmarx campaign but has not published a detailed breakdown of how the attacker obtained access to the release pipeline.
The outcomes of the attack
The strongest outcome for defenders is that this incident accelerates a redefinition of what “official” means.
Today, trusted publishing attaches provenance data to each released package, thereby confirming the publisher’s identity in the registry. SLSA explicitly documents a higher standard for verifiers to check if provenance matches the expected repository, branch, workflow, and build parameters.
If that standard becomes default consumer behavior, “official” starts to mean “built by the right workflow under the right constraints,” and an attacker who compromises an action but cannot satisfy every provenance constraint produces a package that automated consumers reject before it lands.
The more plausible near-term path runs in the opposite direction. Attackers have demonstrated across at least 4 incidents in 60 days that release workflows, action dependencies, and maintainer-adjacent credentials yields high-value results with relatively low friction.
Each successive incident adds another documented technique to a public playbook of action compromise, token theft from CI output, maintainer account hijack, and trusted-publish-path abuse.
Unless provenance verification becomes the default consumer behavior rather than an optional policy layer, official package names will command more trust than their release processes can justify.