Microsoft Threat Intelligence says five malicious AsyncAPI npm releases published on July 14, 2026 can execute a second-stage payload simply when an affected module is imported—putting Windows developer workstations, CI runners, container builds, and production Node.js services at risk even if npm lifecycle scripts were disabled.
The compromised releases are
This is not the familiar malicious
For Windows administrators, the immediate hunting target is
According to Microsoft, the initial compromise was rooted in a GitHub Actions workflow in the
Microsoft’s timeline places the attacker-controlled commit at 05:08 UTC on July 14, followed by the privileged Docs Preview workflow shortly afterward. Later pushes were authenticated as
That became the decisive point of failure. The attacker apparently did not need to directly seize the npm organization or bypass npm’s trusted-publishing controls. Instead, they used the projects’ normal GitHub Actions OpenID Connect publishing route, producing packages under the expected automated identity,
The releases therefore carried valid provenance attestations. But the attestations only proved that a legitimate repository workflow built the package from a particular commit; they did not establish that the commit itself was authorized. Provenance is not a substitute for source-control integrity.
Three generator-related packages were republished at about 07:10 UTC.
The payload then decrypted and evaluated an approximately 8.2 MB runtime Microsoft identifies as Miasma, with active command-and-control and persistence functions. In the analyzed configuration, credential-harvesting and propagation capabilities were present but disabled. That is a meaningful distinction: Microsoft has not said those modules executed in this campaign, but their presence makes a host that reached the second stage unsuitable for casual cleanup and continued use.
On Windows, the runtime could create an HKCU Run value named
Microsoft Defender Antivirus detects relevant artifacts as
Start by searching lockfiles, dependency inventories, internal registries, developer endpoints, CI caches, container build caches, and golden images for the five named versions. Pin known-good versions identified by Microsoft:
This response needs to include cache eviction, not merely a package downgrade. npm and Yarn caches can reintroduce previously downloaded artifacts into later builds; shared runners and reusable base images can distribute them well beyond the machine that first resolved the dependency. Rebuild affected containers and runner images from a known-good baseline after purging cached package data.
Microsoft also published SHA-256 values for each affected tarball, making endpoint and artifact-repository searches more reliable than version-only checks. The company specifically advises hunting for
For Windows endpoints, the core triage checks are straightforward:
Projects should separate preview builds that process external contributions from jobs that can access secrets, write to repositories, or mint release credentials. Bot tokens should be narrowly scoped, workflows should avoid persisting credentials where they are unnecessary, and protected environments should gate release operations. A commit-message condition that starts a release workflow is not a meaningful safeguard if an attacker can write commits as the bot account.
npm’s newer minimum release-age controls can also reduce exposure to freshly published malicious versions. They are not a cure for a targeted compromise, but delaying automatic adoption gives maintainers, registries, and threat researchers time to identify a bad release before it becomes embedded in CI and production.
For now, the decisive question is not whether a workstation ran
The compromised releases are
@asyncapi/[email][email protected][/email], @asyncapi/[email][email protected][/email], @asyncapi/[email][email protected][/email], @asyncapi/[email][email protected][/email], and @asyncapi/[email][email protected][/email]. Microsoft’s July 15 analysis says organizations that resolved and imported any of them should treat the environments as potentially exposed, clear package caches, investigate for persistence, and rotate credentials accessible to the affected process.This is not the familiar malicious
postinstall story. The injected loader ran at module-load time: normal require() or import activity triggered the payload during an application start, build, generator invocation, or test run. That distinction matters because npm install --ignore-scripts does not prevent execution after a poisoned dependency enters the dependency graph.For Windows administrators, the immediate hunting target is
%LOCALAPPDATA%\NodeJS\sync.js, alongside a suspicious miasma-monitor value under the current user’s Run key. The malware’s use of a directory named NodeJS is intended to resemble a harmless development artifact rather than an obvious persistence location.
A trusted release pipeline distributed untrusted code
According to Microsoft, the initial compromise was rooted in a GitHub Actions workflow in the asyncapi/generator project. A malicious pull request—PR #2155—targeted a docs-preview workflow using pull_request_target, which runs in the security context of the base repository. The workflow also checked out untrusted pull-request code, a hazardous combination when credentials or repository secrets are available to the job.Microsoft’s timeline places the attacker-controlled commit at 05:08 UTC on July 14, followed by the privileged Docs Preview workflow shortly afterward. Later pushes were authenticated as
asyncapi-bot, enabling unauthorized commits to branches that the projects’ legitimate release automation trusted.That became the decisive point of failure. The attacker apparently did not need to directly seize the npm organization or bypass npm’s trusted-publishing controls. Instead, they used the projects’ normal GitHub Actions OpenID Connect publishing route, producing packages under the expected automated identity,
npm-oidc-no-reply@github[.]com.The releases therefore carried valid provenance attestations. But the attestations only proved that a legitimate repository workflow built the package from a particular commit; they did not establish that the commit itself was authorized. Provenance is not a substitute for source-control integrity.
Three generator-related packages were republished at about 07:10 UTC.
@asyncapi/[email][email protected][/email] followed at 08:06 UTC, and the stable 6.11.2 release arrived at 08:30 UTC—just 24 minutes later—with a byte-identical malicious payload. Microsoft observed a downstream Yarn cache fetching the stable release at 08:49 UTC.The import was the trigger, not the installation
The malicious loader was inserted into code paths that consumers would normally reach:@asyncapi/specsusedindex.js.@asyncapi/generatorusedlib/templates/config/validator.js.@asyncapi/generator-componentsusedlib/utils/ErrorHandling.js.@asyncapi/generator-helpersusedsrc/utils.js.
sync.js from IPFS. On Windows, the downloaded file was written to %LOCALAPPDATA%\NodeJS\sync.js; Linux and macOS used similarly plausible user-profile directories.The payload then decrypted and evaluated an approximately 8.2 MB runtime Microsoft identifies as Miasma, with active command-and-control and persistence functions. In the analyzed configuration, credential-harvesting and propagation capabilities were present but disabled. That is a meaningful distinction: Microsoft has not said those modules executed in this campaign, but their presence makes a host that reached the second stage unsuitable for casual cleanup and continued use.
On Windows, the runtime could create an HKCU Run value named
miasma-monitor. Microsoft also identified command-and-control, upload, and management services on 85.137.53[.]71 using ports 8080, 8081, and 8091. Its fallback mechanisms included IPFS and several decentralized protocols, an architecture designed to make simple takedowns less effective.Microsoft Defender Antivirus detects relevant artifacts as
Trojan:JS/MiasmStealer.SC and Trojan:Script/Supychain.A, while Microsoft Defender for Endpoint has behavioral coverage for suspicious Node.js execution, IPFS retrieval, and persistence changes. Those detections are useful, but security teams should not make a clean Defender result their sole recovery criterion when a build runner may have held source-control, cloud, container registry, or package publishing credentials.Windows and CI teams need to find every cached copy
The practical blast radius is broader than the number of developers who intentionally installed AsyncAPI tooling.@asyncapi/specs is a transitive dependency for other packages, and a locked dependency tree or shared package cache can preserve an affected tarball long after a project’s manifest changes.Start by searching lockfiles, dependency inventories, internal registries, developer endpoints, CI caches, container build caches, and golden images for the five named versions. Pin known-good versions identified by Microsoft:
@asyncapi/specs 6.11.1 or earlier, @asyncapi/generator 3.3.0, @asyncapi/generator-components 0.7.0, and @asyncapi/generator-helpers 1.1.0.This response needs to include cache eviction, not merely a package downgrade. npm and Yarn caches can reintroduce previously downloaded artifacts into later builds; shared runners and reusable base images can distribute them well beyond the machine that first resolved the dependency. Rebuild affected containers and runner images from a known-good baseline after purging cached package data.
Microsoft also published SHA-256 values for each affected tarball, making endpoint and artifact-repository searches more reliable than version-only checks. The company specifically advises hunting for
sync.js inside the NodeJS masquerade path, detached Node.js processes, and outbound requests for the identified IPFS content.For Windows endpoints, the core triage checks are straightforward:
- Search
%LOCALAPPDATA%\NodeJS\sync.jsand inspect whether a user-levelmiasma-monitorRun entry exists. - Review recent
node.exechild processes, especially detached or hidden executions launched by build, test, or package-generation tasks. - Identify connections to
85.137.53[.]71on ports 8080, 8081, and 8091, as well as retrievals through public IPFS gateways. - Purge npm and Yarn caches before rebuilding, rather than relying on a fresh install command alone.
- Rotate exposed tokens from a clean host if an affected package was imported, including npm, GitHub, cloud, Kubernetes, Docker, SSH, and CI secrets.
The lesson is in the release workflow
The breach is a sharp example of why GitHub Actions workflows deserve the same security review as production deployment code. The dangerous pattern was not simplypull_request_target; it was running that privileged event while checking out and executing content supplied by an untrusted pull request.Projects should separate preview builds that process external contributions from jobs that can access secrets, write to repositories, or mint release credentials. Bot tokens should be narrowly scoped, workflows should avoid persisting credentials where they are unnecessary, and protected environments should gate release operations. A commit-message condition that starts a release workflow is not a meaningful safeguard if an attacker can write commits as the bot account.
npm’s newer minimum release-age controls can also reduce exposure to freshly published malicious versions. They are not a cure for a targeted compromise, but delaying automatic adoption gives maintainers, registries, and threat researchers time to identify a bad release before it becomes embedded in CI and production.
For now, the decisive question is not whether a workstation ran
npm install during the July 14 exposure window. It is whether any affected AsyncAPI version was actually imported. If the answer is yes, organizations should assume the build environment—and every credential it could reach—requires a deliberate incident response.References
- Primary source: Microsoft
Published: 2026-07-16T01:36:21+00:00
Unpacking the AsyncAPI npm supply chain compromise and import-time payload delivery | Microsoft Security Blog
Threat actors compromised AsyncAPI packages and weaponized trusted CI/CD workflows to distribute malware through npm. This analysis breaks down the attack chain, payload delivery, and recommended defenses.www.microsoft.com