Bitwarden CLI Supply Chain Attack 2
8 Min. Reading time
On the evening of 22 April, a malicious Bitwarden‑CLI package sat in the npm registry for 93 minutes, delivered through the official Bitwarden distribution. The payload ran in the pre‑install hook and exfiltrated GitHub tokens, SSH keys, .env files and cloud secrets to a sub‑domain of audit.checkmarx.cx. The real problem isn’t the hijacked package. The real problem is that DACH security teams in 2026 still have no inventory of their npm pre‑install hooks.
Key Takeaways
- Incident window 22.04.2026, 17:57 – 19:30 ET. @bitwarden/cli@2026.4.0 with malicious bw1.js in the package body, distributed via the official npm path.
- Pre‑install hook is the vector. Malware ran automatically during npm install, AES‑256‑GCM‑encrypted exfiltration to audit.checkmarx.cx, a domain impersonating Checkmarx.
- Loot from CI environments. GitHub and npm tokens, SSH keys, shell history, .env files, GitHub Actions and cloud secrets.
- Entry point was a Bitwarden GitHub Action. Consistent with the Shai‑Hulud pattern of the ongoing Checkmarx supply‑chain campaign.
- Immediate action for DACH security teams. Audit npm pre‑install hooks, add detection rule for AES‑256‑GCM exfiltration to unknown audit sub‑domains, rotate all tokens exposed in CI pipelines.
What is a pre‑install hook?
What is a pre‑install hook? A pre‑install hook is a script that the npm package manager runs automatically before the actual package is installed or used. It is defined in the scripts.preinstall field of package.json. The hook has the same privileges as the running build process, can read any files, open network connections and exfiltrate data. It was originally intended for native build steps (e.g., compiling C extensions) before package setup. In practice it is the most common code‑execution vector in npm supply‑chain attacks because it starts without explicit user action.
Related hook types are install (during installation), postinstall (afterwards) and prepare (on git clone in dependencies). All three share the same privileges and risk profile. A complete hook inventory must cover all four.
What happened, in order
The Bitwarden‑CLI pre‑install incident has a clearly documented timeline. The Bitwarden security team reconstructed the compromised package in the official Bitwarden community forum with minute‑by‑minute details.
The 93‑minute window looks small, but in npm terms it’s large enough to hit thousands of automated builds. Any CI pipeline that spun up a fresh container and installed @bitwarden/cli during that period executed the pre‑install hook. The exfiltration runs without visible logging in the default npm output.
Why pre‑install hooks are the real problem
The usual response to an npm incident is: remove the package from the lockfile, reinstall, and carry on. That treats the symptom, not the mechanism. The mechanism is npm’s pre‑install script feature, which runs a script before the package itself is used. In the Bitwarden case, no one actively invoked the CLI tool to trigger the exfiltration; a simple npm install was enough.
Most engineering teams can’t say how many of their direct dependencies contain a pre‑install hook. The picture is even worse for transitive dependencies. A typical Node project with five hundred transitive packages usually has between ten and forty packages with pre‑install, install, or post‑install hooks. Each of those is a code‑execution vector with virtually zero review time. The Axios npm attack from April used the same mechanism, just a different maintainer account as entry point.
Four‑Step Audit for npm Pre‑install Hooks
Security teams that still don’t have a hook inventory in 2026 can set one up in a single workshop day. Four steps are enough for an initial overview that immediately serves as a detection baseline.
Step 1: Inventory all pre‑install, install and post‑install scripts across every repository. The standard tool is npm-audit-resolver or a simple script that parses every package.json in the dev repos and in vendored lockfiles. The output is a table with package, hook type, script content and last update timestamp. In a medium‑sized engineering team this usually yields 200 to 500 hooks.
Step 2: Classify by risk profile. Hooks that only run local build scripts (e.g., node-gyp rebuild for native extensions) are low‑risk. Hooks that download external scripts, make arbitrary curl calls, or read .env paths in plain text are high‑risk. Classification can be automated with simple pattern matching on the hook content, but each matching package requires a manual review.
Step 3: Check CI configuration for hook protection. npm provides the --ignore-scripts flag to disable all hooks during install. For CI builds this is often an acceptable trade‑off because most build steps already have separate configurations for native extensions and build scripts. Anyone who set the flag in CI was lucky on 22 April.
Step 4: Deploy a detection rule at the SIEM level. A rule that flags outbound connections to unknown audit, telemetry or analytics subdomains from npm build contexts provides an effective detection layer. In the Bitwarden case the subdomain was audit.checkmarx.cx, a deliberately trustworthy‑looking address. A regex that catches subdomains mimicking typical trust tools will capture similar vectors in the future.
What Breaks, What Works in a Hook Audit
The practice emerging from the Bitwarden response wave revealed clear patterns of which detection approaches succeed and which end up as theater.
What Breaks
- Detection based only on package names without inspecting hooks
- SBOM maintenance without active hook classification
- CI builds with active hooks and no network‑egress filtering
- Blind trust in
npm audit, which does not report hook behavior - Manual forensics without pipeline logs from CI runs
What Works
npm installwith--ignore-scriptsas the CI default- Egress filtering on build runners against unknown domains
- Hook inventory with a semi‑annual review cycle
- SIEM rule for AES‑encrypted traffic in npm build contexts
- Token rotation for all build pipelines with a short TTL
The most important change is the CI default. When every new build container starts without active hooks and hooks are enabled only where they are technically required, the attack surface shrinks by orders of magnitude. It’s not a hard‑to‑communicate measure; it costs hours, not days.
What Sec Teams Need to Do Operationally Now
Concrete immediate actions for the week after the incident: First, run the npm audit command with a date filter over the logs of your own CI runs from April 22 between 17:57 and 19:30 ET to verify whether @bitwarden/cli@2026.4.0 was installed during that window. Second, rotate all tokens, SSH keys and .env contents from the potentially exposed build environments. Third, push the detection rule against audit‑subdomain egress into the SIEM, preferably as an alert with medium severity, because false positives exist for legitimate audit‑traffic subdomains.
The medium‑term task is the hook inventory. It belongs in the NIS2 supply‑chain documentation because npm packages are formally suppliers of your software. The plugin‑acquisition wave affecting WordPress and the Bitwarden incident are technically different but regulatorily identical: both are supply‑chain risks that fall under NIS2 Article 21 and must be recorded in the risk register.
In practice, a quarter‑page risk‑register item per supply‑chain path is sufficient: which build pipelines use npm in which account context, which detection layers are applied, what token‑rotation frequency is defined, and who the risk owner is. Most DACH insurers and banks already have the schema from DORA mapping, but they need to articulate it specifically for npm builds. The damage from a single exfiltrated GitHub token with write access to production repos regularly reaches six figures, because the token not only opens one path but also provides leverage for lateral movement across the entire engineering stack.
A second layer that is often forgotten: build caching. Some npm CI setups cache node_modules between builds to save time. If the malicious hook ran in one build, the malicious code persists in the cache even after the package is removed from the lockfile. Post‑incident forensics should explicitly include cache directories; otherwise a residual risk remains that can be re‑activated on the next build run. If you cannot selectively invalidate the cache, you should perform a full cache wipe rather than a quick patch.
On the tooling side the picture has improved slightly since Q1 2026. Open‑source tools such as Socket, Endor Labs Open Source and Snyk have rolled out specific detection rules for hook behavior that were available within hours of the Bitwarden incident. Anyone who has one of these tools in their stack should review the associated rule packs and ingest them into the SIEM. The detection gap has narrowed, but the audit‑obligation part remains, because none of the tools provides a complete hook classification. This is a discipline task that must appear in every DACH security roadmap over the coming months, as the effort to inventory hooks is far lower than the downstream cost of a single compromised build pipeline with production tokens. Operational responsibility belongs to the Application Security team, formal documentation to the CISO office, and the status report should be presented twice a year to the risk committee, because supply‑chain risks are no longer a pure engineering discipline but a directly measured corporate risk position. Anyone still operating in 2026 without this triple‑layer approach does not lack staff; they have an outdated role assignment that can be corrected operationally with a one‑day workshop, a board proposal and a semi‑annual review—without allocating an external consulting budget or waiting for the next external audit.
Conclusion
The Bitwarden incident is neither the first npm supply‑chain attack nor the last. What makes it stand out is the clarity of the vector: the malicious code ran in a pre‑install hook, not in the CLI code that was used. Organizations without a hook inventory in 2026 have blind spots in exactly the layer targeted by the ongoing Shai‑Hulud campaign. A four‑step audit, CI default –ignore‑scripts, egress filtering and a SIEM rule are not large projects. They are the homework every DACH security department should complete in Q2 2026. Waiting until the next maintainer account is compromised teaches the lesson at the cost of tokens that, without a backup, will never return.
Frequently Asked Questions
Am I affected if I installed Bitwarden CLI on April 22?
Only if the installation was performed between 17:57 and 19:30 ET from the npm registry. Anyone who did not install during that window is not affected. Those who did should rotate every token and key reachable from the build environment.
Is uninstalling the package enough?
No. The malicious code already exfiltrated data in the pre‑install hook; removal only deletes the package, not the damage. Token rotation, SSH‑key rotation and a .env content audit are mandatory.
Does the –ignore‑scripts recommendation also apply to local development machines?
Locally it’s trickier, because many developer tools rely on native extensions or build hooks that won’t start without them. A more practical approach is a differentiated allow‑list for the truly required packages plus hardening the local shell environment against unsigned egress connections.
Which domains should security teams add to their detection watchlist?
Subdomains that mimic typical trust‑tool names (audit.*, telemetry.*, sbom.*, supply.*) and appear for the first time in npm‑build contexts. The watchlist should be cross‑checked with the domains of the actual trust tools in use to reduce false positives.
Why is this a NIS2‑relevant incident even though Bitwarden is a US company?
NIS2 Article 21 requires critical sectors to maintain documented supply‑chain risk management. npm packages and CLI tools are part of the software supply chain and therefore fall under the regulation, regardless of the provider’s location. The documentation obligation applies to the German user, not the US vendor.
More from the MBF Media Network
Mid‑size Digital ends in 2026: What SMEs should prepare for by 2027
AI Governance 2026: System‑level instead of Excel compliance
Source cover image: Pexels / Rahul Pandit (px:1933900)
