Socket has identified a software supply chain attack involving compromised AsyncAPI npm packages distributing a Miasma botnet loader.
According to the company’s Threat Research Team, versions of packages inside the @asyncapi namespace have been found shipping an obfuscated first-stage implant.
The compromised packages are:
- @asyncapi/generator-helpers@1.1.1
- @asyncapi/generator-components@0.7.1
- @asyncapi/generator@3.3.1
- @asyncapi/specs (at both versions 6.11.2 and 6.11.2-alpha.1)
Socket AI Scanner reports the generator-helpers release as confirmed malware. Analysis indicates that the releases immediately preceding these compromised versions contain none of the primary-stage signatures.
A key aspect of this attack is its evasion strategy. The malicious code is embedded directly inside legitimate source files rather than relying on package lifecycle scripts. When any piece of Node.js code requires one of the infected modules, the implant activates immediately at load time.
Upon loading, it spawns a detached background process using node -e that downloads the subsequent stage. This design ensures that standard install hooks or install-script blockers offer zero protection. Any developer machine, CI runner, test suite, or application path that imports the module becomes the execution point.
Weaponising the ‘trusted publishing’ loophole
The malicious packages were published on 14 July 2026 in two distinct waves. The generator-related packages were pushed within seconds of each other at approximately 07:10 UTC, while the two @asyncapi/specs releases followed an hour later.
Worryingly, npm metadata attributes every publish to the GitHub Actions identity used for trusted publishing. The three generator packages share identical metadata: the same Node.js version, npm version, source commit, repository, branch (next), release workflow, and Actions run identifier. While Socket notes that public GitHub API calls for the workflow run and job logs returned 404 errors during analysis, provenance confirms the origin from a GitHub-hosted runner.
The underlying source files were already fully poisoned within a public commit that the trusted-publishing workflow later built and released. The commit itself lists the author and committer as ‘Your Name’ with a placeholder email, showing an invalid-email-address GitHub user association.
Multi-stage execution architecture
The infection chain deploys in three highly-obfuscated stages:
Stage 1: The initial implant: The first stage consists of a single heavily-obfuscated statement dropped into the package source. Deobfuscation reveals strings describing a Node child-process spawn configured with detached, unref, ignore, and windowsHide flags to maintain stealth. The child process receives a second-stage downloader as an argument to node -e.
Stage 2: The downloader: The downloader URL points to an IPFS gateway serving a file named sync.js. It targets platform-specific directories specifically chosen to mimic ordinary Node.js runtime locations:
- Windows: LocalAppData\NodeJS
- macOS: Application Support/NodeJS
- Linux: .local/share/NodeJS or .config/node
Once written, another detached node process initiates the 8.25 MB sync.js file.
Stage 3: Miasma payload decryption: The sync.js loader serves as a decryption wrapper utilising HKDF-SHA256 and AES-256-GCM alongside a character rotation step. Upon successfully decrypting its embedded ciphertext blobs, the loader evaluates 3.09 MB of JavaScript.
The Miasma botnet framework
The decrypted payload self-identifies as a tasking framework belonging to the Miasma family. It utilises configuration values such as a target name of miasma-train-p1, state directories under .config/.miasma, and a service named miasma-monitor. To remain hidden, camouflage paths reuse mesa_shader_cache directories.
The configuration specifically marks the npm ecosystem as the active target, leaving propagation modules for PyPI, Ruby, and Cargo currently disabled.
The command-and-control (C2) infrastructure centers on a single IPv4 address hosting REST endpoints on ports 8080, 8081, and 8091. The supporting code includes dormant modules for Nostr relays, IPFS, Ethereum RPC lookups, libp2p, BitTorrent DHT bootstrap nodes, and local mDNS discovery.
Dynamic testing of the payload confirmed that handlers for file listing, retrieval, writing, shell execution, payload updates, and beacon-interval updates are all functional. The shell blacklist is sparse (only restricting the command killall) leaving most shell activity unrestricted. On Linux, persistence is achieved by writing a systemd user unit that launches a background Node process as miasma-monitor, followed by issuing daemon-reload and enable commands.
Exposure criteria and remediation
Socket notes that merely holding the affected packages in a lockfile does not automatically compromise a host. Exposure specifically requires that application, test, CLI, or build code has imported the infected source file. When this cannot be ruled out, the host must be treated as exposed.
Smply removing node_modules will not reverse the compromise. Residual artifacts from a second or third stage execution can include:
- A background Node process
- The installed sync.js file
- A .miasma lock file
- Camouflaged cache files
- Residual spawn-chain data
- An active systemd user service
Organisations relying on AsyncAPI tooling need to audit their dependency trees for the listed versions and either pin to clean versions or apply patches as they become available. Security teams should concurrently review GitHub organisation audit logs for pushes resulting in commit 3eab3ec9304aa26081358330491d3cfeb55cc245 on the next branch.
Any CI runners that imported the packages require a forensic inspection against Socket’s published indicators, which include traffic to 85.137.53.71, unexpected IPFS/Nostr/DHT/Ethereum RPC traffic originating from build agents, and the presence of miasma-named systemd user units.
Automation tools can only surface these indicators; the burden of confidence thresholds, credential rotation, and remediation strategy rests with internal security and engineering teams.
See also: Developers face RCE via Claude Code ‘auto-mode’ exploit
Want to learn more about cybersecurity from industry leaders? Check out Cyber Security & Cloud Expo taking place in Amsterdam, California, and London. The comprehensive event is part of TechEx and is co-located with other leading technology events including the AI & Big Data Expo. Click here for more information.
Developer is powered by TechForge Media. Explore other upcoming enterprise technology events and webinars here.
