"The framework bundles 744 modules and is built as a command framework that supports six independent command-and-control (C2) communication channels," researchers reported — a compact way to describe a multifaceted, multi-stage loader now tied to compromised packages in the @asyncapi namespace.
Compromised @asyncapi packages and versions
Four npm packages in the @asyncapi namespace were observed delivering a multi-stage botnet loader, according to findings from OX Security, SafeDep, Socket, and StepSecurity. The affected package versions are:
- @asyncapi/generator-helpers@1.1.1
- @asyncapi/generator-components@0.7.1
- @asyncapi/generator@3.3.1
- @asyncapi/specs (v6.11.2, v6.11.2-alpha.1)
All five malicious versions have since been unpublished from the npm registry. Security teams are advised to treat any endpoint that imported or executed one of these versions as potentially compromised.
Execution behavior of poisoned AsyncAPI modules
The malicious packages carried a hidden JavaScript implant: each contained an injected source file that decodes to the same second-stage downloader. Unlike prior supply-chain incidents that relied on install hooks, the injected code executes when the infected module is loaded by Node.js — the moment a build or CI job calls into the library — and not during npm install.
StepSecurity emphasized the delivery timing: "There is no preinstall/postinstall/install script anywhere in any of the three package.json files. This dropper fires when the poisoned module is require()d during normal use of the generator: the moment a build or CI job actually calls into the library, not at npm install time."
When executed, the poisoned module launches a detached background Node process that downloads an encrypted second-stage payload from IPFS.
Miasma loader, capabilities, and persistence
The second-stage payload is an encrypted JavaScript loader named "sync.js" fetched from the IPFS gateway URL ipfs[.]io/ipfs/QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9. The loader is written to operating-system-specific paths and executed; it contains two main components: an encrypted final JavaScript payload that decodes to the Miasma tasking framework, and a large encrypted blob used by a runtime "spawn-chain" framework.
Researchers report the Miasma tasking framework supports six C2 channels: HTTP, Nostr relay, IPFS, BitTorrent DHT, libp2p GossipSub P2P mesh, and an Ethereum smart contract. The framework is built as a command framework with bundled modules — the reporting notes 744 modules in total — and delivers a broad feature set including credential theft, AI tool poisoning, LAN lateral movement, and worm-like propagation across npm, PyPI, and Cargo registries.
The malware also implements multiple persistence mechanisms — systemd, crontab, macOS launchd, and Windows Registry autostart keys — and includes a dead-man's-switch that monitors a stolen token and will trigger a directory wipe if the token is revoked. The implant avoids execution on sandboxes or virtual environments, on systems whose current language is set to Russian, and on hosts with specific security products installed, including CrowdStrike, SentinelOne, Microsoft Defender, CarbonBlack, Cylance, Osquery, Tanium, and Qualys.
Researchers summarized the payload's core operational mode: the implant beacons to an HTTP endpoint, accepts encrypted tasking, and posts command results back to the same infrastructure, while also carrying support for upload transport, command ciphering, node signing, payload updates, file management, shell execution, and persistence writing.
CI/CD pipeline compromise via GitHub Actions OIDC
StepSecurity reports the attacker gained push access to the repositories and used each project's legitimate GitHub Actions release pipeline to publish the malicious packages with valid OIDC provenance attestations. The attack did not involve theft of an npm token.
Security researcher Rohan Prabhu summarized the technique: "Both attacks are CI/CD pipeline compromises, not stolen npm tokens or malicious maintainers. The attacker pushed commits under a placeholder git identity and let each repository's real release workflow do the publishing via npm's GitHub OIDC trusted-publisher integration."
Prabhu added a stark technical point about attestations: "The resulting packages carry legitimate SLSA provenance attestations, proving only that the project's authorized workflow produced them, not that the triggering commits were legitimate. Provenance does not protect against a compromised push credential."
What this means for developers, enterprise build teams, and security operations
- Developers and CI owners: Treat any endpoint that imported or executed the affected package versions as potentially compromised; exposure depends on whether the infected module was actually loaded during a build or developer workflow.
- Enterprise build and release teams: Review push credentials and the security of repository write access and CI pipelines, especially workflows that automatically publish artifacts via OIDC- or SLSA-backed release flows.
- Security operations teams: Look for indicators tied to the loader — creation of a sync.js file at OS-specific paths, detached background Node processes, unexpected HTTP beacons, and persistence artifacts (systemd, crontab, launchd, Windows Registry) — and be aware the payload avoids common analyst environments and certain security products.
The incident underscores a narrow but consequential point: a legitimate CI/CD workflow can publish malicious artifacts if an attacker can push commits that trigger that workflow. The packages in question have been removed from the registry, but the multi-stage nature of the dropper, its reliance on module loading rather than install hooks, and its sophisticated persistence and evasion measures mean affected environments deserve careful review.
