Bitwarden CLI Hit by GitHub Actions Supply Chain
The Bitwarden CLI incident of April 22, 2026, is not a library glitch, but a pipeline problem. The compromised GitHub Action checkmarx/ast-github-action made tokens and build material attack-ready in Bitwarden’s own CI – and thus briefly distributed @bitwarden/cli@2026.4.0 on npm. Anyone responsible for DACH DevSecOps should now examine not the CLI, but the surrounding build machines.
Key Takeaways
- Incident. Between 23:57 and 01:30 CEST on the night of April 22-23, 2026, a compromised variant of @bitwarden/cli@2026.4.0 was available on npm. Bitwarden has since deprecated the release.
- Root Cause. A third-party action named checkmarx/ast-github-action, hijacked as part of the broader Checkmarx incident, exfiltrated workflow secrets within Bitwarden’s GitHub workflow.
- Impact. Payload bw1.js collected GitHub/npm tokens, SSH keys, environment variables, and cloud credentials during npm install. According to Bitwarden, end-user vault data was not affected.
- Mandatory Checks. CI runner inventory, hash pinning for third-party actions, lockfile and cache audit, token rotation, egress filters on build runners.
What is a Supply Chain Attack via GitHub Actions? A supply chain attack via GitHub Actions is a class of attack where attackers compromise not the delivered software package itself, but a third-party action integrated into the build workflow. When executed, this action gains access to workflow secrets (tokens, cloud credentials), which it can exfiltrate to an attacker-controlled endpoint. The stolen tokens can then be used to manipulate releases, write to foreign repositories, or take over cloud resources – noticed by the end customer only when the resulting package becomes visible on the distribution channel.
Why this incident is a pipeline incident, not a CLI incident
The media’s interpretation of the Bitwarden episode is oversimplified: a password manager CLI was supposedly compromised, putting vault data at risk. That’s precisely not what happened. Bitwarden’s official statement confirms a 93-minute distribution channel via npm and explicitly rules out access to vault contents. The real problem lies a layer deeper – within the CI/CD workflow that built and published the CLI.
Bitwarden’s GitHub repository – like many DevSecOps stacks – uses a third-party action called checkmarx/ast-github-action for static analysis. This action was tampered with as part of a broader Checkmarx supply chain campaign and exfiltrated workflow secrets. Using the tokens obtained, the attacker briefly slipped into the publish job and pushed a modified variant of version 2026.4.0 to the npm channel. Security researchers from Socket, Endor Labs, and Palo Alto Networks independently reconstructed the mechanism; the payload bw1.js collected GitHub and npm tokens, SSH keys, shell history, and cloud credentials during the installation hook and sent them AES-256-GCM-encrypted to the imitated domain audit.checkmarx.cx.
For DACH decision-makers, this means: every organization using GitHub Actions is potentially exposed in the same way – regardless of whether Bitwarden CLI is part of their stack. The attack does not target the published package, but rather the point in the workflow where a third-party step gains access to job secrets. Organizations running GitHub workflows with uses: references without hash pinning download the current state of the external action with each run – including any compromise that may have occurred between two builds.
Three Layers DevSecOps Teams Must Now Go Through
The remediation process pragmatically unfolds in three layers. What actually ran on the build runners in recent weeks? Which secrets were available during this time? Which third-party steps had read or write access to the workflow context? Only after these three questions does the CLI version and lockfile analysis follow.
Layer one is the CI Runner Inventory. Every build runner that executed workflows between the evening of April 22nd and midday on April 24th belongs on a list with its Run ID, Job Name, involved Actions, and started Container Image. Self-hosted runners are particularly critical because they retain state between jobs – if a prepared workflow wrote tokens to the runner cache, they will still be there even after the Bitwarden cleanup. GitHub-hosted runners are ephemeral, but the run logs also show the loaded Action versions there.
Layer two is the Secret Inventory. Tokens referenced in an affected job are considered compromised – even if the job ran cleanly. This includes Repository, Organization, and Environment Secrets, OIDC Issuer Tokens, npm Publish Tokens, GitHub PATs, and Cloud Credentials that flowed into the job via federation. Rotation does not need to happen in a panic, but it must occur in a documented sequence, because rotated tokens are referenced in parallel in production systems.
Layer three is the Action Inventory. Which third-party Actions are present in your own workflows? Which of these are referenced by tag (@v3), and which by hash? Tag pinning acts like versioning but offers no guarantee – an attacker with maintainer access can re-point the tag to a compromised commit. Hash pinning freezes the Action to an exact commit SHA and excludes this class of attacks.
Urgent Review Sequence for DACH DevSecOps Teams
1. Export GitHub audit logs from the last 7 days and search for pushes of workflow files as well as Action token usage against external domains. 2. Remove checkmarx/ast-github-action from every workflow or pin it to a commit SHA prior to April 22nd. 3. Rotate all Repository, Organization, and Environment Secrets that were referenced in a workflow between April 22nd and 24th. 4. Check npm lockfiles for @bitwarden/cli@2026.4.0 and, if found, downgrade to a previous version. 5. Activate a SIEM rule that reports connections to audit.checkmarx.cx.
What Has an Immediate Effect – And What Only Appears to Provide Security
The DevSecOps community has been debating for days which measures are truly effective. Some responses are operationally sound, while others offer a false sense of security. The following evaluation distinguishes between essential and optional measures.
Immediate Impact
- Hash pinning for every third-party action (uses: checkmarx/ast-github-action@<sha>)
- OIDC Federation instead of long-lived cloud tokens in workflows
- npm ci –ignore-scripts as default in CI pipelines
- Egress filters on build runners (allowlist on registry, mirror, own domains)
- Token TTL shorter than the typical build cycle
Only Appears Effective
- Tag pinning without hash (tag can be reassigned)
- Two-stage code review without branch protection on workflow files
- Vault solutions without build runner hardening
- SBOM reports that only show runtime dependencies
- Static scanners without visibility into their own workflow files
The most effective immediate measure is the separation of build steps that load external actions from steps that require secrets. In a simple pattern, this means: Linting, static analysis, and dependency scanning run in one job without a secrets block, while the publish step runs in a second job with minimal tokens and no external actions other than those maintained by GitHub itself. Most workflows combine both for historical reasons, even though it is not technically necessary.
At the architectural level, OIDC Federation will become a mandatory pattern within the next 12 months. The effect is sharp: Cloud credentials no longer exist as a stored value in the workflow but are issued ephemerally by the cloud provider for each run. An attacker who compromises a single run will no longer have reusable access afterwards. The migration effort typically amounts to one person-day per cloud account plus the audit of trust conditions – manageable compared to the damage of a token leak.
What the Incident Means for Vault and Secrets Strategies
The knee-jerk question in many DACH security teams is: do we replace Bitwarden? This question misses the point. The incident says nothing about the security of Bitwarden’s server infrastructure or vault encryption. It says something about the build and distribution pipeline. Precisely this pipeline is a potential gateway for any serious open-source or closed-source provider.
What changes is how secrets strategies are secured against CI/CD risks. We observe three adjustments among teams that are thoroughly addressing the incident. First: CLI tools for secret access now run
Do we need to rotate all tokens?
Rotation applies to every token referenced in a workflow between April 22nd and 24th – regardless of whether the build was successful. Repository, organization, and environment secrets, as well as OIDC-related cloud credentials, belong on the rotation list. A complete rotation of all tokens is not necessary, provided they were not referenced in affected workflows.
What are the compliance implications?
Under NIS2, the incident falls under the obligation to report significant incidents, provided that own critical services are affected. Under DORA, the same logic applies to financial institutions. Regardless, all DACH teams should appropriately document the incident in the internal incident log with the measures taken, because supervisory authorities increasingly inquire about supply chain controls in follow-up audits.
Editor’s Reading Tips
- Bitwarden CLI Supply-Chain-Attack 22.04.2026: npm-Hook-Audit – Companion article to the npm hook inventory, detailing the distribution channel and preinstall hooks.
- Axios npm Attack: How a Hijacked Maintainer Account Threatened Millions of Developers – The background to the current incident and a pattern that has been emerging since early April.
- Supply Chain Attack on Trivy: When the Security Scanner Itself Becomes a Weapon – How a DevSecOps tool, of all things, became part of the supply chain and which SLSA layers provide protection.
- Software Supply Chain Security: Why SBOMs Will Become Indispensable in 2026 – Fundamental classification of the SBOM obligation and its role in NIS2/DORA audits.
More from the MBF Media Network
cloudmagazin: BSI-KRITIS and Cloud Usage – Multi-Cloud Compliance under NIS2 and C5
mybusinessfuture: AI More Expensive Than Planned – The 33 Percent Cost Overrun Rate
digital-chiefs: AI Cost Overruns as a Steering Issue for C-Level
Source Cover Image: Pexels / panumas nikhomkhai (px:17489157)
