Security alert: compromised @ asyncapi npm packages fire the malicious Miasma framework during building and CI flows

Security investigators have identified a supply chain engagement campaign that affected several npm packages of name space @ asyncapi, and that they distributed a charger in several stages that leads to an advanced malicious framework known as "Miasma." The affected packages included specific versions of @ asyncapi / generator-helps, @ asyncapi / generator-components, @ asyncapi / generator and @ asyncapi / specs; those packages contained an injected file that, when loaded by Node.js with required (), executed a first obfuscated payload that downloaded from IPFS a second encrypted stage called "sync.js." The observed download resource was published on the public gateway: ipfs.io / ipfs / QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9.

The infection chain described above does not depend on installation hooks (pre-install / post-install) but on the load in running time: the malicious code is activated when the infected bookstore is required () d during a build or in a CI workflow. This difference is crucial for detection and response, because a simple npm install that does not charge the library may not activate the execution, while a compilation or a CI job that matters the module will.

The "sync.js" loader houses two components: one is the encrypted final payload JavaScript containing the Miasma framework and another is a large encrypted structure used by the runtime to run process chains. The reported framework packs hundreds of modules and supports multiple control and control channels, including HTTP REST, Nostr relays, IPFS, BitTorrent DHT, libp2p GossipSub and even an intelligent contract in Etheum. Its capabilities include the theft of credentials, the poisoning of IA tools, the lateral movement of LAN and the spread of worm to records such as npm, PyPI and Cargo, as well as mechanisms of persistence in systemd, crontab, launchd and Windows registry keys.

The analysis also shows mature operational functions: encryption of communications and tasks, file uploading transport, signature of nodes and remote update of payloads. The malware includes a "dead man's switch" mechanism that monitors a stolen token and can activate a deleted directories if the token is revoked, and avoids systems that look like sandboxes, virtual machines, Russian-configured equipment or those with specific security software installed (e.g. CrowdStrike, SentinelOne, Microsoft Defender and others), which indicates intention to stay operational in real environments and avoid analysis.

An important operational point that distinguishes this intrusion is the publication vector: according to the teams involved in the investigation, the attacker gained access to push the repositories and used the legitimate GitHub Actions flows of the project, publishing packages through the integration of GitHub's OIDC for npm. This produced packages with valid SLSA and OIDC attestations, which shows that the buildings were made by an authorized workflow, but does not guarantee that the members who activated it were legitimate. In other words, the presence of evidence of origin SLSA does not replace strict control over who can push and what commitments are accepted.

The malicious versions have already been removed from the npm record, but the damage may have materialized in any endpoint that has imported and executed those modules in buildings, development environments or CI jobs. Any system that loaded the affected versions should be treated as potentially compromised and not to assume security due to the absence of installation scripts in package.json.

For teams and managers, the immediate actions recommended are to isolate and preserve artifacts if they suspect execution, to audit dependencies and build, and to look for concrete indicators: to track in the lockfiles and in the tree of dependencies affected versions of @ asyncapi; to search in repositories and in the code base called to require () on these packages; to detect child Node.js processes that are executed in the background and files called "sync.js" written on specific routes of the system; to verify the presence of systemd units, crontab entries, launchd and Rkeys recently created in the Windows Registry. It is also appropriate to block at the network level the known CID / IPFS and the gateway involved to prevent future downloads: in addition to the previous IPFS link, organizations can apply egress controls for public gateways.

At the level of supply chain prevention, it is key to restrict who can modify repositories and which workflows can publish artifacts. Review branch protections, force human reviews before they shoot releases, audit the secrets and credentials of push to the repository, and limit the identities of GitHub Actions with minimum permissions. Note that the OIDC / SLSA tests confirm that the build was produced by the trusted workflow, but does not replace control of the integrity of the repository or the protection of push credentials. Useful documentation on the OIDC model in GitHub and on the SLSA initiative is available from official resources: GitHub - OIDC for GitHub Actions and SLSA (Supply-chain levels for Software Artists).

In the response and mediation phase, it is appropriate to combine technical and process measures: to revoke and rotate exposed credentials, to review and replace packages committed by clean or reconstructed versions from verified sources, to rebuild release devices in controlled environments and to check hashes, and to run forensic analysis on suspected endpoints with EDR / antimalware to detect exfiltrations, persistences and modules loaded by Node.js. To reduce future risk, implement continuous unit scanning, release signing and policies that limit automatic publication without revision of the code that triggers the workflow.

This incident stresses that confidence in the supply chain is conditioned: the guarantees of workflow and signature facilitate traceability, but do not replace the need for access controls, human review and performance monitoring. If your organization used any of the compromised versions, it acts as if there had been a compromise: it hovers, investigates and recovers from clean sources, and takes advantage of the lesson to tighten controls on repositories and CI / CD.