Inside a supply chain attack: Bitwarden CLI, Checkmarx campaign, and key lessons

On April 22, 2026, a credential stealer shipped inside a package with 250,000 monthly downloads. It executed silently at install time, required no user interaction, and was pulled automatically by CI runners across dozens of pipelines. By the time the package was pulled from the registry, real machines had already been compromised.

Just a routine dependency update.

Modern infrastructure is only as secure as its weakest dependency. When attackers can't breach your perimeter directly, they compromise something you already trust and ride it straight into your environment.

A supply chain attack is the compromise of a trusted third-party vendor, software component, or service to infiltrate downstream targets. The attacker doesn't need your credentials. They need access to something your build pipeline pulls automatically at 3 AM. They need a preinstall hook that runs before you can inspect it.

The Bitwarden CLI incident is the latest proof that this threat is operational, coordinated, and accelerating. In this article, we break down how the attack worked, what it teaches us about modern infrastructure, and what controls actually prevent supply chain compromises from reaching your environment.

Key takeaways

Supply chain attacks bypass your perimeter by weaponizing what you already trust — packages, CI workflows, and plugins execute in your environment with full privileges, without a single phishing link.
The April 2026 Bitwarden CLI compromise was a coordinated, multi-stage operation — attackers hijacked a third-party GitHub Action, stole an npm token, and published @bitwarden/[email protected] with a credential stealer that ran silently at install time.
Transitive dependencies are your largest unaudited attack surface — your application may import ten packages directly, but each of those pulls in dozens more, none of which receive the same scrutiny as first-party code.
Architecture is a stronger control than process — a system designed so that compromising one component yields nothing useful is fundamentally more resilient than one that relies on every control holding simultaneously.
Secrets in CI/CD pipelines are the primary target — GitHub tokens, SSH keys, and cloud credentials harvested in a single build job can propagate a compromise across every repository and pipeline that token can reach.
Defense requires continuous controls, not periodic ones — pinned dependencies, signed builds, SBOM tracking, scoped ephemeral tokens, and secrets rotation must run on every commit, not every quarter.

What is a supply chain attack

A supply chain attack occurs when an adversary compromises a trusted third-party vendor, open-source package, or software component to deliver a malicious payload to downstream organizations. The attacker exploits the trust relationship between a supplier and its consumers, making detection significantly harder than with direct intrusion.

The attack surface is wide because modern software is built on layers of dependencies. Your application may directly import ten packages, but each of those imports dozens more. These transitive dependencies (components your code relies on indirectly) are rarely audited with the same rigor as first-party code.

Supply chain attacks fall into several categories:

Software supply chain attacks — Malicious code injected into open-source libraries, package registries (npm, PyPI), or vendor software updates.
CI/CD pipeline attacks — Compromise of build systems, GitHub Actions workflows, or container registries to intercept the build process.
Third-party service attacks — Exploitation of SaaS tools, plugins, or managed services that have privileged access to customer environments.
Hardware supply chain attacks — Physical tampering with firmware or components before they reach the end user (less common in software contexts, but documented in nation-state operations).

The common thread: the victim installs, runs, or trusts something that has already been weaponized.

The anatomy of a modern supply chain attack

A supply chain attack follows a predictable lifecycle. Knowing the phases is what makes it preventable.

Reconnaissance. Attackers scan public repositories, package registries, and CI/CD configurations for weak links: unprotected GitHub tokens, packages with high download counts and minimal maintainers, or Actions workflows with excessive permissions.
Upstream compromise. The attacker gains write access to a trusted artifact by stealing maintainer credentials, submitting a malicious pull request, or injecting code directly into a build pipeline. The malicious payload is embedded where it will execute automatically: a preinstall hook, a workflow step, a plugin update.
Dormancy. The compromised artifact is published and waits. Automated systems (CI runners, dependency managers, developer workstations) pull the update without human review. The malicious code sits dormant until triggered.
Downstream delivery. Developers and pipelines install the infected version through normal, trusted channels. There is no phishing link to click, no suspicious attachment to open. The credential stealer executes as part of the standard build process.
Privilege escalation. With initial access established, the attacker harvests secrets: API tokens, SSH keys, environment variables, cloud credentials. GitHub tokens are particularly valuable — they can be weaponized to inject malicious workflows into every repository the token can reach, propagating the compromise further downstream.

Unprotected secrets in CI/CD pipelines are exactly what attackers harvest in phase five. Try Passwork free and see how structured secrets management reduces your exposure → passwork.pro

Case study: the 2026 Bitwarden CLI and Checkmarx campaign

The Bitwarden CLI supply chain attack, confirmed by JFrog and Socket on April 23, 2026, is one of the most technically precise credential-harvesting operations documented to date. It targeted developers directly: their tokens, their AI tools, their pipelines. And it carried an important architectural lesson for the entire industry.

The attack unfolded in stages, each one exploiting a different layer of trust in the software supply chain.

What happened

On April 22, 2026, a malicious version of the Bitwarden CLI (@bitwarden/[email protected] ) was published to the npm registry. The package has over 250,000 monthly downloads, making it a high-value target. The malicious code was embedded in bw1.js and triggered via a preinstall hook in package.json, which first ran bw_setup.js to install the Bun runtime, then executed bw1.js — the actual malicious payload (OX Security, 2026). No user interaction required.

They compromised a third-party GitHub Action used in Bitwarden's CI/CD pipeline, gained access to workflow secrets including an npm token, and used it to publish the malicious package — Source: OX Security

The attackers didn't breach Bitwarden directly. They compromised a third-party GitHub Action used in Bitwarden's CI/CD pipeline, gained access to workflow secrets including an npm token, and used it to publish the malicious package. The attack used the CI/CD pipeline as the entry point — consistent with the broader pattern identified across the Checkmarx supply chain campaign. The string "Shai-Hulud: The Third Coming" embedded in the package confirmed this was the third iteration of an ongoing, organized campaign — not an opportunistic one-off.

Critically, no user vaults were affected. Bitwarden's zero-knowledge architecture meant the server never held master passwords or access to decrypted user data. Even with CI/CD compromised, the attacker couldn't reach what the architecture was designed to protect.

What the malware did

The malicious payload (the third phase of the "Shai-Hulud" worm) performed the following sequence:

Russian-language check. Before doing anything else, the malware checked whether the host machine had Russian language configured. If so, it exited immediately. This is a standard self-protection technique: the authors avoid infecting their own development machines, and it points strongly to a Russian-speaking threat actor.
Credential harvesting. It targeted GitHub and npm tokens, .ssh directories, .env files, shell history, GitHub Actions environment variables, AWS, GCP, and Azure credentials, and GitHub Runner information.
AI tool targeting. Configuration files for AI coding assistants (Claude, Kiro, Cursor, Codex CLI, and Aider) were explicitly targeted, reflecting how deeply these tools are now embedded in developer workflows and how much sensitive context they store locally.
Encrypted exfiltration via GitHub. All stolen data was encrypted with AES-256-GCM using asymmetric encryption — meaning only the threat actor's private key can decrypt it. The data was uploaded to a newly created public GitHub repository on the victim's own account, with files named results-TIMESTAMP-ID.json. A secondary channel exfiltrated data to audit.checkmarx[.]cx, a domain impersonating the legitimate Checkmarx platform. Using GitHub as a C2 server is deliberate: traffic to github.com is rarely flagged by security tools and cannot be traced to a threat-actor-controlled domain.
Self-propagation. This is what makes Shai-Hulud a worm, not just a stealer. If valid npm tokens were found, the malware downloaded one of the victim's own npm packages, injected malicious code into it, and republished a new version — spreading the infection to the victim's downstream users automatically.
Pipeline propagation. If GitHub tokens were found, the malware injected malicious Actions workflows into accessible repositories, extracting CI/CD secrets and extending the compromise to every pipeline the developer's token could reach.

As StepSecurity noted: "A single developer with @bitwarden/[email protected] installed can become the entry point for a broader supply chain compromise, with the attacker gaining persistent workflow injection access to every CI/CD pipeline the developer's token can reach."

OX Security confirmed that encrypted exfiltration data was already present in public GitHub repositories at the time of discovery — real machines had been compromised before the package was pulled.

The Checkmarx incident: March 23, 2026

This campaign didn't begin in April. According to the Checkmarx security update, on March 23, 2026, malicious versions of two OpenVSX plugins were published at approximately 02:53 UTC and remained available until 15:41 UTC. Two GitHub Actions workflows (ast-github-action and kics-github-action) were also compromised. Organizations that downloaded these artifacts during that window and executed them were exposed.

The April Bitwarden CLI incident followed the same GitHub Actions supply chain vector, confirming an active, evolving campaign rather than an isolated incident.

The architectural lesson

Passwords are encrypted client-side and stored on the server only in encrypted form.

The Bitwarden incident reflects a pattern the industry keeps relearning: process-level security controls can be bypassed. Architectural constraints cannot. A system designed so that compromising one component yields nothing useful is fundamentally more resilient than one that relies on every control holding simultaneously.

Passwork is built on this principle. Credentials are encrypted client-side before they ever reach the server. The server stores ciphertext. A database breach, a compromised server, or a rogue administrator yields nothing without the client-side keys. Passwork CLI publishing to PyPI follows a semi-manual process from trusted machines — CI/CD compromise cannot trigger an automated release of a malicious artifact.

The question to ask about any tool in your stack: if this component is compromised, what does the attacker actually get?

Other notable supply chain attacks (2020–2026)

The Bitwarden CLI incident is the latest in a series of high-impact supply chain compromises that have reshaped how security teams think about third-party risk.

Incident	Year	Vector and Impact
event-stream (npm)	2018	Social engineering of open-source maintainer; malicious dependency injected into npm package. Targeted Bitcoin wallet credentials; millions of downstream installs affected
SolarWinds	2020	Malicious update injected into Orion build pipeline. ~18,000 organizations affected; multiple US government agencies breached
Codecov	2021	Compromised Docker image build process; malicious Bash Uploader script distributed to CI environments. Environment variables and CI/CD secrets exfiltrated from thousands of organizations for two months undetected
3CX	2023	Trojanized desktop app update; first documented supply chain attack triggered by a prior supply chain attack. Signed, vendor-distributed installer delivered infostealer to 600,000+ business customers; attributed to Lazarus Group
XZ Utils backdoor	2024	Multi-year social engineering of open-source maintainer; backdoor embedded in SSH authentication. Near-miss: caught before widespread deployment; affected systemd-linked Linux distributions

Each incident shares a structural pattern: attackers found a trusted, automated delivery mechanism and inserted their payload where it would execute without scrutiny:

event-stream established that open-source maintainer trust is exploitable at scale
SolarWinds showed that even signed, vendor-distributed updates can be weaponized
XZ Utils demonstrated that long-term social engineering of maintainers is a viable attack path
Codecov proved that CI/CD infrastructure itself is a high-value target — secrets harvested from build pipelines can unlock entire organizations
The 3CX case introduced a new threat model: a supply chain attack used as the entry point for another supply chain attack

The attack surface has expanded with every iteration. What began as isolated package hijacks has evolved into coordinated, multi-stage campaigns targeting the entire software delivery chain.

The true cost of supply chain vulnerabilities

Supply chain attacks are expensive — and the cost is accelerating. According to Wiz's 2025 analysis, global costs of software supply chain attacks are estimated at $60 billion in 2025 and are projected to reach $138 billion by 2031.

These figures reflect direct incident response costs, regulatory penalties, reputational damage, and the downstream costs borne by affected customers — not just the breached vendor.

The regulatory dimension compounds the financial exposure. Organizations operating under GDPR, HIPAA, SOC 2, or ISO 27001 face mandatory breach notification requirements and potential fines when supply chain incidents result in unauthorized access to personal or regulated data. A compromised CI/CD pipeline that exfiltrates environment variables containing database credentials isn't just an operational incident — it's a compliance event.

For organizations with mature security programs, the harder cost to quantify is trust. When a developer tool used across hundreds of pipelines is compromised, the remediation effort extends far beyond patching: every secret that could have been exposed must be treated as compromised and rotated.

How to prevent supply chain attacks in CI/CD environments

Preventing supply chain attacks requires controls at every layer of the software delivery process. The following practices address the specific attack vectors seen in the 2026 campaigns.

Pin dependency versions and verify hashes. Never use floating version ranges in production pipelines. Pin exact versions and validate checksums against a known-good state. This won't prevent a maintainer account compromise, but it eliminates automatic exposure to newly published malicious versions.
Enforce signed builds and provenance attestation. A signed artifact with a verifiable build chain is significantly harder to tamper with undetected.
Generate and maintain a software bill of materials (SBOM). An SBOM gives you a complete inventory of every component in your software, including transitive dependencies. When a new vulnerability or malicious package is disclosed, you can immediately determine whether you're affected — without manual auditing.
Run continuous software composition analysis (SCA). Static, one-time scans are insufficient. SCA tools should run on every pull request and every dependency update, flagging new packages, unusual preinstall hooks, and unexpected network calls in package scripts.
Apply zero-trust principles to CI/CD workflows. GitHub Actions workflows should operate with the minimum permissions required. Use ephemeral tokens scoped to individual jobs, not long-lived personal access tokens. Audit workflow files for third-party Action references and pin them to specific commit SHAs, not mutable tags.
Rotate CI/CD secrets regularly and after every incident. Treat secrets in CI/CD environments as short-lived credentials. Any token, API key, or SSH key that could have been exposed should be rotated immediately. A structured secrets management process makes this operationally feasible rather than a manual scramble.
Monitor for anomalous exfiltration behavior. The Bitwarden CLI malware made outbound connections to audit.checkmarx[.]cx. Network-level monitoring of CI runner egress traffic would have flagged this. Allowlist expected outbound destinations for build environments and alert on deviations.
Audit AI coding tool configurations. The 2026 campaign explicitly targeted configuration files for Claude, Cursor, Aider, and similar tools. These files often contain API keys and context about the codebase. Treat them as sensitive artifacts and include them in your secrets scanning scope.

Conclusion

Supply chain attacks work because they exploit the one thing organizations can't easily audit: the trust embedded in automated systems. Every dependency your pipeline pulls, every GitHub Action your workflow references, every plugin your IDE loads — each is a potential entry point.

The 2026 Bitwarden CLI and Checkmarx campaigns make the threat concrete. A single compromised package, installed silently by a CI runner, can expose every secret in a developer's environment and propagate through every pipeline that token can reach. The attack doesn't announce itself. It executes as part of your normal build process.

Defending against this requires more than periodic audits. It requires zero-trust architecture applied to the software supply chain: pinned dependencies, signed artifacts, SBOM tracking, continuous SCA, and short-lived scoped credentials. Secrets must be treated as perishable — rotated regularly, stored securely, and never embedded in code or environment files without governance.

Robust secrets management is a foundational control here. When credentials are stored in a structured, access-controlled vault like Passwork rather than scattered across .env files and developer workstations, the blast radius of a supply chain compromise shrinks significantly. Attackers can steal what they can reach. Make it nothing.

Ready to reduce your blast radius? Passwork gives your team a structured secrets vault with role-based access, full audit logging, and a self-hosted deployment that keeps credentials off third-party infrastructure. Explore Passwork

FAQ: Supply chain attacks

What is a supply chain attack in cybersecurity?

A supply chain attack is a cyberattack that compromises a trusted third-party vendor, open-source package, or software component to gain access to downstream targets. Instead of attacking an organization directly, adversaries insert malicious payloads into software updates, build pipelines, or dependencies that the target installs automatically.

How did the Bitwarden CLI supply chain attack work?

The malicious @bitwarden/[email protected] package was published to npm on April 22, 2026, with a credential stealer embedded in bw1.js and executed via a preinstall hook. It harvested GitHub tokens, SSH keys, environment variables, cloud secrets, and AI coding tool configurations, then exfiltrated the data — encrypted with AES-256-GCM — to a domain impersonating Checkmarx.

What is the difference between a supply chain attack and a direct cyberattack?

A direct attack targets the victim's own systems — their network, credentials, or applications. A supply chain attack targets a trusted supplier or dependency instead, using that trust to bypass the victim's defenses. The victim installs or runs the compromised component voluntarily, through normal processes, which makes detection significantly harder.

What are transitive dependencies and why do they matter for security?

Transitive dependencies are software components that your code relies on indirectly — libraries imported by your direct dependencies, which in turn import others. They are rarely audited with the same rigor as first-party code, yet they execute in your environment with the same privileges. A compromise anywhere in that chain can affect your application.

What is an SBOM and how does it help prevent supply chain attacks?

A software bill of materials (SBOM) is a structured inventory of every component in a software product, including all direct and transitive dependencies. When a malicious package or vulnerability is disclosed, an SBOM lets security teams immediately determine whether their software is affected — without manually tracing dependency trees across every project.

What GitHub Actions security practices reduce supply chain risk?

Pin all third-party Actions to specific commit SHAs rather than mutable version tags. Use ephemeral, job-scoped tokens instead of long-lived personal access tokens. Restrict workflow permissions to the minimum required. Audit all workflow files for unexpected third-party references, and monitor CI runner egress traffic for anomalous outbound connections.

How should organizations respond if a compromised package was installed in their CI/CD pipeline?

Treat all secrets accessible during the affected build jobs as compromised. Rotate every token, API key, SSH key, and cloud credential that could have been exposed. Review GitHub Actions workflow files for unauthorized modifications. Audit repository access logs for unexpected commits or workflow runs. Report the incident per your regulatory obligations under GDPR, HIPAA, or applicable frameworks.

Inside a real supply chain attack: Bitwarden CLI, Checkmarx campaign, and key lessons