Skip to content

Back to the catalog

Coordinated AsyncAPI Supply Chain Attack: Miasma RAT Delivered via Compromised CI/CD Pipelines in Two Repositories
stepsecurity.iowriteup

Coordinated AsyncAPI Supply Chain Attack: Miasma RAT Delivered via Compromised CI/CD Pipelines in Two Repositories

On July 14, 2026, attackers compromised push access to two AsyncAPI GitHub repositories (asyncapi/generator and asyncapi/spec-json-schemas) and pushed malicious commits under a placeholder git identity that triggered legitimate CI/CD release workflows (release-with-changesets.yml, if-nodejs-release.yml), publishing five malicious npm package versions (@asyncapi/generator, generator-helpers, generator-components, specs) carrying a runtime-triggered obfuscated dropper for the Miasma RAT, complete with valid OIDC/SLSA provenance attestations. StepSecurity detected the packages within 30 minutes, used Harden-Runner in an isolated GitHub Actions job to capture the malware's C2 traffic (HTTP plus IPFS/Nostr/BitTorrent DHT fallback channels), and pushed the IOCs to their Global Block List to block exfiltration across customer pipelines; all malicious versions have since been unpublished.

TL;DR Attackers hijacked push access to two AsyncAPI repos to smuggle a Miasma RAT dropper into five npm packages via legitimate, OIDC-attested CI/CD release pipelines — proving provenance doesn't guarantee commit legitimacy.
Document

What it is

A July 14, 2026 supply-chain attack on two AsyncAPI repos (asyncapi/generator and asyncapi/spec-json-schemas) that published four malicious npm packages across five versions, each carrying an obfuscated dropper for the Miasma RAT. The clean versions to pin to are @asyncapi/generator@3.3.0, @asyncapi/generator-helpers@1.1.0, @asyncapi/generator-components@1.0.0, and @asyncapi/specs@6.11.1. The malicious versions were 3.3.1, 1.1.1, 0.7.1, 6.11.2-alpha.1, and 6.11.2.

How it works

This is a CI/CD pipeline compromise, not a stolen npm token or malicious maintainer. The attacker gained push access and pushed commits under the git default identity "Your Name" <you@example.com> (GitHub login invalid-email-address, unsigned). Those pushes triggered each repo's own legitimate release workflow, which published via npm's GitHub OIDC trusted-publisher integration:

  • asyncapi/generator: commit to the next branch triggered release-with-changesets.yml.
  • asyncapi/spec-json-schemas: commits to master triggered if-nodejs-release.yml, which fires on any push whose commit message starts with fix: or feat:.

Critically, the packages carry valid SLSA/OIDC provenance attestations — but provenance proves only that the authorized workflow built them, not that the triggering commit was legitimate. The dropper fires at library load time, not install time, so --ignore-scripts does not protect you.

What to do

  • Pin to the clean versions above; fresh installs now resolve to safe versions.
  • Audit lock files and existing installs from the exposure window (roughly 06:58–11:18 UTC, July 14) — the page states these are not safe even though the registry is clean.
  • If you use Harden-Runner, the C2 IOCs (HTTP server plus IPFS/Nostr/BitTorrent DHT fallbacks) are on its Global Block List with no config change needed.

Caveats

The spec-json-schemas master HEAD remained at the attacker's commit at publication time. StepSecurity statically decoded the payload; they executed it only in an isolated, monitored job. The page's own body says "four malicious packages" while listing five versions — count packages vs. versions carefully.

Organisations named here

  • AsyncAPI
  • @asyncapi/generator
  • @asyncapi/generator-components
  • @asyncapi/generator-helpers
  • Miasma RAT

Technologies named here

  • npm
  • GitHub Actions
  • Node.js
  • StepSecurity
  • Harden-Runner
  • @asyncapi/specs
  • asyncapi/spec-json-schemas