The Bitwarden CLI incident was not an isolated npm compromise. It was a downstream consequence of a broader Checkmarx supply chain attack in which TeamPCP compromised the KICS delivery path and then let trusted automation do the rest. In Bitwarden’s case, Dependabot-driven CI pulled a malicious checkmarx/kics:latest image into the build pipeline, which led to the publication of a malicious @bitwarden/cli@2026.4.0 package for roughly 90 minutes. The result was a brief but dangerous window where a trusted developer security workflow turned into a distribution path for credential theft, reinforcing the same lesson seen in the LiteLLM and Telnyx incidents: once an attacker compromises a high-trust upstream component, downstream consumers can become compromised without any direct breach of their source repository.

What Happened

In late April 2026, public reporting tied a new Bitwarden CLI compromise to the ongoing TeamPCP campaign and, more specifically, to a concurrent compromise involving Checkmarx KICS. Bitwarden confirmed that a malicious package was briefly distributed through the npm delivery path for @bitwarden/cli@2026.4.0 between 5:57 PM and 7:30 PM ET on April 22, 2026. Bitwarden also stated that the issue affected the npm-distributed CLI package during that limited window, not the integrity of the legitimate Bitwarden CLI codebase or stored vault data.

SANS ISC added the key missing link: the Bitwarden incident was a cascade from the Checkmarx KICS compromise. According to that reporting, Bitwarden’s Dependabot‑driven CI/CD automation pulled the malicious checkmarx/kics:latest Docker image into the build pipeline during the Checkmarx compromise window, and the resulting build published the backdoored CLI to npm. That makes this incident especially important for software supply chain teams because the compromise did not require a direct source‑code intrusion into Bitwarden’s repository; trusted automation and a poisoned upstream dependency were enough.

As part of this cascade, a new malicious file, bw1.js, was injected into the Bitwarden CLI package and shipped as part of @bitwarden/cli@2026.4.0, despite no corresponding change in Bitwarden’s public source repository.

This was not “Bitwarden got hacked” in the conventional sense. It was a software supply chain cascade: compromise the scanner, wait for trusted automation to consume it, and let a downstream security tool publish the attacker’s payload.

What the Attack Actually Did

The malicious version of @bitwarden/cli used the injected bw1.js file to perform post‑install or runtime credential theft behavior consistent with the broader TeamPCP campaign. Public analysis describes it as one of the more capable npm supply-chain payloads seen so far, combining credential harvesting, propagation logic, encrypted exfiltration, and persistence techniques into a single package.

1. Environment and secret harvesting: The payload collected environment variables, cloud credentials, shell history, SSH material, and other high-value secrets typically present on developer laptops and CI runners.
2. Packaging and encryption: The malware bundled stolen data into an archive and encrypted it using the same crypto patterns associated with earlier TeamPCP operations, including authenticated encryption and reuse of campaign-linked keying material.
3. Propagation and control: Reporting on the sample indicates worm-like behavior that could re-infect other publishable npm packages reachable via victim tokens, alongside a GitHub-based dead-drop command channel and persistence through shell startup modifications.

No obvious red banners. No broken build by default. No immediate reason for a developer to suspect that a password-manager CLI command had just become an outbound secret exfiltration event.

The dangerous part was not just theft. It was positioning. A compromised CLI that sits in front of secrets can become a launch point for broader CI/CD and registry abuse.

IoCs

Packages / versions

@bitwarden/cli 2026.4.0 (malicious npm release)


Known malicious file

bw1.js


Network

audit.checkmarx.cx
<https://audit.checkmarx.cx/v1/telemetry>
94.154.172.43


Timeline artifact

Exposure window: April 22, 2026, 5:57 PM to 7:30 PM ET


Build and dependency pivots

• checkmarx/kics:latest pulled into Bitwarden CI during the upstream compromise window.
• Dependabot-driven CI/CD workflow consumed the malicious upstream image before publishing @bitwarden/cli@2026.4.0.

Behavioral indicators

• Unexpected outbound HTTPS traffic immediately following bw execution.
• Access to environment variables, shell history files, SSH material, and local credential sources from the Bitwarden CLI execution context.
• Encrypted outbound transmission from hosts that installed and executed @bitwarden/cli@2026.4.0.
• Possible worm-like follow-on behavior targeting additional publishable npm packages when valid tokens were accessible.

Campaign linkage indicators

• Overlap with the broader Checkmarx KICS compromise and TeamPCP tradecraft.
• Reuse of campaign encryption and downstream CI abuse patterns described in reporting on the incident.

The Problem with Traditional Systems

Traditional tooling struggles with incidents like this because it treats dependency trust as static and shallow. A conventional SBOM can tell you that Bitwarden CLI exists somewhere in the environment, but it usually does not explain that its malicious release was itself the product of a poisoned upstream security scanner pulled automatically by a CI dependency bot. Similarly, registry signatures and package integrity checks do not help much when the attacker successfully rides the legitimate release path and publishes an “official” artifact through a trusted mechanism.

This is exactly why scanner and CI dependencies deserve the same scrutiny as production dependencies. The Checkmarx KICS image was part of a security workflow meant to improve confidence, but once that workflow was compromised it became a trusted bridge into downstream build systems. By the time the malicious Bitwarden CLI package appeared, the failure had already happened upstream, and traditional point-in-time package scanning was too late to explain the full attack path.

Security tooling is now part of the attack surface. If it runs in CI, handles credentials, or influences releases, it should be modeled as a privileged dependency, not a passive utility.

What Actually Works

Incidents like Checkmarx-to-Bitwarden are exactly where lineage, provenance, and deep dependency context matter most. Security teams need to know not just that @bitwarden/cli@2026.4.0 was bad, but why it existed, which upstream artifact introduced risk, and which downstream systems consumed it. That requires visibility across containers, CI workflows, transitive dependencies, automation tooling, and release paths rather than a flat list of packages.

For teams defending modern software factories, the practical controls are clear:

• Pin GitHub Actions and CI-integrated security tooling by immutable digest or commit SHA, not moving tags like latest.
• Reduce long-lived publish credentials in CI and migrate to trusted publishing models where possible.
• Track dependency lineage across build-time tools, container images, and automation bots so that a compromised scanner can be tied back to every downstream artifact it influenced.
• Treat short-lived malicious versions as first-class incidents; even a 90-minute exposure window is enough when the target is a widely trusted CLI used to access secrets.

The main lesson is not just “pin your dependencies.” It is that organizations need the ability to trace how a malicious upstream artifact became a downstream release, identify every affected build, and separate direct compromise from cascade impact quickly enough to contain blast radius.

The Lesson

The Bitwarden CLI incident shows how software supply chain attacks are evolving from one-off poisoned packages into cascade attacks that exploit trust relationships between scanners, CI bots, build systems, and developer tooling. Checkmarx was the upstream break. Bitwarden CLI was the downstream manifestation. The same pattern will keep repeating anywhere organizations allow privileged automation to consume mutable external dependencies without deep provenance controls.

This is also why incidents like LiteLLM, Telnyx, and Bitwarden should not be viewed as separate stories. They are variations of the same operating model: compromise a trusted upstream component, steal or inherit publishing capability, and then distribute malware through the exact channels developers are trained to trust.

The real failure is not just a bad package. It is a missing chain of custody for software, containers, and automation across the entire release path.

Lineaje Attestation provides high-integrity detection for software supply chain tampers — across all direct and transitive dependencies, at every depth. To see it in action, schedule a demo at lineaje.com.

‍