Supply Chain Warning: Bitwarden CLI Compromise in Checkmarx Campaign
Just saw the report from JFrog and Socket regarding the Bitwarden CLI compromise. It looks like the package @bitwarden/cli version 2026.4.0 is the culprit in this new Checkmarx supply chain campaign.
The malicious payload was delivered via a file named bw1.js included in the package contents. Given how many of us use the CLI for syncing secrets in CI/CD pipelines, this is a major issue. If you are running this version, the malicious code is likely executing immediately upon import. The attack vector is particularly concerning because the CLI tool often runs with high privileges to access system keychains or environment variables.
I recommend running an audit on your node_modules immediately:
npm audit
If you want to specifically hunt for the affected file in your local projects:
find . -name "bw1.js" -type f
For those with Bitwarden CLI baked into Docker images, you must rebuild your images immediately using a pinned safe version. We are currently enforcing stricter dependency pinning in our package. and strictly using package-lock. to prevent these silent upgrades, but it's not foolproof if the lockfile gets updated accidentally.
Are teams enforcing private registries like Artifactory for internal tools to scan packages before they hit the dev environment, or are we still relying on the public npm registry for critical security infrastructure?
We pushed a detection rule for this immediately. We're hunting for any processes spawning from node that reference bw1.js.
Here is the KQL we're using in Sentinel:
DeviceProcessEvents
| where FileName has "node.exe" and ProcessCommandLine contains "bw1.js"
Also, check for any anomalous outbound network connections from your build agents shortly after CLI execution.
Thanks for the heads-up. Another quick mitigation is to downgrade to the last known good version immediately via command line if you are stuck:
npm install @bitwarden/cli@2026.3.0 -g
We’re also looking into `npm ci` for deployments as it respects the lockfile strictly, preventing these "latest" tag surprises.
This is exactly why we moved to vendor-locking our supply chain tools. For clients using Bitwarden, we're pushing a script to check versions via PowerShell:
npm list -g @bitwarden/cli
If it reports 2026.4.0, we're disabling the service and forcing a reinstall. Has anyone seen the actual payload behavior? Is it exfiltrating vault data?
Solid advice. For those who can't immediately run package managers or want to verify if the artifact was actually dropped, scanning the filesystem for the specific payload file is a reliable triage step. This confirms the presence of the compromise without relying solely on version metadata. You can run this on your CI/CD runners or local dev machines:
find / -name "bw1.js" -path "*/node_modules/*" -type f 2>/dev/null
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access