Between 5:57 p.m. and 7:30 p.m. Eastern Time on April 22, 2026, anyone who ran npm install @bitwarden/cli downloaded a credential-stealing worm. The malicious version, published as 2026.4.0, was live for exactly 93 minutes before Bitwarden’s security team identified and deprecated it. In that window, the package was available to the roughly 250,000 developers who download the Bitwarden CLI every month, along with every CI/CD pipeline that pulls it automatically. The malware did not exploit a flaw in Bitwarden’s code. It exploited a flaw in how security tools are trusted inside software delivery infrastructure.
The incident is part of a broader attack campaign. The same threat actor group that compromised Checkmarx’s GitHub Actions infrastructure earlier in April used that access to reach Bitwarden’s CI/CD pipeline. From there they pushed a malicious npm package. The package spread by stealing GitHub tokens from infected machines and using them to inject itself into every npm package those developers published. The attacker called this the Shai-Hulud worm. The string embedded in the malware reads: “Shai-Hulud: The Third Coming.”
Three supply chain attacks. Three security vendors and developer tools. The pattern says something specific about where attackers are targeting in 2026, and why.
Why Bitwarden CLI Is a Different Kind of Target
Most people who have heard of Bitwarden think of it as a password manager. The consumer product is a browser extension and mobile app. The CLI is something different. It is developer infrastructure. Teams wire @bitwarden/cli into CI/CD pipelines to inject secrets at build or deployment time, pull API keys into automation scripts, and integrate with orchestration frameworks that need programmatic access to a shared vault. The CLI runs with the permissions of the developer account that authenticated it, which typically means it runs with GitHub tokens, npm publish credentials, AWS access keys, and SSH keys in scope.
An attacker who compromises a build environment running @bitwarden/cli does not get access to the user’s password vault. Bitwarden confirmed that no end-user vault data was accessed. What the attacker gets is far more useful for supply chain propagation: the cloud credentials, GitHub tokens, and npm publish permissions that the developer uses to build and ship software. With a single infected developer machine, the attacker gains persistent workflow injection access to every CI/CD pipeline that developer’s tokens can reach.
The 250,000 monthly download figure is not the attack surface. The attack surface is every repository those 250,000 developers can push to.
The Cascade: How Checkmarx Became the Entry Point
The attack’s origin is Checkmarx. On April 22, 2026, Checkmarx confirmed that attackers had compromised multiple components of its public infrastructure: KICS Docker images on Docker Hub, the checkmarx/ast-github-action GitHub Action used in automated security scanning pipelines, a VS Code extension, and a Developer Assist extension. The malicious artifacts were designed to harvest credentials and exfiltrate them to a domain impersonating Checkmarx: audit.checkmarx[.]cx.
Bitwarden uses checkmarx/ast-github-action in its GitHub repository for automated code scanning. This is a common integration. Security-conscious software teams use security scanning tools in their CI/CD pipelines, and checkmarx/ast-github-action is a widely used option. When Checkmarx’s GitHub Action was compromised, the compromise propagated through every repository that used it. Bitwarden’s repository was one of them.
The compromised GitHub Action gave the attacker access to Bitwarden’s CI/CD workflow secrets, including the npm publish credentials for @bitwarden/cli. The attacker used those credentials to push version 2026.4.0 to the npm registry. The npm publish step in Bitwarden’s pipeline is designed to automate distribution. It delivered the malicious package automatically.
This is the specific failure mode that makes security-tool supply chains dangerous: the attack travels upstream. Breaching a security vendor reaches every security-conscious team that uses that vendor’s tooling, because security teams by definition integrate security tools deeply into their build processes. The teams with the most rigorous security practices are the ones most exposed when a security vendor is compromised.
What bw1.js Actually Does: The Technical Mechanism
The malicious version 2026.4.0 introduced two new files absent from all prior releases: bwsetup.js and bw1.js. A recursive diff against version 2026.3.0, published by Endor Labs, confirmed that the core CLI bundle in build/bw.js was essentially unchanged between versions at 3.4 MB. The malware did not modify Bitwarden’s actual code. It wrapped around it.
The package.json modification added a preinstall hook: node bwsetup.js. This hook executes automatically when npm installs the package, before any other installation step. The preinstall hook downloads and installs the Bun JavaScript runtime, then uses Bun to execute bw1.js. The redirect of the bw entry point from build/bw.js to bwsetup.js ensured the malicious wrapper ran instead of the legitimate CLI on first invocation as well.
bw1.js contains the credential harvesting payload. It begins with a kill switch: if the current machine has a Russian language locale installed, the script exits immediately. This is a standard operational security tell. Malware developers skip execution on their own development machines to avoid self-infection; the Russian locale check indicates where the development environment lives.
After the locale check, the malware collects credentials across multiple categories. It harvests npm authentication tokens, validates them against the npm registry to confirm they are active, then uses them to publish malicious versions of any npm packages the compromised account can push to. It captures GitHub personal access tokens and uses them to inject a new GitHub Actions workflow into every repository the token has write access to, adding a workflow that captures all secrets available to future workflow runs. It collects SSH private keys, AWS access key IDs and secrets, Azure service principal credentials, Google Cloud service account keys, and any secrets stored in AWS Secrets Manager accessible from the machine.
All harvested data is encrypted with AES-256-GCM. The decryption key is held only by the attacker, so even other threat actors who observe the exfiltration cannot read the stolen credentials. The encrypted payload is exfiltrated by creating a public GitHub repository under the victim’s own account. That repository’s description contains the string “Shai-Hulud: The Third Coming” and commit messages follow a pattern including “LongLiveTheResistanceAgainstMachines:” followed by the encrypted data. Exfiltrating through the victim’s own GitHub account means the traffic is authenticated GitHub API calls from a known account, which most security tools do not flag as suspicious.
The worm component propagates by using the stolen npm credentials to publish malicious patch versions of any npm packages the infected developer owns. Those malicious versions contain the same bw1.js payload, waiting for the next developer who installs a dependency.
The Shai-Hulud Lineage and What It Reveals About the Attacker
The “Shai-Hulud: The Third Coming” naming convention is the third iteration of a campaign that has used this identifier. The first and second appearances established the technique: GitHub-as-C2, AES-256-GCM encryption of exfiltrated data, asymmetric key management so only the attacker can decrypt stolen credentials, and the Russian locale kill switch. OX Security, whose analysis of the package identified the worm mechanics, notes that the technique has become increasingly sophisticated across iterations.
SecurityWeek attributes the Checkmarx campaign to TeamPCP, a threat actor group also known as DeadCatx3, PCPcat, and ShellForce, active since at least 2024 with a focus on supply chain attacks across the open source ecosystem. TeamPCP claimed responsibility for the Checkmarx incident on social media. The group’s prior campaigns include the April 2026 compromise of Aqua Security’s Trivy vulnerability scanner, which also traveled through Checkmarx’s GitHub Actions infrastructure. Trivy is another security tool used in CI/CD pipelines. The attack pattern is consistent: target security scanning tools that have write access to developer workflows.
Socket’s analysis found overlapping indicators between the Checkmarx breach and the Bitwarden attack at the malware and infrastructure level. The same audit.checkmarx[.]cx exfiltration endpoint appears in both. The same __decodeScrambled obfuscation routine with seed 0x3039 is present in both. The same general pattern of credential theft, GitHub-based exfiltration, and supply chain propagation behavior connects them. Socket notes that operational signatures differ in ways that complicate direct attribution, but the shared tooling strongly suggests the same malware ecosystem.
Why GitHub as Command-and-Control Is Hard to Stop
The exfiltration architecture deserves specific attention because it represents a pattern that is genuinely difficult to block with conventional security controls. The attacker creates repositories under the victim’s own GitHub account. Traffic to github.com is authenticated, expected, and not blocked by most corporate firewalls or DNS filtering systems. The data arrives in encrypted form, unreadable to anyone monitoring the repository content without the attacker’s private key. The repository name and commit messages carry the data, not file contents, which makes content scanning ineffective.
GitGuardian’s analysis of the incident identified additional exfiltration infrastructure: a Cloudflare-fronted domain not previously documented in the Checkmarx campaign disclosure. The use of Cloudflare fronting makes IP-based blocking ineffective, since Cloudflare IPs serve enormous amounts of legitimate traffic. The attack architecture was designed by someone who understood what defensive tools do and built around them.
Defenders can look for the specific exfiltration fingerprints: repositories with the description containing “Shai-Hulud: The Third Coming” or commit messages matching the LongLiveTheResistanceAgainstMachines: pattern, and the file $TMPDIR/tmp.987654321.lock which indicates a running daemon. The SHA-256 hash of the malicious bw1.js file is 18f784b3bc9a0bcdcb1a8d7f51bc5f54323fc40cbd874119354ab609bef6e4cb. These are actionable indicators that can be checked immediately on any machine that had @bitwarden/cli@2026.4.0 installed.
Who Was Exposed and Who Was Not
The malicious version was available from 5:57 p.m. to 7:30 p.m. ET on April 22, 2026. Ninety-three minutes. Any machine or CI/CD pipeline that ran npm install @bitwarden/cli or resolved the package through a lockfile during that window installed version 2026.4.0 and executed the preinstall hook. Any machine or pipeline that did not install during that window was not affected. Bitwarden released a clean version, 2026.4.1, on April 23 at 4:45 p.m. GMT+2, confirming it as the last-known-clean baseline before the compromise.
The exposure is not limited to direct installs. Any developer who had @bitwarden/cli in a project’s dependencies and whose CI/CD pipeline ran during that window without pinning to a specific version hash may have installed the malicious package. The gap between “I use Bitwarden CLI” and “I was exposed” is the npm install timestamp, the version resolution behavior of the project’s package manager, and whether the pipeline ran between 5:57 and 7:30 p.m. ET.
Endor Labs notes that the attack hits security tools embedded deep in developer and CI pipelines particularly hard. After the Trivy and Checkmarx breaches, this represents a third consecutive hit on security-category tooling. The pattern is not coincidental. Security tools are attractive targets precisely because they are granted elevated access to the build environment for legitimate reasons. A tool that scans your code for vulnerabilities needs to run in your CI/CD context. That context contains your secrets.
The Compound Risk: When Security Vendors Are the Attack Vector
The Bitwarden incident illustrates a systemic problem with how the software development ecosystem trusts security tooling. Developers and organizations that invest in security practices integrate security scanning tools into their pipelines. Those integrations create dependencies on third-party GitHub Actions, Docker images, VS Code extensions, and npm packages maintained by security vendors. When a security vendor is compromised, those dependencies become attack vectors that are specifically well-positioned to reach security-conscious teams.
This is the inverse of what supply chain security is supposed to accomplish. Teams that use Checkmarx for code scanning, Trivy for container scanning, and Bitwarden for secret management are teams that have invested in security. The Checkmarx compromise reached those teams because of those investments. The attack traveled through the security tooling itself.
The REF6598 attack on Obsidian’s plugin ecosystem in April demonstrated the same structural property in a different tool category. A tool that developers trust deeply, that runs with elevated filesystem access, and that has a community-maintained extension ecosystem is a high-value supply chain target. The attack does not need a zero-day. It needs access to a trusted distribution channel, a preinstall hook, and 93 minutes.
The MCP ecosystem faces the same exposure. Formal analysis of MCP’s 97-million-download ecosystem identified supply chain poisoning as one of the 23 attack vectors the formal security model catalogs. The Bitwarden incident is a concrete proof of concept for what that attack looks like in practice: a trusted tool, a compromised upstream dependency, 93 minutes of exposure, and credentials from every pipeline it touched.
What Developers and Security Teams Need to Do
The immediate check is straightforward. Determine whether @bitwarden/cli@2026.4.0 was installed on any machine or in any CI/CD pipeline between 5:57 p.m. and 7:30 p.m. ET on April 22, 2026. The fastest indicator is checking for the presence of bw1.js in the npm package directory: find node_modules/@bitwarden/cli -name bw1.js. If the file exists, the malicious version was installed. Verify the SHA-256 hash of bw1.js against the known malicious hash: 18f784b3bc9a0bcdcb1a8d7f51bc5f54323fc40cbd874119354ab609bef6e4cb.
If any exposure is confirmed, credential rotation is not optional. Rotate npm tokens, GitHub personal access tokens, SSH keys, AWS access key IDs and secrets, Azure credentials, and GCP service account keys for any account accessible from the affected machine. Search GitHub for repositories owned by the account that contain “Shai-Hulud: The Third Coming” in their description, which indicates exfiltration repositories created by the malware. Audit npm publish logs for packages with unexpected patch-version bumps that include a preinstall: node setup.mjs hook in their package.json.
The structural fix for future exposure is pinning high-value CLI tools and GitHub Actions to verified content hashes rather than mutable version tags. A package pinned to its SHA-256 hash cannot be swapped for a malicious version without changing the hash and breaking the install. This discipline is more operationally demanding but removes the 93-minute attack window entirely. For GitHub Actions, pinning to a specific commit SHA rather than a mutable tag like @v1 provides the same protection at the workflow level.
Enable npm provenance attestation for packages your organization publishes and require attestation for packages your pipelines consume where it is available. Provenance attestation links a published package version to a specific commit and a verified build environment, making it possible to detect packages published outside the expected workflow. The Bitwarden attack used the attacker’s own npm publish credentials to push a malicious version through the legitimate registry. Provenance attestation would not have prevented the compromise, but it would have made the malicious version detectable as built outside the expected signing context.
The Shai-Hulud worm will have a Fourth Coming. Supply chain attacks that exploit security vendor infrastructure have now succeeded three times against three different tools in a single month. The attack is effective, repeatable, and appears to be actively maintained. The teams most at risk are the ones who care most about security.