24 April 2026 Supply Chain Security

Bitwarden CLI Backdoored: The Shai-Hulud npm Supply Chain Attack and What Australian Developers Must Do

On 22 April 2026, the official Bitwarden CLI npm package was briefly replaced with a malicious version that stole developer credentials, self-propagated through the npm ecosystem, and exfiltrated secrets to remote servers — all within a 93-minute window. The Australian Signals Directorate had warned about exactly this type of attack just three weeks earlier. Here is what happened and what any developer using open-source tooling must do now.

Disclosure: This post contains affiliate links. We only recommend tools we've researched and trust. If you purchase through our links, we may earn a commission at no extra cost to you.

What Happened: The 93-Minute Bitwarden CLI Compromise

On the evening of 22 April 2026, security researchers from OX Security, Endor Labs, and Socket identified that @bitwarden/cli version 2026.4.0 — the official command-line client for the Bitwarden open-source password manager — had been tampered with and published to the npm registry. The malicious version was live for approximately 93 minutes, between 5:57 PM and 7:30 PM Eastern Time. Anyone who ran npm install or npm update during that window and had Bitwarden CLI as a dependency received the compromised build.

The attack did not involve compromising Bitwarden's source code directly. Instead, threat actors exploited a vulnerability in Bitwarden's continuous integration/continuous delivery (CI/CD) pipeline — specifically, a compromised GitHub Actions workflow — to inject malicious code into the published npm artefact. This is a known supply chain attack vector: the source code repository remained clean, but the distributed package did not. Developers who reviewed Bitwarden's GitHub repository would have seen nothing unusual; the danger was hidden in the published binary.

Bitwarden's security team responded promptly once the attack was identified. The compromised version was deprecated on the npm registry, misused access tokens were revoked, and Bitwarden published guidance instructing any developer who had installed the package during that window to immediately uninstall it (npm uninstall -g @bitwarden/cli) and clear their npm cache. The team confirmed that only the CLI npm distribution path was affected — Bitwarden's web vault, browser extensions, and mobile applications were not touched.

The attack is attributed to the "Shai-Hulud" threat campaign. Researchers labelled this incident "The Third Coming," indicating that it is the third known wave of this particular threat actor's supply chain intrusion series. The campaign is linked to a broader set of attacks tracked by Checkmarx's supply chain security team, which has been monitoring this group's evolving tactics across the npm ecosystem.

The timing was not accidental. In the same 48-hour window of 21–23 April 2026, three separate supply chain attack campaigns hit npm, PyPI, and Docker Hub simultaneously — all targeting the same surfaces: API keys, cloud credentials, SSH keys, and developer CI/CD tokens. The Bitwarden CLI compromise was the most high-profile of the wave, but it was not the only one. Sources: Bleeping Computer; OX Security.

Why This Attack Is Different: A Self-Propagating npm Worm

Compromised npm packages are not new. Typosquatting (publishing packages with names similar to popular ones), dependency confusion (injecting malicious packages into internal registries), and account takeovers are documented threats. What distinguishes Shai-Hulud from most compromised-package incidents is what the malware does after it lands on a victim's system: it spreads.

If the malware found npm publish tokens with write permissions on a victim's machine, it did not stop at stealing credentials. It used those tokens to identify every package that the victim had rights to publish and injected those packages with the same malicious preinstall hook. A single infected developer workstation could therefore silently backdoor dozens of other packages across public npm registries or a company's private package registry — expanding the blast radius far beyond the initial incident. Supply chain researchers at OX Security described this as a "branching" infection tree that propagates through your open-source or internal registries without any further attacker action.

The Australian Signals Directorate's Australian Cyber Security Centre (ASD's ACSC) had already raised the alarm about exactly this threat vector. On 1 April 2026 — just three weeks before the Bitwarden CLI incident — the ACSC issued a High Alert warning Australian organisations and developers about the active, ongoing targeting of online code repositories. The alert described threat actors using phishing, vishing, social engineering, compromised credentials, compromised authentication tokens, and infected packages to gain access to code repositories. According to reporting by Avocado Consulting, it was the ACSC's second High Alert on this topic in five months — an unusual cadence that underscores how seriously the ASD views the threat.

For Australian developers and businesses that use open-source tooling in their workflows — and that includes virtually every startup, digital agency, and SaaS provider in the country — this is not a theoretical concern. Automated CI/CD pipelines that pull npm packages as part of scheduled builds could have been affected without any human intentionally running a command. If a GitHub Actions workflow triggered npm update during the 93-minute compromise window on 22 April, it may have silently installed @bitwarden/cli@2026.4.0 with no developer aware of the change. Source: ACSC Alerts and Advisories.

How the Attack Worked: Inside Shai-Hulud's Mechanisms

The malicious preinstall hook

The @bitwarden/cli@2026.4.0 package introduced a malicious preinstall hook in its package.json, pointing to a new file named bw_setup.js. This hook fires automatically when a developer runs npm install — no additional user interaction is required. The hook executed bw_setup.js, a cross-platform loader that downloaded the legitimate Bun JavaScript runtime from GitHub to run the next-stage payload. Using a legitimate, widely recognised runtime was deliberate: it reduces the likelihood that static malware scanners will flag the presence of an unknown or suspicious binary.

Multi-cloud credential harvesting

Once running, the malware targeted six distinct secret surfaces on the victim's system:

npm and GitHub tokens stored in local configuration files and environment variables
SSH private keys from the ~/.ssh directory
.env files containing API keys, database credentials, and service passwords
Shell history files (bash_history, zsh_history), which can expose recently typed secrets and command patterns
GitHub Actions secrets accessible from CI/CD pipeline environments at the time of execution
Cloud provider credentials for AWS, GCP, and Azure stored in standard credential directories

Researchers at OX Security noted the worm also specifically targeted authenticated sessions of AI coding assistants — a novel capability suggesting the threat actors are actively adapting to development environments where tools like GitHub Copilot and similar AI-assisted IDEs are embedded in daily workflows.

The GitHub dead-drop C2 channel

All exfiltrated data was encrypted using RSA signing before transmission. The malware uploaded stolen credentials to attacker-controlled private domains and also committed encrypted data to public GitHub repositories — a technique researchers dubbed "GitHub dead-drop command and control." This approach makes C2 traffic appear as ordinary repository commit activity, complicating detection by network monitoring tools that treat GitHub traffic as trusted.

Self-propagation through the npm registry

If the malware discovered a valid npm publish token with write permissions on the infected system, it enumerated every package that token could publish to and injected the same malicious preinstall hook into those packages. This "branching" mechanism means a single compromised developer workstation can silently infect dozens of downstream packages — both public npm packages and private corporate registries — without any further attacker intervention. The infection tree grows organically through the victim's existing publishing rights.

CI/CD pipeline as the entry point

Bitwarden's own investigation confirmed that the source code repository was not directly compromised. The attack succeeded by exploiting a compromised GitHub Actions workflow, which tampered with the build artefact during the publishing step. This "build-time injection" is particularly dangerous because it bypasses any source code review: a developer auditing Bitwarden's GitHub repository would find nothing unusual. The malicious code only ever existed in the distributed npm package, not in the repository that generated it. Source: Endor Labs analysis; iTnews.

What Developers Must Do Right Now

If you or your team use the Bitwarden CLI via npm, the following steps are time-sensitive. Even if you are confident you were not affected, the broader Shai-Hulud campaign warrants a review of your credential hygiene regardless.

Immediate steps if you may have been affected

First, determine whether @bitwarden/cli@2026.4.0 was installed on any of your systems or in any CI/CD pipeline between 5:57 PM and 7:30 PM Eastern Time on 22 April 2026 (equivalent to 7:57 AM–9:30 AM AEST on 23 April 2026). Check your npm logs (~/.npm/_logs/), your shell history, and your CI/CD pipeline run logs.

If you find evidence of the malicious version being installed:

Uninstall it immediately: npm uninstall -g @bitwarden/cli
Clear your npm cache: npm cache clean --force
Rotate every secret that was accessible on the affected system: npm access tokens, GitHub personal access tokens and fine-grained tokens, SSH keys, all values in .env files, AWS/GCP/Azure credentials, and any service API keys stored in environment variables
Review any npm packages you publish: check for unexpected new versions, unexpected commits, or unexpected changes to package.json or preinstall hooks published after 22 April
Enable GitHub's secret scanning alerts on all repositories you control — GitHub's free tier can detect common credential patterns in commits

Broader supply chain hygiene steps

Following the ACSC's April 2026 High Alert, all Australian developers and DevOps teams should review their package management practices:

Pin package versions. Use exact version pinning in package.json (e.g., "@bitwarden/cli": "2026.3.0" not "^2026.3.0") and commit a package-lock.json so that npm ci installs known-good versions only.
Use npm ci in CI/CD, not npm install. npm ci respects the lockfile strictly and refuses to silently upgrade packages, eliminating a key attack vector.
Run npm audit regularly. It won't catch every supply chain compromise, but it flags known-vulnerable package versions.
Review CI/CD secrets scoping. CI/CD environments should only have access to the secrets they specifically need — not your entire npm token list or all your cloud credentials. Principle of least privilege applies to automated pipelines as much as to human users.
Enable two-factor authentication on npm. npm supports MFA for publishing. Requiring MFA for package publication would have made this class of attack considerably harder.

The ACSC specifically recommends that organisations review their logs for recent package installations, validate packages against expected checksums where possible, educate their teams about supply chain risks, and monitor their code repositories for unexpected secret scanning activity. These are now baseline hygiene items, not optional extras, for any Australian development team.

The Bigger Picture: Australia's Code Repository Security Problem

The Shai-Hulud incident does not exist in isolation. It sits within a pattern that the ACSC has now flagged urgently on two separate occasions: threat actors have identified software supply chains as a high-value attack surface, and they are iterating rapidly. The "Third Coming" label attached to this campaign by researchers makes the group's persistence explicit — they have been active, partially disrupted, and adapted their approach at least twice before this incident.

The broader April 2026 attack wave amplified the risk further. In the same 48 hours as the Bitwarden CLI compromise:

Malicious packages on PyPI disguised as Kubernetes utilities deployed a persistent Go-based backdoor
Docker Hub packages embedded credential harvesters targeting cloud environment configurations
A GitHub Actions campaign dubbed "prt-scan" abused the pull_request_target trigger to steal CI/CD secrets from open-source repositories
36 separate malicious npm packages exploited Redis and PostgreSQL connections to deploy persistent implants on developer machines

Three registries, four separate campaigns, 48 hours. This is not coincidence — it reflects a threat landscape in which supply chain attack tooling has become commoditised and threat actors are running concurrent campaigns across multiple ecosystems.

What this means for the Essential Eight

Australian organisations aligning with the ACSC's Essential Eight framework will find that supply chain attacks challenge several controls simultaneously. Application control — ensuring only approved software executes — is tested when a trusted package is tampered with mid-distribution. Patch management is complicated when the "patched" version is itself the attack vector. Multi-factor authentication on npm and GitHub publishing accounts directly addresses the credential-harvesting step that enables these attacks to propagate.

Organisations at Essential Eight Maturity Level 2 and above should already have policies for validating third-party software and restricting developer machine access to production secrets. If those policies exist on paper but not in practice — which is the case at many Australian SMBs and digital agencies — the Bitwarden CLI incident is the kind of event that clarifies the cost of that gap.

A note on Bitwarden

It is worth stating clearly: this attack targeted Bitwarden's distribution infrastructure, not Bitwarden's security model. Bitwarden's web vault and the cryptographic architecture that protects stored passwords were not affected. The vendor's response — identifying the compromise, deprecating the package, and publishing guidance within hours — was appropriate. The incident highlights the fragility of the npm publishing pipeline as an attack surface, not any flaw in Bitwarden's product. Users of Bitwarden's web vault, browser extensions, or mobile apps have no reason to change their passwords or switch products as a result of this incident.

What the incident does highlight is that even security-focused software vendors are not immune to supply chain compromise when their CI/CD pipelines are targeted. Developers should treat any npm package — regardless of the vendor's reputation — as a potential attack surface, and apply the hygiene steps described above to all dependencies, not just Bitwarden. The trust model for open-source packages is under active attack. Adjusting accordingly is not paranoia; it is proportionate risk management.