Key Takeaways<\/p>\n
- \n
- Incident window 22.04.2026, 17:57\u202f\u2013\u202f19:30\u202fET.<\/strong> @bitwarden\/cli@2026.4.0 with malicious bw1.js in the package body, distributed via the official npm path.<\/li>\n
- Pre\u2011install hook is the vector.<\/strong> Malware ran automatically during npm install, AES\u2011256\u2011GCM\u2011encrypted exfiltration to audit.checkmarx.cx, a domain impersonating Checkmarx.<\/li>\n
- Loot from CI environments.<\/strong> GitHub and npm tokens, SSH keys, shell history, .env files, GitHub Actions and cloud secrets.<\/li>\n
- Entry point was a Bitwarden GitHub Action.<\/strong> Consistent with the Shai\u2011Hulud pattern of the ongoing Checkmarx supply\u2011chain campaign.<\/li>\n
- Immediate action for DACH security teams.<\/strong> Audit npm pre\u2011install hooks, add detection rule for AES\u2011256\u2011GCM exfiltration to unknown audit sub\u2011domains, rotate all tokens exposed in CI pipelines.<\/li>\n<\/ul>\n<\/div>\n
What is a pre\u2011install hook?<\/h2>\n
What is a pre\u2011install hook?<\/strong> A pre\u2011install 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<\/code> field ofpackage.json<\/code>. 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\u2011execution vector in npm supply\u2011chain attacks because it starts without explicit user action.<\/p>\nRelated hook types are
install<\/code> (during installation),postinstall<\/code> (afterwards) andprepare<\/code> (on git clone in dependencies). All three share the same privileges and risk profile. A complete hook inventory must cover all four.<\/p>\nWhat happened, in order<\/h2>\n
The Bitwarden\u2011CLI pre\u2011install incident has a clearly documented timeline. The Bitwarden security team reconstructed the compromised package in the official Bitwarden community forum with minute\u2011by\u2011minute details.<\/p>\n
\nBitwarden CLI Compromise Timeline (all times ET)<\/div>\n\n\n22.04. 17:57<\/div>\n@bitwarden\/cli@2026.4.0 published to the npm registry with malicious bw1.js. The trigger was a compromised GitHub Action in the Bitwarden CI pipeline.<\/div>\n<\/div>\n\n22.04. 18:30<\/div>\nFirst automated exfiltration telemetry becomes visible to third\u2011party security researchers (Endor Labs, Socket, Safedep).<\/div>\n<\/div>\n\n22.04. 19:30<\/div>\nBitwarden pulls the package from the registry, posts a security notice to the community forum and social channels, and begins forensic analysis of the CI pipeline.<\/div>\n<\/div>\n\n23.04.<\/div>\nSecurityWeek, The Hacker News and Endor Labs publish the first technical analyses, linking the attack to the ongoing Shai\u2011Hulud campaign.<\/div>\n<\/div>\n\n25.04.<\/div>\nBitwarden confirms that end\u2011user vault data was not affected. The risk is limited to developers and CI systems that installed the package within the 93\u2011minute window.<\/div>\n<\/div>\n<\/div>\n<\/div>\nThe 93\u2011minute window looks small, but in npm terms it\u2019s 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\u2011install hook. The exfiltration runs without visible logging in the default npm output.<\/p>\n
Why pre\u2011install hooks are the real problem<\/h2>\n
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\u2019s pre\u2011install 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<\/code> was enough.<\/p>\nMost engineering teams can\u2019t say how many of their direct dependencies contain a pre\u2011install 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\u2011install, install, or post\u2011install hooks. Each of those is a code\u2011execution vector with virtually zero review time. The Axios npm attack from April<\/a> used the same mechanism, just a different maintainer account as entry point.<\/p>\n
\n93 Min<\/div>\nAvailability window of the malicious bw1.js in the official npm registry on 22\u202fApril\u202f2026.<\/div>\nSource: Bitwarden Community Forum Statement, 23.04.2026<\/div>\n<\/div>\nFour\u2011Step Audit for npm Pre\u2011install Hooks<\/h2>\n
Security teams that still don\u2019t 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.<\/p>\n
Step 1: Inventory all pre\u2011install, install and post\u2011install scripts across every repository.<\/strong> The standard tool is
npm-audit-resolver<\/code> or a simple script that parses everypackage.json<\/code> 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\u2011sized engineering team this usually yields 200 to 500 hooks.<\/p>\nStep 2: Classify by risk profile.<\/strong> Hooks that only run local build scripts (e.g.,
node-gyp rebuild<\/code> for native extensions) are low\u2011risk. Hooks that download external scripts, make arbitrarycurl<\/code> calls, or read .env paths in plain text are high\u2011risk. Classification can be automated with simple pattern matching on the hook content, but each matching package requires a manual review.<\/p>\nStep 3: Check CI configuration for hook protection.<\/strong> npm provides the
--ignore-scripts<\/code> flag to disable all hooks during install. For CI builds this is often an acceptable trade\u2011off 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\u202fApril.<\/p>\nStep 4: Deploy a detection rule at the SIEM level.<\/strong> 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<\/code>, a deliberately trustworthy\u2011looking address. A regex that catches subdomains mimicking typical trust tools will capture similar vectors in the future.<\/p>\nWhat Breaks, What Works in a Hook Audit<\/h2>\n
The practice emerging from the Bitwarden response wave revealed clear patterns of which detection approaches succeed and which end up as theater.<\/p>\n
\n\nWhat Breaks<\/p>\n
- \n
- Detection based only on package names without inspecting hooks<\/li>\n
- SBOM maintenance without active hook classification<\/li>\n
- CI builds with active hooks and no network\u2011egress filtering<\/li>\n
- Blind trust in
npm audit<\/code>, which does not report hook behavior<\/li>\n- Manual forensics without pipeline logs from CI runs<\/li>\n<\/ul>\n<\/div>\n
\nWhat Works<\/p>\n
- \n
npm install<\/code> with--ignore-scripts<\/code> as the CI default<\/li>\n- Egress filtering on build runners against unknown domains<\/li>\n
- Hook inventory with a semi\u2011annual review cycle<\/li>\n
- SIEM rule for AES\u2011encrypted traffic in npm build contexts<\/li>\n
- Token rotation for all build pipelines with a short TTL<\/li>\n<\/ul>\n<\/div>\n<\/div>\n
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\u2019s not a hard\u2011to\u2011communicate measure; it costs hours, not days.<\/p>\n
What Sec Teams Need to Do Operationally Now<\/h2>\n
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\u202f22 between 17:57 and 19:30\u202fET 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\u2011subdomain egress into the SIEM, preferably as an alert with medium severity, because false positives exist for legitimate audit\u2011traffic subdomains.<\/p>\n
The medium\u2011term task is the hook inventory. It belongs in the NIS2 supply\u2011chain documentation because npm packages are formally suppliers of your software. The plugin\u2011acquisition wave affecting WordPress<\/a> and the Bitwarden incident are technically different but regulatorily identical: both are supply\u2011chain risks that fall under NIS2 Article\u202f21 and must be recorded in the risk register.<\/p>\n
In practice, a quarter\u2011page risk\u2011register item per supply\u2011chain path is sufficient: which build pipelines use npm in which account context, which detection layers are applied, what token\u2011rotation 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.<\/p>\n
A second layer that is often forgotten: build caching. Some npm CI setups cache\u202fnode_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\u2011incident forensics should explicitly include cache directories; otherwise a residual risk remains that can be re\u2011activated on the next build run. If you cannot selectively invalidate the cache, you should perform a full cache wipe rather than a quick patch.<\/p>\n
On the tooling side the picture has improved slightly since Q1\u202f2026. Open\u2011source 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\u2011obligation 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\u2011chain risks are no longer a pure engineering discipline but a directly measured corporate risk position. Anyone still operating in 2026 without this triple\u2011layer approach does not lack staff; they have an outdated role assignment that can be corrected operationally with a one\u2011day workshop, a board proposal and a semi\u2011annual review \u2013 without allocating an external consulting budget or waiting for the next external audit.<\/p>\n
Conclusion<\/h2>\n
The Bitwarden incident is neither the first npm supply\u2011chain attack nor the last. What makes it stand out is the clarity of the vector: the malicious code ran in a pre\u2011install 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\u2011Hulud campaign. A four\u2011step audit, CI default\u202f–ignore\u2011scripts, egress filtering and a SIEM rule are not large projects. They are the homework every DACH security department should complete in Q2\u202f2026. Waiting until the next maintainer account is compromised teaches the lesson at the cost of tokens that, without a backup, will never return.<\/p>\n
Frequently Asked Questions<\/h2>\n
Every question is locked. A tap unlocks the answer.<\/p>\n
\nAm I affected if I installed Bitwarden CLI on April\u202f22?<\/strong><\/summary>\n
Only if the installation was performed between 17:57 and 19:30\u202fET 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.<\/p>\n<\/details>\n
\nIs uninstalling the package enough?<\/strong><\/summary>\n
No. The malicious code already exfiltrated data in the pre\u2011install hook; removal only deletes the package, not the damage. Token rotation, SSH\u2011key rotation and a .env content audit are mandatory.<\/p>\n<\/details>\n
\nDoes the \u2013ignore\u2011scripts recommendation also apply to local development machines?<\/strong><\/summary>\n
Locally it\u2019s trickier, because many developer tools rely on native extensions or build hooks that won\u2019t start without them. A more practical approach is a differentiated allow\u2011list for the truly required packages plus hardening the local shell environment against unsigned egress connections.<\/p>\n<\/details>\n
\nWhich domains should security teams add to their detection watchlist?<\/strong><\/summary>\n
Subdomains that mimic typical trust\u2011tool names (audit.*, telemetry.*, sbom.*, supply.*) and appear for the first time in npm\u2011build contexts. The watchlist should be cross\u2011checked with the domains of the actual trust tools in use to reduce false positives.<\/p>\n<\/details>\n
\nWhy is this a NIS2\u2011relevant incident even though Bitwarden is a US company?<\/strong><\/summary>\n
NIS2 Article\u202f21 requires critical sectors to maintain documented supply\u2011chain risk management. npm packages and CLI tools are part of the software supply chain and therefore fall under the regulation, regardless of the provider\u2019s location. The documentation obligation applies to the German user, not the US vendor.<\/p>\n<\/details>\n
<\/p>\n
More from the MBF Media Network<\/h3>\n
![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/net-valkey-9-ga-release-redis-fork-dach-ops-8589484.jpg\")
<\/span>cloudmagazin<\/span>Valkey 9 GA: DACH Ops Teams 18 Months After Redis Split<\/span><\/span><\/a>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/net-mittelstand-digital-zentren-bmwk-foerder-67606079-250x131.jpg\")
<\/span>MyBusinessFuture<\/span>SMEs\u2018 Access to Consulting at Risk<\/span><\/span><\/a>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/net-ai-governance-2026-system-level-vorstand-12449460-250x143.jpg\")
<\/span>Digital Chiefs<\/span>AI Governance 2026: System\u2011Level, Not Excel Compliance<\/span><\/span><\/a><\/p>\n","protected":false},"excerpt":{"rendered":"93 minutes malicious bw1.js in the official npm path. What the Bitwarden CLI incident of April\u202f22 means for the DACH hook audit.","protected":false},"author":10,"featured_media":13477,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_yoast_wpseo_focuskw":"","_yoast_wpseo_title":"Bitwarden CLI Supply Chain Attack 2","_yoast_wpseo_metadesc":"Bitwarden CLI incident: 93 mins bw1.js in npm. Discover key Sec-Team lessons on preinstall hook audits to strengthen your security posture now.","_yoast_wpseo_meta-robots-noindex":"","_yoast_wpseo_meta-robots-nofollow":"","_yoast_wpseo_meta-robots-adv":"","_yoast_wpseo_canonical":"","_yoast_wpseo_opengraph-title":"","_yoast_wpseo_opengraph-description":"","_yoast_wpseo_opengraph-image":"","_yoast_wpseo_opengraph-image-id":0,"_yoast_wpseo_twitter-title":"","_yoast_wpseo_twitter-description":"","_yoast_wpseo_twitter-image":"","_yoast_wpseo_twitter-image-id":0,"_evm_slot_owner":"","evm_cvss":0,"evm_risk":0,"evm_casefile":"","evm_primary_cve":"","evm_pin_until":0,"evm_external_preview_token":"","evm_external_preview_expires":"","_evm_translation_lang":"","featured_post":0,"featured_post_sortierung":0,"_wp_old_slug":[],"footnotes":""},"categories":[255],"tags":[],"class_list":["post-13756","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-praxis-umsetzung-en"],"evm_reading_time_minutes":12,"wpml_language":"en","wpml_translation_of":13478,"_links":{"self":[{"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/posts\/13756","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/users\/10"}],"replies":[{"embeddable":true,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/comments?post=13756"}],"version-history":[{"count":3,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/posts\/13756\/revisions"}],"predecessor-version":[{"id":21463,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/posts\/13756\/revisions\/21463"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/media\/13477"}],"wp:attachment":[{"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/media?parent=13756"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/categories?post=13756"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/tags?post=13756"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Manual forensics without pipeline logs from CI runs<\/li>\n<\/ul>\n<\/div>\n
- Pre\u2011install hook is the vector.<\/strong> Malware ran automatically during npm install, AES\u2011256\u2011GCM\u2011encrypted exfiltration to audit.checkmarx.cx, a domain impersonating Checkmarx.<\/li>\n