AsyncAPI CI/CD Compromise: Malware Signed by the Project's Own Release Pipeline

Attackers never stole an npm token — they used AsyncAPI's legitimate GitHub Actions workflow to publish backdoored packages with valid provenance attestations

Date: July 14, 2026 Primary Source: Microsoft Security Blog (Microsoft) · Datadog Security Labs (Datadog)

AsyncAPI npm CI/CD supply-chain compromise — a poisoned GitHub Actions release pipeline publishes backdoored packages with valid provenance, delivering a multi-stage botnet payload at import time

Executive Summary

What: On July 14, 2026, attackers compromised the release pipelines of two AsyncAPI GitHub repositories and used the projects' own legitimate workflows to publish four malicious npm packages carrying an obfuscated dropper. (Microsoft)
The twist: No npm token was stolen. The packages were published with valid OIDC provenance attestations, because the project's real pipeline did the publishing. (StepSecurity)
Who is affected: Projects consuming @asyncapi packages — the affected namespace totals over 3 million weekly downloads. (Microsoft)
Severity: High — payload executes on import, not install, and pulls a multi-stage botnet framework with credential theft, AI-tool poisoning, and worm-like propagation.
Action required: Audit lockfiles for the five malicious versions, rotate developer and CI credentials, and put an execution-control layer between a poisoned dependency and your build machines.

Overview

Software supply-chain defense has spent two years building toward provenance: sign the artifact, attest where it was built, verify the attestation. It is good work and it remains worth doing.

This incident is a reminder of what provenance actually proves. It proves where a package was built. It does not prove that what was built is safe.

The attacker did not forge a signature or steal a publishing token. They got their code into the repository, and the project's own release pipeline signed and published it — correctly, with valid attestations, exactly as designed. Every automated check downstream passed.

Threat Summary

Field	Detail
Incident	AsyncAPI npm supply-chain compromise via GitHub Actions
Initial public report	July 14, 2026
CVE ID	None — CI/CD workflow misconfiguration abuse, not a product CVE
Affected packages	`@asyncapi/generator` 3.3.1, `@asyncapi/generator-helpers` 1.1.1, `@asyncapi/generator-components` 0.7.1, `@asyncapi/specs` 6.11.2-alpha.1 and 6.11.2 (StepSecurity)
Scale	`@asyncapi` namespace exceeds 3 million weekly downloads (Microsoft)
Attack vector	GitHub Actions "pwn request" — a `pull_request_target`-class misconfiguration used to steal a privileged bot token
Execution trigger	On import, not at install time (Microsoft)
Payload	Obfuscated dropper → multi-stage botnet framework retrieved from IPFS
Provenance	Valid OIDC attestations — packages were published by the real pipeline
Remediation	All five malicious versions unpublished from npm

Technical Analysis

How the Attack Works

Camouflage. The attacker opened dozens of pull requests against the AsyncAPI generator repository, using the noise to hide the one that mattered — PR #2155. (Datadog)
Workflow abuse. That PR exploited a known class of GitHub Actions misconfiguration (a "pwn request") to steal a privileged bot token (MITRE ATT&CK T1078).
Push access. With the token, the attacker pushed commits to the next branch, injecting a dropper into three packages.
The project published its own malware. The commits triggered the legitimate release-with-changesets.yml workflow. At 06:58 UTC, @asyncapi/generator, generator-helpers, and generator-components were published. At 07:56 UTC, a second repository — asyncapi/spec-json-schemas — was hit the same way, publishing two versions of @asyncapi/specs. (StepSecurity)
Import-time execution. The dropper fires when the library is loaded, not when it is installed — so --ignore-scripts provides no protection (T1059).
Second stage from IPFS. The dropper retrieves a botnet framework from IPFS, with multi-channel command and control across HTTP, Nostr, IPFS, BitTorrent, libp2p, and Ethereum. (Microsoft)
Objectives. Credential theft, AI tool poisoning, and worm-like propagation to other packages the victim can publish (T1552, T1195.002).

Payload and Impact

The C2 design deserves attention from anyone who thinks blocking a domain solves this. Command and control spread across IPFS, BitTorrent, Nostr, libp2p, and Ethereum has no single chokepoint to sinkhole and no static domain to blocklist. Reporting associates the payload with the Miasma malware family, whose tooling appeared in the June @redhat-cloud-services compromise we covered previously. (Rescana)

Roughly two hours separated the two repository compromises. That is an operator working from a prepared playbook, not improvising.

Why Traditional Defenses Struggle

Provenance verification passes. The attestations are genuine. The packages really were built by AsyncAPI's pipeline.
No stolen token to detect. There is no anomalous publish from an unfamiliar location — the publish came from the project's own CI.
--ignore-scripts does not apply. Import-time execution bypasses install-hook mitigations entirely.
C2 cannot be blocklisted cleanly. Six transport channels, several of them decentralized, defeat domain-based blocking.
The malicious PR was buried. Dozens of decoy pull requests meant the real one arrived inside legitimate-looking review noise.

How White Cloud Security Trust Lockdown Stops This

Least-Privilege Zero-Trust App Firewall

Every path in this attack — install hook or import, HTTP or IPFS, first stage or second — converges on the same requirement: something unapproved has to execute on your machine.

White Cloud Security (WCS) Trust Lockdown enforces Zero-Trust Application Control: only explicitly approved software runs, and unknown or unapproved software is denied before execution.

Attack step	WCS control that applies
Package published with valid provenance	Provenance is not an input to the decision — approval is by file identity, not by attestation or publisher
Dropper fires on import rather than install	Irrelevant to the outcome: the dropper still needs to run an unapproved binary or interpreter, which is denied
Second stage retrieved from IPFS	A payload that reaches disk is not thereby permitted to run — denied before execution
Multi-channel C2 (HTTP, Nostr, BitTorrent, libp2p, Ethereum)	WCS does not inspect or block this traffic. It would help prevent the process from running that would establish the channel
Worm propagation using stolen publish rights	Would reduce the attack surface by denying the unapproved tooling that performs it

The fourth row is stated carefully on purpose. WCS is not a network product and does not decrypt, inspect, or block C2 traffic. Its contribution is upstream of that: preventing the unauthorized process from starting in the first place.

Handprint Identity

WCS identifies files by handprint — SHA-1, SHA-256, SHA-512, MD5, CRC32, and file length. A dropper that is re-obfuscated per campaign, a second stage pulled fresh from IPFS, or a payload renamed to resemble a build tool all produce different handprints and remain denied. Approval does not transfer from a package name, a namespace, or a signature.

What this does not do: it would not have prevented the GitHub Actions misconfiguration, the token theft, or the malicious publish. Those require workflow hardening, pull_request_target review, and least-privilege CI tokens. Execution control limits what the poisoned dependency can accomplish once it reaches a machine.

At White Cloud Security, we continue to track and report new hacking methods and tools — not just because of their immediate threat, but because patterns of reuse often expose the playbooks of these cybercriminal groups.

Recommended Mitigations

Audit lockfiles for the five affected versions listed in the Threat Summary.
Rotate credentials on any machine that imported the affected packages: cloud keys, CI tokens, npm and GitHub tokens, SSH keys — and AI-tool API keys, given the payload's AI-poisoning objective.
Audit your own GitHub Actions workflows for pull_request_target and similar patterns that expose privileged tokens to untrusted pull-request content.
Scope CI tokens to least privilege and prefer short-lived, narrowly scoped credentials over durable bot tokens.
Treat a burst of unfamiliar pull requests as a signal, not just noise — the camouflage worked because volume looked like community activity.
Do not treat provenance as a safety verdict. It attests to build origin, not to content.
Apply Default-Deny application control on developer endpoints and build servers.

Indicators of Compromise

@asyncapi/generator             3.3.1
@asyncapi/generator-helpers     1.1.1
@asyncapi/generator-components  0.7.1
@asyncapi/specs                 6.11.2-alpha.1
@asyncapi/specs                 6.11.2

Compromise windows (2026-07-14):
  06:58 UTC — asyncapi/generator
  07:56 UTC — asyncapi/spec-json-schemas

Consult the Microsoft, Datadog, and StepSecurity analyses for current hashes and network indicators before hunting.

Key Takeaways

Valid provenance is not a safety verdict. The packages were genuinely built and signed by AsyncAPI's own pipeline.
No npm token was stolen — a GitHub Actions "pwn request" yielded a privileged bot token instead.
Import-time execution defeats --ignore-scripts, the mitigation most teams rely on.
Multi-channel C2 across IPFS, BitTorrent, Nostr, libp2p, and Ethereum leaves no clean domain to block.
Dozens of decoy pull requests hid the malicious one — review volume was the camouflage.
Every variant still ends in an unapproved process trying to execute, which is the point Default-Deny addresses.