Miasma Worm Returns as RAT-First npm Attack With Automatic Propagation Disabled

Four AsyncAPI packages previously affected by the Shai-Hulud: The Second Coming campaign have been compromised again, with new malicious releases delivering a RAT-focused build of the Miasma worm.

The impacted versions are @asyncapi/generator 3.3.13.3.13.3.1, @asyncapi/generator-components 0.7.10.7.10.7.1, @asyncapi/generator-helpers 1.1.11.1.11.1.1, and @asyncapi/specs 6.11.26.11.26.11.2 and 6.11.2−alpha.16.11.2-alpha.16.11.2−alpha.1.

Unlike the prior Miasma activity, the AsyncAPI packages do not use malicious preinstall, install, or postinstall lifecycle hooks.

Instead, the attackers inserted an approximately 7.77.77.7 KB obfuscated launcher into legitimate JavaScript source files. The code executes when CommonJS loads the compromised module, meaning installation alone does not prove execution.

This design may help attackers evade protections introduced in npm v12 that block package scripts by default.

It also complicates incident response: a lockfile, local cache, or container image containing an affected version is not necessarily compromised, but any developer endpoint, CI runner, documentation workflow, or build system that imported the poisoned code must be treated as potentially exposed.

Once triggered, the injected launcher spawns a detached node -e child process, downloads sync.js from an IPFS gateway, and stores it in a plausible user-profile NodeJS directory.

The payload is retrieved through the IPFS CID QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9.

JFrog’s analysis found that the downloaded 8.258.258.25 MB wrapper decrypts into a 3.093.093.09 MB bundled Node.js application marked as Miasma v3.

The payload uses HKDF-SHA256, AES-256-GCM, and a printable-ASCII ROT transformation to conceal its code and configuration.

The active configuration identifies the operation as miasma-train-p1 and enables persistence, encrypted command-and-control communications, arbitrary shell command execution, and remote payload replacement.

Its primary C2 infrastructure is 85[.]137[.]53[.]71 on ports 808080808080, 808180818081, and 809180918091.

JFrog researchers said the releases contain Miasma v3, a payload family recently documented in attacks against @redhat-cloud-services npm packages.

Miasma Worm Returns as RAT

Crucially, automatic propagation is disabled. The malware framework includes modules for credential theft, npm and PyPI poisoning, GitHub repository abuse, AI-tool poisoning, and metamorphic mutation, but JFrog found these features set to false in the observed build.

The campaign should therefore be characterized as a RAT-first deployment of the broader Miasma framework, not an actively self-spreading npm worm.

That distinction does not reduce the severity. The enabled ShellExec capability allows operators to run commands for up to 120120120 seconds and capture their output.

A compromised developer workstation or CI environment could expose source code, npm tokens, GitHub credentials, cloud identities, SSH keys, signing materials, and deployment secrets.

Miasma v3 also attempts user-level persistence across major operating systems. It creates a miasma-monitor. service systemd user service on Linux, adds a miasma-monitor Run key on Windows, and modifies macOS shell startup files with a ### Node Auto-Update Script ### marker.

It stores victim-specific cryptographic identity data in masquerading cache paths and may send the X-Miasma-Spawn-Chain HTTP header, providing defenders with a valuable network detection signal.

The malicious releases were reportedly published through AsyncAPI’s legitimate GitHub Actions release workflow using npm’s OIDC trusted-publisher mechanism.

Consequently, the packages carried valid provenance attestations. The incident demonstrates that provenance confirms which workflow produced a package, but cannot establish whether the source commit entering that workflow was authorized.

Organizations should identify affected versions across lockfiles, caches, CI records, generated artifacts, and container images; determine whether poisoned modules were loaded; and isolate systems where execution occurred or cannot be excluded.

Defenders should block the malicious IPFS CID and C2 infrastructure, remove persistence artifacts, rotate credentials accessible to exposed environments, and rebuild systems where full forensic scoping is not possible.

IOCs

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Stop Accepting SLAs Written for 2019 SOCs – Here’s the 2026 AI SLA Vendor Checklist – Download Free AI SOC SLA Guide