Compromised AsyncAPI npm Packages Deliver Multi-Stage Botnet via IPFS

Four npm packages published under the widely used AsyncAPI namespace were compromised to distribute a multi-stage botnet loader, according to coordinated research from OX Security, SafeDep, Socket, and StepSecurity.

The affected packages

The compromised versions were @asyncapi/generator-helpers 1.1.1, @asyncapi/generator-components 0.7.1, @asyncapi/generator 3.3.1, and two versions of @asyncapi/specs. All five have since been unpublished from the npm registry, but exposure depends on whether an affected version was actually loaded during a build or development workflow, since the malicious code runs when the poisoned module is required during normal use, not at install time.

What the payload does

Each compromised package carried a hidden JavaScript implant that decodes into a downloader, which launches a detached background Node process to retrieve an encrypted second-stage payload from an IPFS gateway, identified as a variant of the Miasma tasking framework. While the underlying codebase contains dormant frameworks for six independent C2 channels (including Nostr, BitTorrent DHT, and Ethereum RPC) alongside modules for credential harvesting, these features were largely toggled off in this deployment. The active footprint is focused on establishing a persistent remote shell executing arbitrary commands over a standard HTTP command-and-control channel.

Notably, the malware includes a dead man's switch that monitors a stolen authentication token and triggers a directory wipe if that token is revoked, and it actively avoids sandboxed or virtualised environments, as well as any system with security tools from CrowdStrike, SentinelOne, Microsoft Defender, CarbonBlack, Cylance, Osquery, Tanium, or Qualys installed, or with its system language set to Russian.

How the attackers actually got in

This was not a stolen npm token, nor was it a simple direct account takeover. Instead, the attacker exploited a well-known CI/CD pipeline vulnerability: a pull_request_target workflow configuration flaw in the main repository. By flooding the project with malicious pull requests, the attacker forced a workflow to run untrusted code with access to repository secrets, successfully exfiltrating a privileged GitHub personal access token. Using this stolen credential, the attacker pushed malicious code directly to the project's unprotected next branch, which automatically triggered the legitimate GitHub Actions release pipeline. The resulting packages carried valid SLSA provenance attestations, cryptographic proof that the authorized workflow produced them—proving that provenance only validates pipeline integrity, not commit integrity.

A pattern this week has made unmistakable

This is the third distinct npm-adjacent supply chain compromise we have covered this week alone, following North Korea's PolinRider campaign against npm, Go, and Chrome packages and 11 malicious NuGet packages disguised as game cheats. It also echoes a separate compromised npm build tool package that briefly shipped a cross platform infostealer before being pulled. Taken together with the 725 percent growth in malicious package volume we documented in our analysis of how AI turned script kiddies into enterprise grade threat actors, the message for any organisation consuming open source packages is consistent: the registry ecosystem is under sustained, escalating pressure, and provenance and signature checks alone are not sufficient controls.

What to do

Any endpoint that imported or executed one of the affected package versions should be treated as potentially compromised. Security teams should audit build and CI logs for the affected version ranges, rotate any credentials that may have been accessible to a compromised build process, and monitor for the specific IPFS retrieval pattern and unusual outbound connections across HTTP, Nostr, BitTorrent, and blockchain based channels described in the underlying research. More broadly, organisations should treat provenance attestations as evidence of pipeline integrity, not commit integrity, and pair them with commit level review and anomaly detection on release workflows themselves.