← Back to articles

Axios x Bitwarden CLI: CTI Analysis – Two Incidents, One Attack Surface

09 June 2026
npmSupply ChainAxiosBitwarden CLICTIUNC1069TeamPCP

Introduction

Every time you run npm install, you make a trust decision. Most of the time, that decision is invisible. In March and April 2026, it was not.

When an npm package falls, the real shock is not just that a JavaScript file has been compromised. It is that the chain of trust around that package starts executing the attack on your behalf: installers, lockfiles, CI runners, developer workstations, and sometimes downstream projects that automatically redeploy the wrong version.

That is the thread connecting Axios (March 2026) and Bitwarden CLI (April 2026). Both incidents look like “classic” supply chain attacks from a distance, but a closer read reveals two distinct operational models built on the same npm entry surface. The real subject of this analysis is separating what is confirmed, what is probable, and what remains speculative – then showing what these two incidents reveal about how an npm compromise propagates through a developer’s trust graph.

What This Analysis Actually Contributes

The useful finding is not that Axios and Bitwarden are linked. It is the opposite: they do not tell the same operational story.

Axios points to a clean delivery chain, with a clearly identifiable network pivot and documented downstream propagation. Bitwarden CLI points to a chain centered on credential theft, abuse of dev/CI environments, and large-scale secret harvesting. Same attack surface, same tactical family – two distinct compromise models.

The CTI lesson is not “these campaigns might be the same thing.” The lesson is: a compromised package becomes a repeatable trust event, and that repeatability is what gives the supply chain its real power.

Why This Vector Is Structurally Hard to Contain

The pattern is simple to describe but difficult to contain: a popular npm package gets compromised, a JavaScript stager is injected, the malicious code hunts for secrets, and the attack extends into development environments, CI/CD runners, and downstream projects. The primary risk is not limited to the initial package. It extends to every machine that installs the wrong version, every lockfile that pins it, every pipeline that reinstalls it, and every secret in scope when the compromised dependency executes.

What makes these incidents effective is more precise than “lockfile + CI/CD + downstream.” They exploit workflows that reinstall and replay trust without revalidating context: a young domain, a freshly issued certificate, a short compromise window, then execution that propagates with every automated build or reinstall.

Axios illustrates propagation into downstream projects like @usebruno/cli. Bitwarden illustrates the abuse of dev/CI environments where secrets are concentrated. In both cases, the useful CTI signal is not “the package is infected” – it is “the software supply chain has itself become a repeatable attack surface.”

Unified Timeline

Axios falls first, on March 31, 2026, with the publication of two malicious versions: axios@1.14.1 at 00:21 UTC, then axios@0.30.4 at 01:00 UTC. The community alert thread GitHub #10611 is opened the same day. Microsoft Threat Intelligence publishes its analysis on April 1, 2026. The maintainer post-mortem is published on April 2, and CISA formalizes its alert on April 20.

Bitwarden CLI follows a shorter window. Version @bitwarden/cli@2026.4.0 is published on April 22, 2026 at 21:22 UTC, after a malicious workflow was injected into Bitwarden’s CI pipeline at 21:18 UTC. The distribution window for the compromised package runs from 21:57 UTC to 23:30 UTC – approximately 90 minutes – according to the official Bitwarden statement. The statement is published on April 23, 2026. Bitwarden confirms that no end user vault data or production systems were compromised.

Axios: Facts, Mechanism, Infrastructure

The technical core of the incident rests on two malicious versions – axios@1.14.1 and axios@0.30.4 – published via the compromised npm account jasonsaayman, belonging to the project’s lead maintainer. A forensic signal is directly readable in the npm registry metadata: the account email changed from jasonsaayman@gmail.com on all legitimate releases to ifstap@proton.me on the malicious ones. The attack does not modify any Axios source file. Instead, it injects a phantom dependency – plain-crypto-js@4.2.1 – whose sole purpose is to execute a postinstall hook at npm install time.

The GitHub #10611 thread lists the base IOCs: the injected dependency plain-crypto-js@4.2.1, the C2 domain sfrclak.com:8000, and the IP 142.11.206.73. Microsoft and CISA cross-reference the incident, and Google Cloud Threat Intelligence attributes it to UNC1069, with the associated malware families WAVESHAPER.V2 and SILKBELL.

What can be stated cleanly: the Axios infrastructure is coherent and identifiable – sfrclak.com, 142.11.206.73, port 8000, and the delivery chain around plain-crypto-js@4.2.1. This infrastructure confirms a compromise and a malicious delivery mechanism. It does not, on its own, prove the author. The most probable attribution, reported convergently by multiple vendors, is UNC1069 – but that is an attribution, not direct technical proof.

Real-World Impact of the Axios Compromise

The impact does not stop at the Axios package itself. The most documented downstream case is @usebruno/cli, covered by GitHub Advisory GHSA-658g-p7jg-wx5g. In practice, the most exposed environments are developer workstations, CI/CD runners, and repositories that automatically reinstall dependencies via lockfile. Thread #10611 shows that impact hunting targets node_modules directories, lockfiles, and outbound network connections to sfrclak.com / 142.11.206.73.

A compromised version can install, persist in the lockfile, and propagate silently during a subsequent redeployment or reproducible build. That silent reinstallation mechanism is precisely what makes the incident difficult to scope after the fact.

Bitwarden CLI: Facts, Mechanism, Infrastructure

Bitwarden CLI is compromised via @bitwarden/cli@2026.4.0. The entry vector is not a directly stolen npm account: the attackers injected a malicious workflow into Bitwarden’s CI pipeline by abusing a compromised GitHub Action linked to Checkmarx (checkmarx/ast-github-action). That workflow exfiltrated an npm token with publish rights, which was then used to push a pre-built malicious tarball to the registry.

The official Bitwarden statement confirms the compromised version @bitwarden/cli@2026.4.0, the incident window (21:57–23:30 UTC on April 22, 2026), and the absence of end user vault or production system compromise. Technical sources from JFrog and Endor Labs describe the execution chain in detail.

  • bw_setup.js is the primary loader. It is declared as the preinstall script and as the bin entry point in the malicious package.json. It checks for the Bun runtime, downloads it if absent, then launches bw1.js.
  • bw1.js is the obfuscated main payload, launched via Bun v1.3.13 downloaded from GitHub. Using Bun as the runtime allows execution of obfuscated JavaScript outside the standard Node.js environment.
  • The primary exfiltration endpoint is audit.checkmarx.cx – a typosquat of the legitimate checkmarx.com domain, designed to blend into network logs as routine security scanner telemetry.
  • The marker LongLiveTheResistanceAgainstMachines is also present in the code, alongside GitHub and npm pivots tied to the propagation of stolen tokens. The payload is designed to self-propagate: using recovered npm tokens, it will republish a malicious version of every package the victim can publish.

The technical artifacts confirm an execution and exfiltration chain. They do not, on their own, prove the threat actor label.

Real-World Impact of the Bitwarden CLI Compromise

The practical impact is concentrated on development and build environments. Bitwarden confirms that no end user vault data or production systems were compromised – which refocuses the exposure on the dev/CI ecosystem. The most exposed targets are machines that installed @bitwarden/cli@2026.4.0 during the compromise window (21:57–23:30 UTC), as well as CI/CD pipelines using that CLI to manage secrets, cloud access, or automation workflows.

The concern is not mass impact on end users. It is targeted exposure in environments where secrets are concentrated: GitHub tokens, AWS/GCP/Azure keys, SSH keys, environment variables. That is precisely the scope that bw1.js was designed to reach.

Attribution

Axios

Confirmed infrastructure: sfrclak.com / 142.11.206.73 / plain-crypto-js@4.2.1 / axios@1.14.1 / axios@0.30.4 / port 8000 / compromised npm account jasonsaayman.

Probable attribution: UNC1069, with WAVESHAPER.V2 and SILKBELL as associated technical families – reported convergently by Google Cloud Threat Intelligence, Microsoft, and CISA.

The rule to retain: sfrclak.com confirms an infrastructure chain. It does not prove UNC1069. Attribution is the conclusion drawn by multiple converging vendors – it is a probable attribution level, not direct technical evidence.

Bitwarden CLI

Confirmed technical artifacts: @bitwarden/cli@2026.4.0, bw_setup.js, bw1.js, bun-v1.3.13, audit.checkmarx.cx, 94.154.172.43, LongLiveTheResistanceAgainstMachines.

Probable attribution: TeamPCP / @pcpcats, reported by JFrog, Palo Alto Networks, and Endor Labs as the most consistent threat actor cluster for this campaign.

An important nuance: the link between TeamPCP and the original Shai-Hulud worm (September 2025) is inferred from ideological markers – the repo name “Shai-Hulud: The Third Coming”, and Dune-themed terms (atreides, fremen, sandworm) embedded in the code. JFrog itself notes that these thematic elements do not definitively link TeamPCP to the previous worm campaigns. Socket and SecurityWeek raise the same ambiguity: the Checkmarx attack was claimed by TeamPCP, but the Bitwarden payload carries an ideological signature that could indicate a distinct operator within the same ecosystem, or a deliberate evolution in public posture. The correct framing is therefore not “TeamPCP = Shai-Hulud” – it is: “TeamPCP is the most probable attribution for Bitwarden CLI; the link to the 2025 Shai-Hulud worm waves is suggested by thematic markers, not established by a technical pivot.”

Correlation: What Can Be Proven, and What Cannot

The strongest correlation between Axios and Bitwarden CLI is tactical, not infrastructural. Both incidents involve npm supply chain compromises, use JavaScript stagers, target developer or CI secrets, and seek to maximize downstream impact across the ecosystem. That is a genuine and meaningful commonality.

But that resemblance is not sufficient to merge the two incidents. No domain, IP, certificate, hash, or shared repository has been demonstrated between the two chains. The correct conclusion is: strong tactical correlation, unproven infrastructural correlation.

The analytical value here is not forcing a single unified campaign. It is showing that two distinct incidents can follow the same trust-abuse model without sharing the same infrastructure – and that recognizing this separation is itself a valid analytical result.

Proof of Non-Correlation

No demonstrable shared pivot was found between the two incidents. Infrastructure chains, domains, IPs, and delivery artifacts remain distinct:

  • Axios: sfrclak.com → 142.11.206.73, port 8000, plain-crypto-js@4.2.1, compromised jasonsaayman npm account
  • Bitwarden CLI: audit.checkmarx.cx → 94.154.172.43, bw_setup.js / bw1.js / Bun v1.3.13, Checkmarx CI pipeline as entry vector

Reported malware families and labels are also distinct: WAVESHAPER.V2 / SILKBELL for Axios, TeamPCP / @pcpcats for Bitwarden. No primary source documents a pivot between these two infrastructure sets.

Absence of evidence is not absolute proof of absence. But it is sufficient here to prevent over-attribution – and that is a valid analytical conclusion in its own right.

Why These Attacks Propagate So Effectively

The supply chain model works because it does not break the frontal defense: it turns it against the organization. The compromised package does not need to attack every endpoint. It just needs to enter a trust workflow that is already automated.

Three mechanisms make propagation effective. First, trust is reinstalled in a loop by builds and CI runners – every npm install replays the execution vector. Second, delivery artifacts are short-lived but easy to replay: a 90-minute or 3-hour window is sufficient to reach tens of thousands of environments given npm download volumes. Third, secrets are often in scope at the precise moment the compromised dependency executes – environment variables, CI tokens, SSH keys, cloud credentials.

In both cases studied, the operational infrastructure is minimalist: young domains, recent certificates, few exploitable pivots, a tight domain-to-IP relationship rather than a large dormant cluster. It is not network sophistication that drives these campaigns. It is their insertion into pipelines that accept execution as a reflex – without revalidating the trust context at each cycle.

Conclusion

Axios and Bitwarden CLI show the same attack terrain, but not the same operational mechanics. Axios is most strongly tied to UNC1069 via sfrclak.com / 142.11.206.73 and the WAVESHAPER.V2 / SILKBELL families. Bitwarden CLI is most strongly tied to TeamPCP / @pcpcats via audit.checkmarx.cx / 94.154.172.43 and the bw_setup.js / bw1.js / Bun chain – with a thematic link to the 2025 Shai-Hulud worm waves, inferred from ideological markers but not established by a technical pivot.

The CTI lesson is not to force a link between the two. It is to show that clean, careful, and verifiable analysis is achievable: distinguishing evidence from labels, accepting when a link is not established, and documenting clearly what is actually known – and why.

For the reader: npm supply chain attacks are not just a distribution vector. They are a mechanism that transforms software trust into an attack surface – one that replays with every build, every npm install, every pipeline that has not revalidated its dependency context.

Resources