Skip to main content
Emerging ThreatsSupply Chain Attacks

Malicious AsyncAPI Packages Target npm Users with Credential-Stealing Malware

Compromised software development environment with laptop and papers, hinting at a supply-chain intrusion.

“Both attacks are CI/CD pipeline compromises, not stolen npm tokens or malicious maintainers,” Step Security wrote, summing up a supply‑chain intrusion that briefly put trojanized AsyncAPI packages into the Node Package Manager (npm) ecosystem on July 14.

Packages, download footprint, and the exposure window

Five malicious releases in the @asyncapi namespace reached npm during a roughly four‑hour window on July 14. The exposure window extends approximately four hours and seven minutes, between 07:10 and 11:18 UTC. The compromised releases and their weekly download figures were:

  • @asyncapi/generator 3.3.1 — 101k weekly downloads
  • @asyncapi/generator-helpers 1.1.1 — 43k weekly downloads
  • @asyncapi/generator-components 0.7.1 — 34k weekly downloads
  • @asyncapi/specs 6.11.2-alpha.1 and 6.11.2 — 2.1 million weekly downloads

Combined, the trojanized packages had a cumulative weekly download count of more than 2.25 million. As of this writing, those five versions have been removed from npm, but the published advisory warns that existing installations and lock files created during the exposure window may still contain the malicious releases.

How the attacker used GitHub Actions and SLSA attestations

Multiple security companies confirmed that the intrusion began with two compromised AsyncAPI GitHub repositories. According to Step Security, the attacker exploited a misconfigured GitHub Actions workflow and pushed commits under a placeholder git identity. Rather than relying on stolen npm tokens or a malicious maintainer, the attacker allowed each repository’s real release workflow to perform the publishing via npm’s GitHub OIDC trusted‑publisher integration.

That sequence produced legitimate SLSA provenance attestations on the published packages — metadata indicating the packages came from an authorized workflow — even though the commits themselves had been injected by the attacker.

Malware architecture: staged delivery, IPFS retrieval, and a large final payload

Security firms pieced together a multi‑stage infection chain. Socket reported that the immediate implant is an obfuscated JavaScript statement that triggers a downloader when the infected module is imported. The downloader retrieves a second‑stage script from the IPFS peer‑to‑peer content delivery network and launches it as a hidden process.

Wiz described the third‑stage payload as “a 92,000‑line malware framework with modular architecture.” That final payload establishes persistence and communicates with command‑and‑control infrastructure over multiple channels: HTTP, Nostr relays, Ethereum smart contracts, and a libp2p mesh network.

SafeDep researchers observed artifact names and configuration files pointing to the Miasma backdoor seen in prior supply‑chain incidents, but concluded the code is “either a private, parallel build by the same operators or a separate group that adopted the Miasma brand after the source was published.” The malware’s apparent purpose is credential and secret theft — credentials, authentication keys and tokens, browser data, CI/CD and AI developer tool secrets, cryptocurrency wallets, and databases — and it can download tools such as Gitleaks and HackBrowserData to aid collection.

Functional testing, geofencing, and researcher caveats

Not every security team saw a fully operational data‑harvesting tool. Aikido reported that many of the automated collection functions “do not work” and that the data‑harvesting component exits before collecting anything; however, Aikido added, the same collection could be carried out manually via an interactive shell. Ox Security noted the malware performs a local check for Russia and terminates its process if there’s a match.

Exposure mitigation: immediate steps and residual risk for developers and security teams

Responders and the published guidance recommend concrete steps: pin dependencies to known‑good files, regenerate lock files, remove the hidden NodeJS/sync.js payload from infected hosts, terminate malicious processes, and rotate credentials on impacted systems. Those steps are aimed at both removing active implants and eliminating poisoned dependency records that would reinstall the trojan on subsequent builds.

Although npm removed the malicious versions, the presence of legitimate SLSA attestations tied to an authorized workflow — created after the attacker pushed commits into the repository — illustrates how a compromised CI/CD pipeline can grant an attacker the same provenance metadata trusted tools and auditors look for.

For organizations that rely on open‑source packages, the AsyncAPI incident is a clear, concrete demonstration: pipeline integrity is now a front‑line control. Provenance attestations remain valuable, but this event shows they can be obtained by an attacker who controls the workflow. That reality shifts some of the defensive burden back onto tight GitHub Actions configurations, rigorous secret and OIDC controls, and the ability to detect anomalous commits and hidden processes on build and developer systems.

Original story