AsyncAPI npm package compromise shows provenance is not a complete supply-chain defense

A coordinated compromise of the AsyncAPI npm ecosystem briefly put poisoned versions of widely used developer packages in the path of build systems, local workstations, and projects that resolve AsyncAPI tooling through transitive dependencies. Microsoft Threat Intelligence said it identified the incident on July 14, 2026, and reported that five package versions across four package names were republished with a malicious loader.

The affected packages were @asyncapi/generator@3.3.1, @asyncapi/generator-components@0.7.1, @asyncapi/generator-helpers@1.1.1, and two @asyncapi/specs releases: 6.11.2-alpha.1 and 6.11.2. Datadog Security Labs said the four package names collectively accounted for more than 3 million weekly downloads, making the window short but consequential for teams that automatically consumed fresh npm versions.

Why the attack matters

The notable detail is where the payload executed. Microsoft said the injected code ran when a compromised package was imported or required, rather than through a conventional install script. That means the familiar npm install --ignore-scripts defense would not have neutralized this campaign once a build or application loaded the package.

StepSecurity reported that the malicious publications carried valid npm provenance attestations because the attacker used the projects' own GitHub Actions release workflows after gaining push access, instead of stealing an npm token. In other words, provenance showed that an authorized workflow produced the package, but it did not prove that the commit triggering the workflow was trustworthy.

What defenders should check

• Remove the affected package versions from lock files, build caches, and artifact repositories.
• Force safe versions where transitive dependency ranges could otherwise select the poisoned @asyncapi/specs release.
• Search developer machines and CI runners for the reported sync.js payload path and related indicators.
• Rotate credentials that may have been reachable from any system that imported the compromised packages.

Microsoft said its guidance includes blocking outbound connections to the reported command-and-control address on ports 8080, 8081, and 8091. StepSecurity said all five malicious versions had been unpublished by 11:18 UTC on July 14, with clean latest tags restored. Fresh installs should therefore avoid the known bad versions, but pinned lock files and cached artifacts remain the key places to inspect.

Sources

• www.microsoft.com
• securitylabs.datadoghq.com
• www.stepsecurity.io

Cover photo by Daniil Komov on Pexels, used under the Pexels License.