AsyncAPI npm Supply Chain Attack: No Token Stolen

The AsyncAPI npm supply chain attack shows that neither of the two controls teams were told to trust — cryptographic provenance and blocking install scripts — actually stopped it: an attacker published four trojanized packages with valid SLSA/OIDC provenance attestations, without ever stealing an npm token, and the payload runs regardless of --ignore-scripts.

What Happened

On July 14, between 07:10 and 08:30 UTC, an attacker who had gained push access to the unprotected next pre-production branch of the AsyncAPI generator monorepo let the project’s own legitimate GitHub Actions release workflow publish malicious versions of four packages: @asyncapi/[email protected], @asyncapi/[email protected], @asyncapi/[email protected], and @asyncapi/specs. The project’s main branch carried strict protections and mandatory peer review; the release branches did not. Because the packages were published through the project’s real CI/CD pipeline, they carry valid npm OIDC and SLSA provenance attestations — the exact signal security teams use to confirm a package’s origin is trustworthy. No npm publishing token was stolen at any point.

Combined weekly downloads across the four affected packages exceed 2.9 million, with @asyncapi/specs alone accounting for 2.7 million. The injected payload executes at module import/require time rather than during installation, so the common npm install --ignore-scripts mitigation does not neutralize it. Once loaded, it downloads Miasma RAT from IPFS and harvests browser data, SSH keys, npm and GitHub CLI tokens, AWS credentials, and cryptocurrency wallets. All malicious versions have since been unpublished; the current clean releases are [email protected], [email protected], [email protected], and [email protected].

Why It Matters

AsyncAPI tooling is widely used to document and generate code for event-driven APIs, including in microservices and IoT architectures common in DACH software and manufacturing engineering teams. This attack is significant less for its scale than for its method: it defeats supply-chain provenance verification and install-script blocking at the same time, using nothing more exotic than an unprotected branch that nobody thought to lock down because “nothing runs from there in production” — except the CI/CD pipeline runs from exactly there. Under NIS2, software supply-chain risk management is an explicit obligation for regulated entities, and this case is a concrete example of why a “provenance verified” badge alone is not sufficient assurance.

What You Should Do Now

1. Immediate: Check whether any of your projects installed @asyncapi/generator, generator-helpers, generator-components, or specs at a version published between July 14, 07:10–08:30 UTC. If so, treat the affected build or developer machine as compromised and rotate npm tokens, GitHub CLI tokens, SSH keys, AWS credentials, and any browser-saved passwords on it.
2. Verify: Run npm ls @asyncapi/generator @asyncapi/generator-helpers @asyncapi/generator-components @asyncapi/specs across your repositories and lockfiles to confirm you are on the clean releases (3.3.0 / 1.1.0 / 1.0.0 / 6.11.1) or later.
3. Mitigate: Do not rely on --ignore-scripts for this class of attack — it does not help against import-time payloads. Pin exact dependency versions and use npm ci with lockfile integrity checks instead.
4. Monitor: Review outbound traffic from build and CI machines for IPFS gateway connections (unusual for most pipelines), and audit npm/GitHub token activity logs for anomalous publishes or API calls in the affected window.

DIESEC Perspective

Provenance attestations prove where a package came from, not that the branch it was built from was safe to trust — and we see the same blind spot repeatedly in Mittelstand CI/CD setups: teams lock down the main branch and assume release or staging branches are lower-risk simply because they are not “production,” while the pipeline treats them as production the moment it publishes from them.

Not sure whether your build pipeline pulled a poisoned AsyncAPI package, or whether your own branch protection has the same pre-production gap? Contact DIESEC for a rapid dependency exposure check and CI/CD branch-protection review.

Sources: Microsoft Security Blog | Socket.dev
Published: 2026-07-21 | Category: Supply Chain Security | ~4 min read