Your release pipeline will vouch for malware

TL;DR: Someone opened a pull request against AsyncAPI's CI, used it to steal the project's release-bot token, and let AsyncAPI's own pipeline publish five npm versions with malware in them, each with valid provenance attestations. The payload runs at import, so --ignore-scripts never sees it. Provenance proves who built a package. It says nothing about whether the code is safe. Inside: how the attack chained, the one workflow trigger to grep for this week, and a symlink trick that makes your coding agent's approval box show you the wrong file.

Rohan Prabhu at StepSecurity, "Coordinated AsyncAPI Supply Chain Attack: Miasma RAT Delivered via Compromised CI/CD Pipelines" [2026-07-14], with the initial-access detail from Microsoft Security's teardown of the same compromise [2026-07-15].

How it runs. Start with a pull request. AsyncAPI had a preview workflow, manual-netlify-preview.yml, wired to pull_request_target. That trigger runs the job with the base repo's secrets, even for an outsider's PR, and this one also checked out the PR's code. So that PR's code ran with the repo's secrets in reach. It read the asyncapi-bot personal access token, a PAT, and copied it out.

That PAT is a real maintainer credential. The attacker used it to push commits to the next branch of asyncapi/generator and master of spec-json-schemas, under a placeholder git identity, and the release pipeline did the rest.

Here's the catch. AsyncAPI publishes through npm trusted publishing with GitHub OIDC, where npm accepts a short-lived token from GitHub in place of a stored npm token. That is the current best-practice setup. The real release workflow saw the new commits and published five versions across four packages, and npm stamped each one with a valid provenance attestation, a signed record of which pipeline built it. That record is accurate. The authorized workflow really did build these packages. It just built the attacker's code.

The payload sits idle until your code loads the module. It fires on import or require, at use-time. npm install --ignore-scripts only blocks install-time scripts, so it misses this one entirely. The first time a build or a test pulls the library in, a remote-access trojan the researchers named Miasma starts up. Its command-and-control falls back across plain HTTP, Nostr relays, and BitTorrent's DHT.

Ship This Week.

The whole thing turned on one combination: a privileged trigger, a checkout of untrusted code, and a step that runs it. You can flag that pattern in a short CI check, before it ever leaks a token.

Alert on any workflow file where all three are true:

That combination lets a stranger's code read your repo's secrets. pull_request_target has real uses, so flag a hit for review instead of auto-failing the build. Just make someone explain why the checkout and the run step both belong in one privileged job.

The weak point here was the pipeline itself. Point an agent at your own release path and see what a stranger's PR could reach.

Point a coding agent at .github/workflows, plus any reusable workflows and composite actions they call, and have it surface four things:

Then make it prove each one. Every hit needs a file:line. For the risky ones, make it show both steps: the grant, and the credential that grant can reach. A bare keyword match shouldn't count. Agents over-report, so treat the whole list as a first pass and confirm by hand.

Maor Dokhanian at Wiz, "GhostApproval: a trust boundary gap in AI coding assistants" [2026-07-08]. The same trick shows up in your editor. A repo ships a file with an innocent name like project_settings.json that is a symlink to ~/.ssh/authorized_keys. You ask your coding agent to set up the workspace, it goes to write that file, and the approval dialog shows you the harmless name while the write lands on your SSH keys.

It gets worse. Wiz saw the agent name the real target in its own reasoning, then hide it in the confirmation box anyway. That is an old symlink-follow bug (CWE-61) sitting on top of an approval box that shows the wrong target (CWE-451).

Six assistants were affected: Amazon Q (CVE-2026-12958), Cursor (CVE-2026-50549), Google Antigravity (CVE pending), Augment, Windsurf, and Claude Code. Amazon Q and Cursor shipped fixes. Anthropic disputed that this is a vulnerability, since a folder you chose to trust sits outside its threat model.