The AsyncAPI npm Attack: Malware That Fires at Import, Not Install

The AsyncAPI npm supply chain attack of July 14, 2026 trojanized four packages — anchored by @asyncapi/specs and its 2.66 million weekly downloads — with a payload that executes the moment the module is imported. No install script. No postinstall hook. Nothing for npm 12's new default protections, shipped just six days earlier, to block.

That timing is the story. On July 8, npm 12 turned off install scripts by default and the ecosystem exhaled — the attack vector behind most of 2025's headline compromises was finally closed at the platform level. Six days later, an attacker demonstrated the counter-move: skip the lifecycle hooks entirely and detonate at module-load time, when a build, test suite, CLI run, or production app first calls require or import on the poisoned code.

This guide covers what happened hour by hour, why install-time controls structurally cannot catch this class of attack, the three-stage anatomy of the malware, the CI misconfiguration that made it possible, and — the part you can act on — a defense-layer matrix mapping every common mitigation against the specific attack stages it would or would not have interrupted.

On the morning of July 14, 2026 (UTC), five malicious versions landed across four packages in the @asyncapi npm namespace: @asyncapi/specs v6.11.2 and v6.11.2-alpha.1, @asyncapi/generator v3.3.1, @asyncapi/generator-components v0.7.1, and @asyncapi/generator-helpers v1.1.1. Socket.dev's registry-metadata inspection puts the first publish at 07:10:42 UTC and the last — the stable specs release — at 08:30:09 UTC. Microsoft's security team published the deepest incident analysis the following day.

The blast radius is what separates this from a typosquat. @asyncapi/specs alone sees 2.66 million downloads a week, and it is also pulled in transitively by @asyncapi/parser (roughly 970,000 weekly downloads) through a ^6.11.1 semver range — meaning the poisoned 6.11.2 satisfied countless installs automatically, with no direct upgrade action by anyone. Combined weekly downloads across the four packages run to two million-plus, by some counts over three million; outlets round differently, so treat the per-package specs figure as the anchor stat.

The roughly four-hour window sounds reassuring until you multiply it against the download rate. At 2.66 million weekly downloads, the specs package averages hundreds of installs a minute — and every CI pipeline that ran npm install against a floating range in that window, then executed a build that imported the module, ran the payload. Speed of unpublish limits the population; it does not identify who in that population was hit.

npm 12 shipped on July 8, 2026 with the most significant default hardening in the registry's history: allowScripts off by default — blocking preinstall, install, and postinstall lifecycle scripts plus implicit node-gyp builds — and git-dependency and remote-tarball resolution disabled unless explicitly allowed. We covered the full mechanics in our npm 12 install-script defaults guide. Those defaults are real progress against the attack pattern that dominated 2025.

They are also completely orthogonal to what happened on July 14. The AsyncAPI malware declares no lifecycle script of any kind — so there is nothing for npm 12 to block, and npm install --ignore-scripts, the veteran mitigation in every hardening guide, is equally inert. The payload triggers the first time the poisoned module is actually imported: a generator build, a CI test run, a CLI invocation, or an application server booting in production.

This is the paragraph worth internalizing as a trend, not a one-off. Platform defaults are public documents: the moment npm 12 announced that install scripts were blocked by default, every capable attacker knew exactly which technique was depreciating and which adjacent technique — runtime execution inside legitimate module code — was untouched. The AsyncAPI campaign landing six days after the npm 12 release is the clearest demonstration yet that supply-chain defenses and attacker innovation move in the same news cycle. Defenses that respond to last quarter's attack pattern buy you exactly one quarter.

Socket.dev's stage-by-stage breakdown — corroborated by Microsoft and Datadog Security Labs — shows a deliberately minimal footprint inside the npm tarball and a deliberately maximal capability at the end of the chain.

Stage 1 spawns a detached, hidden Node.js child process — spawn("node", ["-e", stage2], { detached: true, stdio: "ignore", windowsHide: true }) — the moment the poisoned module loads, then returns control to the legitimate package code. The developer or CI job sees a normal, green run. Using IPFS for stage 2 is the clever part: because the npm tarball only ever contained a small downloader, the operator can update or replace the final payload at will without republishing anything to npm.

The Miasma framework itself is built for resilience. Beyond REST/HTTP beaconing to a hardcoded IP, Socket.dev, StepSecurity, and Datadog document code paths for Nostr relays, Ethereum smart-contract lookups, libp2p, BitTorrent DHT bootstrap nodes, and mDNS discovery — most shipped present but disabled in the observed "safe mode" configuration. Credential targeting spans GitHub, npm, AWS, Azure, GCP, Docker, and Kubernetes tokens, .npmrc and .aws/credentials files, SSH keys, browser-saved passwords and cookies across Chrome, Brave, Firefox, and Edge, and the macOS Keychain. StepSecurity additionally reports an ai-tool-poisoner.js component targeting locally installed AI coding assistant sessions and config — a detail from one source, not independently confirmed by Microsoft or Socket.dev, but consistent with the July 11 Jscrambler stealer's documented interest in AI tool configs. To be clear: that is about local config files on an already-compromised machine, not a compromise of any AI tool itself.

No npm account was phished and no maintainer went rogue. The entry point, documented by Chainguard and corroborated by Socket.dev, StepSecurity, and Wiz, was a misconfigured pull_request_target GitHub Actions workflow in the asyncapi/generator repository — a "pwn request." The workflow checked out attacker-controlled PR code while running with base-repo secrets access, exposing a highly privileged personal access token belonging to the asyncapi-bot account. The attacker opened roughly three dozen decoy pull requests in the hours before the exploit PR, muddying which one mattered.

The sharpest detail: the vulnerable pattern was known. Wiz traces a researcher proof-of-concept to April 2026 with a proposed fix left unmerged, and Chainguard describes the pattern as flagged internally weeks before the attack. Sources differ on the precise dates, but they agree on the shape — a multi-week window between internal warning and external exploitation.

That framing — covering both AsyncAPI and the July 11 Jscrambler incident — matters because it moves the failure domain. The malicious packages were published through npm's trusted publishing (GitHub OIDC) mechanism and carried valid SLSA provenance attestations. The attestations were not forged. They correctly proved the packages came from the project's authorized CI workflow. What they could not prove — what provenance structurally cannot prove — is that the source commit which triggered that workflow was legitimate.

AsyncAPI did not happen in a vacuum. Palo Alto Networks' Unit 42 documents at least six major npm mass-poisoning campaigns in 2026 before this one, each sharing the same mechanism: the attacker gains write or publish access, then rides a legitimate CI pipeline to a trusted release. The table below lists the dated campaigns from Unit 42's tracker plus July's two incidents — the same pattern we examined when a supply-chain compromise hit AI infrastructure tooling earlier this year.

Read the vector column of history, not just the dates. Jscrambler (July 11) used a classic preinstall-hook native binary — the attack class npm 12 now blocks by default. AsyncAPI (July 14) used import-time execution — the class it does not. Three days apart, the ecosystem got a controlled experiment in defense lag: the same week that one vector became harder, the adjacent vector was exploited at well over a hundred times Jscrambler's download volume. The Jscrambler case stings for a second reason — the victim is itself a security and obfuscation vendor, and its plugin ecosystem was affected across multiple versions.

Projecting forward, the honest expectation is that import-time and runtime payloads become the default rather than the exception, because that is where the defensive tooling is thinnest. Registry operators can scan for lifecycle hooks cheaply; distinguishing a malicious module-load statement from the millions of legitimate side effects that fire on import is a materially harder problem. Expect the next platform-level battleground to be behavioral scanning at publish time and sandboxed module execution — and expect attackers to probe whatever those defaults leave open, on roughly the same one-news-cycle lag this incident demonstrated.

Most coverage explains either what happened or what to do, in isolation. The more useful exercise is mapping each common control against the three stages of this specific chain — stage 1, the import-time spawn; stage 2, the IPFS payload fetch; stage 3, the Miasma C2 and credential theft. The verdicts below synthesize the Microsoft and Socket.dev technical breakdowns against the mitigation guidance from Unit 42, Chainguard, and StepSecurity.

The pattern in the matrix is stark. Of the two controls the ecosystem spent 2025-26 celebrating — install-script blocking and provenance attestation — neither interrupts a single stage of this chain. The controls that do are older and less glamorous: a committed lockfile with npm ci, a publication cooldown, and a CI runner that simply cannot reach an IPFS gateway. Defense in depth is not a compliance phrase here; it is the only configuration in which this attack fails.

Everything below comes from the post-incident guidance of Unit 42, Chainguard, StepSecurity, and Datadog, sequenced by effort-to-payoff. The first two need no new tooling — only discipline in files you already have.

Two additions round out the stack. First, keep verifying provenance anyway — it raises attacker cost and catches other attack classes, even though it passed cleanly here. Second, fold these layers into your pipeline design rather than bolting them on; our CI/CD pipeline design reference treats egress control and secrets scoping as first-class architecture decisions, not security afterthoughts. For teams without a dedicated platform function, this is exactly the kind of hardening our web development engagements build into delivery pipelines by default.

Note also npm's parallel identity-hardening track: alongside the npm 12 script defaults, granular access tokens configured to bypass 2FA are deprecated, with restrictions beginning August 2026 and further publishing limits announced for January 2027. That timeline is worth building into your token inventory now rather than during a forced migration.

If any environment installed one of the five malicious versions during the July 14 window and subsequently imported the module, treat the machine as compromised. In order:

• Pin and reinstall clean versions. Purge node_modules and lockfile entries referencing @asyncapi/specs 6.11.2 / 6.11.2-alpha.1, generator 3.3.1, generator-components 0.7.1, or generator-helpers 1.1.1.
• Hunt the stage-2 artifact. Look for an unexpected NodeJS-named state directory containing sync.js in %LOCALAPPDATA% (Windows), ~/Library/Application Support (macOS), or ~/.local/share (Linux).
• Check persistence. Microsoft documents a Windows HKCU Run key named miasma-monitor, a Linux systemd user unit (miasma-monitor.service), and macOS shell-RC injection in .zshrc, .bashrc, or .bash_profile.
• Rotate everything the stealer targets. GitHub, npm, AWS, Azure, GCP, Docker, and Kubernetes tokens; .npmrc and .aws/credentials; SSH keys; browser-saved passwords and session cookies. StepSecurity additionally recommends treating local AI coding assistant sessions and config on affected machines as compromised.