A Misconfigured GitHub Action Backdoored Packages With 3M Weekly Downloads

Somewhere in AsyncAPI’s pull request queue, a fix for a CI workflow bug had been sitting since mid-May — reviewed, technically sound, and stuck. Fifty-eight days later, on July 14, 2026, someone stopped waiting for a maintainer to merge it and used the exact hole it would have closed instead. In just over three hours, five poisoned package versions were live on npm’s public registry, and every one of the 3 million-plus weekly installs of AsyncAPI’s tooling became a potential vector for a credential-harvesting framework that identifies itself, almost tauntingly, as M-RED-TEAM v6.4.

What exactly did the attacker exploit?

A pull_request_target misconfiguration in a single workflow file: manual-netlify-preview.yml. That trigger is designed for jobs that need access to a repository’s secrets — posting a preview URL as a PR comment, for instance — while still running against pull requests from forks. The catch is that pull_request_target runs with the base repository’s permissions and secret store, so if the workflow also checks out and executes the pull request’s own head code, an attacker gets their code running inside a privileged context. Wiz’s writeup has a name for that exact shape: a “pwn request.”

AsyncAPI’s workflow reproduced it. The attacker opened PR #2155 at 05:08 UTC with an obfuscated payload buried after roughly 1,000 bytes of whitespace, according to Wiz. The workflow run completed at 05:16 UTC, and the stolen credentials were exfiltrated to a paste on rentry.co. From there, the attacker used the privileged token to push a malicious commit to AsyncAPI’s next branch at 06:58 UTC and, per Chainguard, trigger the project’s own release pipeline directly — no further social engineering required.

How did the compromise unfold, minute by minute?

Fast, once the token was in hand. From PR to five published packages, the entire operation ran inside a single morning:

Package	Malicious version	Published (UTC)
@asyncapi/generator-helpers	1.1.1	07:10:42
@asyncapi/generator-components	0.7.1	07:10:44
@asyncapi/generator	3.3.1	07:10:48
@asyncapi/specs	6.11.2-alpha.1	08:06:20
@asyncapi/specs	6.11.2	08:30:09

The contrast between how long the defense sat idle and how fast the offense moved once it started is the story in miniature.

What did the payload actually do once it landed on a machine?

It ran when a developer’s code imported the package — not when npm installed it. Microsoft’s analysis is explicit on this point: the malware executed at module-load (import/require) time, which means the standard defense of running npm install --ignore-scripts did nothing, because there was no install script to skip. The malicious logic lived inside the package’s runtime code itself.

Wiz traces a three-stage infection chain. Stage one spawned a child process that downloaded an 8.25 MB encrypted bundle over IPFS to an OS-specific path — ~/.local/share/NodeJS/sync.js on Linux, ~/Library/Application Support/NodeJS/sync.js on macOS, %LOCALAPPDATA%\NodeJS\sync.js on Windows. Stage two unpacked that bundle’s configuration and runtime. Stage three deployed a 92,000-line, modular malware framework that established persistence via a systemd service — Chainguard names it miasma-monitor.service on Linux — and maintained command-and-control through a mix of HTTP, Nostr messaging, Ethereum smart contracts, and peer-to-peer networks. Both Wiz and Chainguard describe it as a remote-access toolkit rather than a self-propagating worm.

The target list reads like a credential inventory of a working developer’s entire machine: browser-saved passwords and cookies across Chrome, Brave, Firefox, and Edge; SSH keys; npm and GitHub tokens; AWS credentials; macOS Keychain entries; and cryptocurrency wallet data. Microsoft’s analysis adds scale to that: the framework probed for more than 100 environment variables, including AWS_ACCESS_KEY, AZURE_CLIENT_SECRET, and GCLOUD_SERVICE_KEY, alongside credential files like .npmrc, .aws/credentials, kubeconfig, id_rsa, .vault-token, and .docker/config.json.

One nuance is worth flagging rather than smoothing over: Microsoft notes that credential harvesting was “disabled in this build” even though the code paths targeting browser passwords and SSH keys were present in the framework. That’s a real discrepancy between what the malware was capable of and what it was confirmed to actively exfiltrate in the version analyzed — the kind of detail that matters for anyone deciding how urgently to rotate which credential. Attribution, meanwhile, stayed inconclusive: the payload self-identified as “M-RED-TEAM v6.4,” Wiz found possible but unconfirmed overlap with a framework researchers call Miasma, and the rentry.co paste slug matched naming patterns from an unrelated campaign — no firm attribution landed in any of the three writeups.

What should teams that depend on AsyncAPI tooling do now?

Assume any machine that ran npm install or imported one of the five versions between July 14’s publish windows is compromised, not just at risk. Because the payload fired on import rather than install, dependency-scanning approaches built around install-time behavior — including the defenses npm’s own v12 security overhaul was designed around — would not have caught this one. That overhaul turns off automatic install scripts by default; this attack never used an install script at all. It’s a live demonstration of the exact gap that npm v12’s critics warned was left open: runtime-triggered payloads that pass straight through script-blocking rules.

None of this required a zero-day. It required a known CI misconfiguration pattern, a proposed fix that outran the review queue by 58 days, and a registry that treats a stolen-but-valid publish token exactly like a legitimate one. AsyncAPI’s maintainers now face the unglamorous work of pulling five versions and explaining to 3 million weekly installs why a re-audit of their own supply chain just became mandatory. The fix that could have prevented all of it was sitting in the PR queue the entire time. Whether a credential escapes through an unmerged CI fix or a disputed forum listing of stolen cloud keys, the fallout runs on the same clock — until “reviewed” starts meaning “merged.”