On July 14, 2026, at 07:10 UTC, three packages in the AsyncAPI generator monorepo were published to npm carrying an obfuscated dropper. Within about ninety minutes, five package versions across four package names in the @asyncapi namespace had gone out with the same malicious loader injected, including a widely used specs package. Every one of them carried a valid npm OIDC provenance attestation, the exact signal that is supposed to tell downstream users a package was built by a legitimate, verifiable CI pipeline rather than by an attacker with a stolen token.
The attack did not need a stolen token
That last detail is what makes this incident worth reading past the headline. The attacker did not compromise npm credentials at all. A misconfigured GitHub Actions workflow using the pull_request_target trigger executed attacker-controlled code from a pull request with the permissions of the base repository, exposing a bot’s personal access token in the process. With that token, the attacker pushed to an auto-publish branch and let AsyncAPI’s own legitimate release pipeline build and publish the packages. The provenance attestation was genuine, because the pipeline that generated it was genuine. It just published something the maintainers never approved.
This is a different failure mode from the credential-theft pattern that has dominated npm and PyPI supply chain incidents all year, including May’s TrapDoor campaign and June’s Miasma attack on Red Hat’s npm namespace. Those relied on stolen tokens or compromised employee accounts. This one relied purely on a workflow permissions mistake that is extremely common in open source projects: pull_request_target gives a workflow access to secrets and write permissions while checking out code from a fork, and if that workflow doesn’t carefully separate “run untrusted code” from “use privileged credentials,” the fork’s code runs with the base repository’s authority.
The payload runs on import, not install
The malicious loader also broke from the typical pattern in a second way. Most npm supply chain malware runs via a postinstall script, the moment a package manager finishes installing it. This payload instead executed at module-load time, the moment a project actually imports or requires the package in running code. That distinction matters for detection tooling: scanners and CI gates that specifically watch for suspicious install scripts, a defense many teams adopted after this year’s wave of postinstall-based attacks, would not have caught this one.
The payload itself is described by researchers as a descendant of the Miasma remote access trojan used in June’s Red Hat npm compromise, with encrypted bootstrap, persistence, and command-and-control resilience built on decentralized discovery channels including Nostr, Ethereum, BitTorrent DHT, libp2p, and IPFS, making conventional domain and IP blocklisting far less effective against it.
What this means for European engineering teams
If your build pipeline or production dependency tree pulled @asyncapi/generator, @asyncapi/generator-helpers, @asyncapi/generator-components, or @asyncapi/specs between July 14 and the point the malicious versions were unpublished, treat any credentials present in that environment as compromised and rotate them.
Beyond incident response, this is a good prompt to audit your own GitHub Actions workflows for pull_request_target usage. If any workflow uses that trigger while also checking out and executing code from the pull request itself, or while holding write permissions and secrets in the same job, it shares AsyncAPI’s exact structural weakness. The fix is almost always to split the workflow: run untrusted code from forks with no secrets and read-only permissions, and gate any privileged step, publishing, deployment, or secret access, behind a separate, reviewed workflow that never checks out unreviewed fork code.
For NIS2 and DORA-covered organisations, this incident also belongs in your supply chain risk documentation. Regulators increasingly expect evidence that you assess the CI/CD posture of your open source dependencies, not just the packages themselves.
If you want a review of your GitHub Actions or GitLab CI configurations for exactly this class of workflow permission issue, or help building a dependency and pipeline risk process that satisfies NIS2 and DORA supply chain requirements, contact Excello Digital. We help European engineering teams close the gaps between what their CI pipelines are trusted to do and what they are actually protected against.