Listen to this Post
Introduction:
A sophisticated supply chain attack has compromised the popular Bitwarden CLI package on npm, turning a trusted password management tool into a credential‑harvesting worm. Attackers hijacked the package’s publishing pipeline through compromised GitHub Actions secrets, injecting malicious code that executes on installation to steal API keys, cloud credentials, and CI/CD tokens.
Learning Objectives:
- Analyze the attack mechanics, from malicious `preinstall` scripts to fallback exfiltration via GitHub repositories.
- Identify compromised indicators including specific file hashes, exfiltration domains, and anomalous npm behaviors.
- Implement proactive defenses, incident response steps, and post‑compromise recovery procedures for your development environments.
You Should Know:
1. Attack Chain & Technical Deep Dive
The compromise begins with the npm package @bitwarden/[email protected], which preserves legitimate Bitwarden metadata but alters its execution path. The `package.json` script `”preinstall”: “node bw_setup.js”` triggers the initial payload. The `bw_setup.js` bootstrapper downloads the Bun runtime from GitHub (github.com/oven-sh/bun) if not present, then executes `bw1.js` – a 10 MB obfuscated Bun bundle. The `bw1.js` payload harvests local file system secrets (SSH keys, shell history, .npmrc, AI tool configs), environment variables (cloud credentials, GitHub tokens), and GitHub Actions runner contexts. Exfiltration happens via a primary HTTPS POST to `audit[.]checkmarx[.]cx/v1/telemetry` (resolving to 94.154.172.43) and a fallback method that creates a new GitHub repository under the victim’s account using stolen PATs to upload encrypted result blobs.
The attack exploits compromised CI/CD credentials, likely from the ongoing TeamPCP‑style campaign that previously targeted Trivy and other npm packages via stolen npm tokens and GitHub Actions secrets. The malicious package uses self‑propagation logic that increments the patch version and republishes infected packages using stolen npm authentication tokens, turning it into a spreadable worm.
2. Detection & IOCs (Indicators of Compromise)
To detect if your environment has been impacted, compare the installed package’s manifest. The malicious version differs from the legitimate baseline `2026.3.0` by adding `bw_setup.js` (SHA256: f35475829991b303c5efc2ee0f343dd38f8614e8b5e69db683923135f85cf60d) and `bw1.js` (SHA256: 18f784b3bc9a0bcdcb1a8d7f51bc5f54323fc40cbd874119354ab609bef6e4cb), and modifes the `bin` entry point. Monitor network egress for connections to `audit.checkmarx.cx` or the IP 94.154.172.43, and watch for unexpected outbound HTTPS to GitHub API (api.github.com) from build environments. Additionally, scan for new, unexpectedly created GitHub repositories on your personal or organization account that have names following predictable patterns (e.g., containing your username and a random suffix). The payload also attempts to run the `gh auth token` command; unexpected invocations of GitHub CLI or npm token commands in CI logs should be treated as suspicious.
3. Step‑by‑Step Mitigation: Hardening npm & CI/CD Pipelines
Step 1: Block Lifecycle Scripts During Installation
Prevent preinstall, postinstall, and `install` scripts from executing inside your CI pipelines. In your pipeline environment variables, add:
NPM_CONFIG_IGNORE_SCRIPTS=true
or use the `–ignore-scripts` flag with npm install. For more granular control, use the `npm pkg set scripts.preinstall=”exit 0″` to explicitly nullify known problematic scripts. Audit your `package-lock.json` after every dependency change to detect newly added install hooks.
Step 2: Enforce Strict Dependency Pinning & Integrity Checks
Pin all npm dependencies to exact versions and use lockfiles: `npm install –package-lock-only –no-package-lock` is insufficient. Instead, use:
npm ci --ignore-scripts
The `npm ci` command respects the lockfile and fails if it doesn’t match package.json, preventing drift. Additionally, compute and store expected integrity hashes for critical packages using npm audit signatures. For GitHub Actions, pin each action to a full commit SHA (not tags or major versions):
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 v4.1.1
Step 3: Rotate and Least‑Privilege All CI/CD Secrets
Assume any secret exposed during the infection window is compromised. Immediately rotate:
– All npm tokens (generate new tokens with limited granular permissions, never with read/write on all packages)
– GitHub personal access tokens (use fine‑grained tokens scoped only to specific repos and actions)
– Cloud provider keys (AWS, GCP, Azure) – revoke affected access keys and replace them.
– SSH keys that were present in the environment where the malicious package was installed.
Step 4: Implement Secure Supply Chain Controls
Add automated scanning to your CI pipeline that detects typosquatting and known malicious packages before installation. Tools like `supply-scan` (GitHub: jtsilverman/supply-scan) and `aegis` flag suspicious packages that `npm audit` misses. For GitHub Actions, enforce strict permissions at the workflow level:
permissions: contents: read id-token: write
Only elevate permissions (write or contents: write) on specific jobs that require them, and never grant `GITHUB_TOKEN` write permissions globally.
Step 5: Isolate Build Environments and Use OIDC
Replace long‑lived credentials with OpenID Connect (OIDC) for authenticating to cloud providers. This eliminates static secrets from CI environment variables. For GitHub Actions, configure the cloud provider (AWS, GCP, Azure) to trust the GitHub OIDC issuer. Example for AWS:
- name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::123456789012:role/github-actions-role aws-region: us-east-1
Never store cloud keys as GitHub secrets or in .npmrc.
4. Incident Response: The Bitwarden CLI Compromise
If you suspect the malicious package was installed:
- Immediately isolate the affected machine or build runner from the network to prevent further exfiltration.
- Revoke all secrets that were present in the environment (see Step 3) and assume they are public.
- Review GitHub audit logs for unauthorized access, especially API calls creating new repositories or modifying `package.json` of other projects. Look for `package_version:2026.4.0` references in your `package-lock.json` and logs.
- Rotate npm tokens for all maintainers who may have run `npm install` during the compromise window.
- Check your CI pipeline logs for unexpected `curl` commands or outbound POST requests to the IP
94.154.172.43. - Use the official Bitwarden advisory to determine if your version was affected, and update to `2026.4.1` or later using the official npm registry (but first verify the package integrity with SHA256).
5. Advanced Threat Hunting & Forensics
For deeper analysis, extract the `bw1.js` payload from a quarantined artifact. The file is highly obfuscated, but static analysis can reveal the string table and decoder function. Use the deobfuscation method documented in the JFrog analysis: the string table is returned by _0x1ee1(), decoded by _0x214e(). Running the script in a controlled sandbox (e.g., using `bun run` inside a Docker container with no network access) will allow you to observe its behavior without exfiltration. The payload also includes a fail‑safe mechanism: if primary exfiltration fails, it will attempt to exfiltrate using GitHub API with staged personal access tokens. Hunting for these tokens in public GitHub commits may reveal other compromised accounts.
6. Long‑Term Hardening for npm Eco‑System
Implement the following defensive strategies across your organization:
- Use private npm registries (e.g., GitHub Packages, AWS CodeArtifact) with allow‑listing of approved packages and versions.
- Mandate two‑factor authentication for all maintainers publishing to npm scopes.
- Set up automated security scanning with tools like `Socket.dev` to detect dynamic code execution and dependency confusion.
- Adopt a zero‑trust model for pipelines: never check out code from untrusted forks without manual review, and use dedicated runner groups with isolated networks.
- Regularly update your base images and restrict outbound internet access from CI runners, allowing only necessary domains (e.g.,
registry.npmjs.org,api.github.com, your cloud’s metadata endpoint).
What Undercode Say:
- Key Takeaway 1: Any npm package, even from a trusted brand, can be weaponized if the publishing pipeline lacks cryptographic signing and strict CI secrets hygiene.
- Key Takeaway 2: The shift to Bun runtime payloads marks an evolution in evasion – defenders must monitor for out‑of‑band binary downloads and non‑Node execution in build phases.
- The attack vector – stolen GitHub Actions secrets – underscores the fragility of current CI/CD security defaults. Least privilege, short‑lived credentials, and OIDC are not optional anymore.
- The fallback exfiltration method using the victim’s own GitHub account is particularly insidious because it bypasses traditional network‑based detection and blends into normal API traffic.
- Most importantly, the self‑propagation mechanism (publishing infected packages from a compromised maintainer’s token) turns a single breach into a cascade that can poison the entire ecosystem.
- Even if you never used Bitwarden CLI, your dependencies might pull a compromised version transitively if it is listed as a dependency of another package – supply chain visibility is paramount.
- Traditional antivirus and EDR tools will miss this because the malicious code lives entirely in the build process (not a persistent binary) and executes only during the install phase.
- Organizations using GitHub Actions must immediately audit their workflow permissions and enforce `–ignore-scripts` for all third‑party installations.
- The use of public GitHub infrastructure for both payload delivery (Bun binary) and exfiltration (new repos) shows how attackers leverage trusted services to evade blocklists.
- This incident is a stark reminder that security controls must extend to every phase of the developer workflow – code review, dependency acquisition, build execution, and artifact publishing.
Prediction: In the coming months, we will see increased targeting of AI‑assisted development toolchains (e.g., VSCode extensions, Copilot configurations) and the emergence of “wormable” supply chain attacks that not only steal credentials but also tamper with model training data or poisoned datasets. Expect regulatory bodies to mandate cryptographic signing for package releases and real‑time integrity monitoring for all open‑source registries. Organizations that fail to adopt pipeline‑level sandboxing will continue to be prime targets.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Hackermohitkumar Warning – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
