The AsyncAPI backdoor shipped with valid provenance, because the official pipeline built it

Researchers at Upwind found that attackers injected malware directly into the AsyncAPI project's source repositories before the packages were published to the npm registry ^[1]. The compromised packages then moved through official publishing channels and looked legitimate to developers, who risked pulling malicious code into their workstations and CI/CD environments simply by importing them ^[2].

That is a different failure mode from the one most dependency controls are built for. Dan Moore Sr. of FusionAuth, quoted in a ReversingLabs write-up of the incident ^[0], said the usual package attack is simple tampering: steal an npm token, push a doctored tarball to the registry ^[5]. AsyncAPI ran in reverse. According to Moore, the attacker exploited a misconfiguration to ship code under the identity of the project's release bot, which let the pipeline build, sign, and publish it ^[6]. Amiram Shachar, CEO and co-founder of Upwind, told Cybersecurity Dive that multiple official AsyncAPI packages were published with backdoored code from separate repositories and pipelines ^[3]. "This wasn't just a malicious package. It was a compromise of trust," Shachar said ^[4].

The consequence is the part worth internalising. The infected packages shipped with valid provenance attestations ^[7]. Michael Nov, co-founder and CEO of Prime Security, said the attacker used AsyncAPI's own trusted publishing workflows, so the verification machinery the industry tells everyone to adopt ended up vouching for the malware ^[8]. "Provenance told the truth," Nov said. "These artifacts really were built by the official pipeline from the official repo. The truth was malicious" ^[9]. The payload also executed on module load rather than through an install hook ^[10], which Nov said implied operational planning well above the opportunistic typosquatting most people picture when they hear "npm attack" ^[11]. Moore's summary: check the attestation and watch the install scripts, and you catch neither half of this ^[12].

The campaign was also broad in a way that suggests the attacker understood how repositories are defended. Dwayne McDaniel, a developer advocate at GitGuardian, called it the widest attack path of any recent worm he has tracked ^[13], noting "there were so many branches and pipelines used at once" ^[14]. Pushing to multiple branches was deliberate evasion, he said, because protections cluster around main and production branches, leaving infected side branches easier to hide in until later legitimate commits ^[15]. Payloads were staged across multiple destinations, Moore added, including an Ethereum dead drop that is effectively impossible to take down ^[16].

Donald McFarlane, an advisory board member at Xcape, said the industry's work on proving where an artifact came from is necessary but, on the evidence here, not sufficient ^[17]; what is missing are controls that assess what actually changed, whether the change was authorized, and what the resulting software does ^[18]. Organisations that do not enforce a cool-down period on newly released packages need strong change and release management controls around open-source dependencies in CI/CD, including careful auditing and analysis ^[19], plus a rehearsed remediation path for the moment a malicious package lands in development or production ^[20].

What to watch is whether release identity gets the same budget as scanning. Kelvin Lim, Asia-Pacific head of security engineering at Black Duck Software, said most security teams he speaks with have software composition analysis, dependency scanning, and SBOMs well covered ^[21], but far fewer have equivalent visibility into the identities, permissions, and workflows that actually publish their software ^[22]. Until they do, an attestation confirms only that your attacker had commit access.