Threat Brief: AsyncAPI Supply Chain Attack, Securonix ThreatWatch Analysis

Executive Summary: 

Several packages in the @asyncapi npm namespace were maliciously republished after an attacker abused AsyncAPI's release process. The malicious code did not rely on npm lifecycle scripts. It executed when affected runtime modules were imported or required, which means npm install --ignore-scripts would not have prevented execution once a compromised package was loaded by an application, build process, or developer tool. 

The impact extended beyond the directly republished packages because @asyncapi/specs is used across AsyncAPI tooling. Parser-based validation, generators, CI jobs, container builds, and developer workstations may have been exposed if they resolved and loaded the affected versions during the publication window.

The releases moved through legitimate publishing channels, including GitHub Actions OIDC trusted publishing and valid provenance attestations. Provenance confirmed the publishing path. It did not prove that the release content was safe. 

The second-stage payload has been linked to a Miasma-branded or Miasma-related modular runtime. Observed behavior included command and control activity, persistence, and fallback discovery through IPFS, Nostr, Ethereum data, BitTorrent DHT, and libp2p-related components. Some details around initial access and activation remain unresolved, but the risk is clear: the campaign combined CI/CD trust abuse, import-time execution, and cross-platform post-import behavior in a way that created exposure for software producers and downstream consumers. 

Securonix ThreatWatch assesses this incident as a supply chain compromise with practical impact across development and build environments, especially where affected AsyncAPI packages were automatically resolved, cached, imported, or bundled during the malicious publication window.

Key takeaways: 

• The malicious @asyncapi packages executed when affected modules were loaded, not during installation. Controls focused only on npm lifecycle scripts would not have stopped the payload after an application or build process imported the compromised package. 

• The packages were published through legitimate GitHub Actions workflows that used trusted publishing and produced valid provenance. That provenance helps confirm the release path, but it does not prove the source state or package contents were authorized. 

• The available reporting points to GitHub Actions abuse tied to pull_request_target risk in asyncapi/generator. The exact credential theft path remains unresolved from the available logs.

• The exposure window was short, but the affected packages sat inside commonly used AsyncAPI workflows. @asyncapi/specs created additional downstream risk as a transitive dependency. 

• Multiple vendors observed overlapping infrastructure and drop paths, including 85[.]137[.]53[.]71, IPFS-hosted sync.js, and per-user NodeJS masquerade directories. These overlaps give defenders useful hunting anchors across workstations, CI runners, build containers, and internal package caches.

Campaign overview:

AsyncAPI is an open-source project for defining, validating, and generating assets for asynchronous and event-driven APIs. Its ecosystem includes packages used to validate AsyncAPI documents, parse schemas, and generate documentation or code from API definitions. That dependency chain is why the compromise of @asyncapi/specs and @asyncapi/generator created risk beyond a single repository. AsyncAPI documentation identifies the parser as the component used for document validation and the generator as the package used to produce documentation and other assets from AsyncAPI definitions.

The malicious publication set included five versions across four package names:

This campaign followed a modern npm and CI/CD supply chain pattern. The attacker did not rely only on a stolen npm publish token. Instead, they abused trusted automation, used a legitimate release workflow, and produced packages with valid provenance metadata. The malicious code also ran from ordinary runtime modules, so normal package use could trigger execution without a visible postinstall script.

Technical analysis:

Initial compromise vector:

A likely compromise path involved GitHub Actions abuse through pull_request_target. GitHub notes that these workflows run with the base repository's GITHUB_TOKEN and can access repository or organization secrets. If the workflow also checks out untrusted pull request code, that combination can expose the repository to compromise.

GitHub actions and CI/CD abuse:

The pre-publication activity shows how a CI job could be turned into a credential theft step. The malicious pull request commit fetched and ran JavaScript from rentry[.]co/elzotebo999. A second stage then wrote an observer script under /tmp, scanned /proc/*/environ for INPUT_GITHUB-TOKEN, NETLIFY_AUTH_TOKEN, and NETLIFY_SITE_ID, patched actions/checkout@v5 by modifying /home/runner/work/_actions/actions/checkout/v5/dist/index.js, and sent harvested values to rentry[.]co/elzotebo. This activity likely exposed a GitHub token associated with asyncapi-bot and may have exposed Netlify credentials as well. 

That helps explain why the later npm publications went through the project’s normal release process. The malicious packages were published through GitHub OIDC trusted publishing and carried valid provenance attestations. The attacker did not need to publish from outside the trusted path. After gaining enough repository-side access, the legitimate release pipeline became the delivery mechanism.

npm publication path:

For asyncapi/generator, the sequence is relatively clear. Commit: “3eab3ec9304aa26081358330491d3cfeb55cc245” was pushed to the next branch, which triggered the repository's release-with-changesets.yml workflow. Around 07:10 UTC, three malicious packages were published. Sigstore and provenance records captured the repository, branch, workflow, and commit used to build those packages. The workflow run referenced in the provenance data was no longer available during later review, which may point to cleanup or deletion after the packages were published. 

The asyncapi/spec-json-schemas path is less straightforward. The project issue identifies an alpha branch compromise and key injection commit: “61a930fca724” other analysis tied the stable 6.11.2 release to refs/heads/master, final commit: “689f5b96693ab1f82a825b6d7c4ee566b0afc4c6”, and the if-nodejs-release.yml workflow. A workable timeline connects both views: alpha workflow activity occurred between 07:56 and 08:04 UTC, the malicious lineage reached master around 08:14 UTC, the final child commit landed at 08:28 UTC, and the stable package was published at about 08:30 UTC. The publication sequence is clear enough, but the exact branch path remains partially unsettled.

Malicious code placement and import-time execution:

The attacker did not use npm lifecycle hooks. Instead, the bootstrap code was placed in normal runtime files that would run during ordinary package use. The affected paths were: 

The malicious code was also padded with whitespace, which pushed it out of view in diffs and made manual review easier to miss. 

Because the payload ran on require() or import, simply loading the package could start a detached Node process. That made the import-time trigger one of the more important parts of the compromise. Defenses focused only on postinstall or other lifecycle scripts would not have stopped execution in CI, local development, testing, service startup, or any environment where the package was already installed and later loaded.

Payload delivery and behavior:

The first-stage loader launched node -e with an obfuscated downloader. That downloader retrieved sync.js from IPFS and wrote it to an OS-specific per-user directory named NodeJS. Two IPFS CIDs were associated with the payloads: QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9 for the generator-family packages and Qmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyf for @asyncapi/specs. The observed drop paths were consistent: ~/.local/share/NodeJS/sync.js on Linux, ~/Library/Application Support/NodeJS/sync.js on macOS, %LOCALAPPDATA%\NodeJS\sync.js on Windows, with ~/.config/NodeJS/sync.js used as a fallback.

sync.js was an encrypted, multi-megabyte Node.js bundle. The loader contained the key material needed to recover it offline. The decryption flow used HKDF-SHA256, AES-256-GCM, and a printable ASCII rotation step before execution. Those layers made analysis slower, but they did not prevent static recovery.

At runtime, the payload communicated with HTTP C2 infrastructure at 85[.]137[.]53[.]71. It also included fallback discovery through IPFS, Nostr relays, Ethereum-recorded data, BitTorrent DHT, and libp2p-related peer discovery. The implant beaconed roughly every 30 seconds. Because the C2 channel used plain HTTP, an on-path attacker could potentially inject commands into the response path.

Credential theft, targeting logic, and runtime limits:

The analyzed build had active persistence and C2, but several automated modules appear to have been disabled in the shipped configuration. Code for credential harvesting, propagation, AI-tool poisoning, and a deadman switch was present, yet those features were not all active by default.

That does not make the payload low risk. The implant still provided persistence, beaconing, and remote shell access, which could allow an operator to collect data manually. It also contained broad credential targeting logic, including more than 100 environment variable names and multiple credential file locations.

Cleanup and public-response status:

By 11:18 UTC on July 14, all five malicious versions had been removed from npm metadata, and fresh installs no longer resolved to the affected packages. That did not automatically clear systems that installed them during the exposure window. Existing node_modules directories, lockfiles, package manager caches, CI caches, artifact repositories, and mirrored registries still needed review.

One additional issue was direct tarball access. @asyncapi/specs@6.11.2-alpha.1 was reportedly still reachable by direct tarball URL after it no longer appeared in registry metadata. That points to a possible delay between registry cleanup and backing storage or CDN purge. For defenders, the cleanup point should not be treated as the end of exposure. Cached or mirrored copies can keep the malicious artifact available after public removal. 

The available records still leaves several gaps. The exact credential theft sequence has not been fully proven. The relationship between the generator and spec-json-schemas compromises also remains partly unresolved. Downstream infection counts are unknown and would require repository audit logs, retained workflow logs, npm publication metadata, and endpoint telemetry from affected consumers.

 Attack chain:

Securonix ThreatWatch summary:

Impact assessment: Known impact includes five malicious package versions, import-time retrieval of a second-stage payload, active persistence logic, active C2, and remote shell capability. The pre-publication activity also indicates that the attacker gained repository-side access or tokens sufficient to perform unauthorized pushes or releases. The exact credential sequence is still not fully proven from the available logs.

Impact depended heavily on where the package was loaded. On a developer workstation, the risk included user-space persistence, exposed tokens, SSH key access, browser data exposure, and interactive command execution. In CI/CD, the blast radius could reach source-control credentials, cloud deployment secrets, signing material, shared caches, base images, and downstream build integrity. For downstream consumers, the higher-risk condition was importing the package during the exposure window, not simply having it listed as a dependency.

Mitigation and response recommendations: Start by confirming whether affected versions were resolved, cached, imported, or bundled. Review dependency trees, lockfiles, build manifests, private mirrors, package manager caches, CI caches, and artifact repositories for the five malicious versions. Replace affected versions with known-good releases and purge npm or Yarn caches where applicable. Search for sync.js in the reported NodeJS drop directories across developer endpoints, CI runners, build containers, and shared build images.

Treat any workstation or CI/CD runner that imported an affected package as potentially compromised. Isolate the host where possible, preserve evidence, and check for detached node processes, unexpected sync.js execution, modified shell RC files, systemd user services, Windows Run keys, and other persistence artifacts. Rotate credentials from a clean system, including GitHub tokens, npm credentials, SSH keys, cloud access keys, CI/CD secrets, registry tokens, browser sessions, and signing material that may have been available in the affected environment.

Review release infrastructure in parallel. Audit GitHub Actions workflows that use pull_request_target or other privileged triggers. Reduce default GITHUB_TOKEN permissions, verify branch and environment protections, and confirm who can approve, modify, or trigger release workflows. Review audit logs for unexpected pushes, deleted workflow runs, unusual bot activity, release automation changes, or commits made outside the normal maintainer path.  

Keep provenance controls in place, but do not rely on them alone. Add release approvals for sensitive packages, quarantine newly published upstream dependencies before internal use, apply release-age holds where possible, and compare SBOMs against known-good baselines. Trusted publishing reduces some token exposure. Release-age controls reduce exposure to newly published backdoored packages. Both controls are stronger when paired with source integrity checks and release authorization gates. 

Lessons for defenders: npm supply chain defense cannot stop at blocking postinstall scripts. In this incident, the attacker placed the loader in normal runtime paths, so execution occurred when the package was imported. Detection should account for what packages do at runtime, not only what happens during installation. 

Provenance is useful, but it is not the same as release authorization. The malicious packages were built by legitimate workflows, and the provenance reflected that path. The weak point appeared earlier, where unauthorized source state reached a trusted build and release process. Teams using SLSA-style provenance should pair it with branch protection, workflow separation, protected release environments, and policy checks that evaluate the actor, branch, commit, and review state. 

Developer tooling should be part of the detection surface. SOC and threat hunting teams should correlate package versions, process activity, file writes, and network connections across endpoints and runners. DevSecOps teams should focus on pull_request_target usage, OIDC trust paths, runner isolation, and publish gates. Security leaders should treat build and release systems as production infrastructure and govern them accordingly.

Detection opportunities:

The strongest detection opportunities go beyond package manager logs. This campaign touched source control, CI/CD, runtime process creation, file writes, and network egress. Hunts should pivot across developer endpoints, build runners, source-control audit logs, package metadata, and artifact repositories.

Practical detection concepts:

Threat hunting guidance:

Appendix A: Indicators of compromise

Appendix B: MITRE ATT&CK mapping

Appendix C: Software supply chain security mapping (NIST Secure Software Development Framework)

Analyst assessment:

The operator showed a solid understanding of open-source release mechanics and CI/CD trust boundaries. The choices made in this campaign point to someone who knew where defenders commonly look in npm compromises. Execution was moved into import-time code paths, package publication went through legitimate release workflows, and the infrastructure mixed centralized C2 with decentralized delivery or fallback channels. Even with some payload modules disabled in the analyzed build, the tradecraft suggests more than basic package poisoning. 

The objective was likely durable access and follow-on exploitation, not nuisance publication. Workflow abuse before publication, remote shell capability after execution, persistence logic, and broad credential targeting all point to interest in developer and build environments. There is not enough evidence to attribute the activity to a specific actor or group. Labels such as M-RED-TEAM v6.4 and Miasma-related identifiers should be treated as clustering signals, not attribution proof. 

The main gaps are the exact credential theft sequence, the full relationship between the generator and spec-json-schemas compromises, and the downstream infection count. Stronger conclusions would require repository audit logs, retained workflow logs, registry publication metadata, and endpoint telemetry from affected consumers. As of July 22, 2026, those gaps remain unresolved.

Conclusion:

The July 2026 AsyncAPI incident shows how package compromise, CI/CD workflow abuse, and valid build provenance can all exist in the same attack. The attacker did not need to break every control. They only needed to compromise the trust boundary before publication, then use the official pipeline to distribute the malicious packages. After publication, import-time execution and IPFS-based second-stage delivery increased the chance of execution in developer and build environments where the affected packages were loaded as part of normal use. 

Defensive priorities are straightforward: identify any use of the five malicious versions, inspect affected endpoints and runners for sync.js and persistence artifacts, rotate exposed credentials from clean systems, purge caches and internal mirrors, and harden GitHub Actions workflows that mix untrusted pull request content with privileged repository context. Provenance still has value, but it needs to be paired with stronger controls over source integrity, workflow authorization, and release approval.

References:

• StepSecurity | Coordinated AsyncAPI Supply Chain Attack: Miasma RAT Delivered via Compromised CI/CD Pipelines in Two Repositories 

• Microsoft Security Research | Unpacking the AsyncAPI npm supply chain compromise and import-time payload delivery 

• Aikido | AsyncAPI npm packages backdoored via GitHub Actions 

• Wiz| M-Red-Team: AsyncAPI Supply Chain Compromise via GitHub Actions 

• Datadog Security Labs | Compromised AsyncAPI npm packages: inside a CI supply-chain attack 

• GitHub | [SECURITY] Malicious versions published via compromised next branch 

• GitHub | [SECURITY] Malicious versions published via compromised alpha branch 

• GitHub Docs | Securely using pull_request_target 

• GitHub Docs | Secure use reference 

• GitHub Docs | Workflow syntax for GitHub Actions 

• NIST CSRC | Secure Software Development Framework Project