A software supply-chain attack compromised four packages in the official AsyncAPI npm namespace, resulting in five malicious package versions being distributed through the project’s legitimate GitHub Actions release pipelines.
The attack occurred on July 14, 2026, and affected packages with approximately three million combined weekly downloads. The malicious releases deployed a multi-stage remote access trojan across Windows, macOS, and Linux systems.
Unlike conventional npm malware that executes through preinstall or postinstall scripts, the AsyncAPI payload activated when an affected module was imported or loaded. This means developer workstations, automated tests, build processes, command-line tools, and CI/CD runners may have executed the malware during normal use.
Organizations that imported or executed an affected package version should treat the relevant systems as potentially compromised.
Compromised Packages
The following AsyncAPI package versions were confirmed to contain malicious code:
| Package | Malicious version | Known clean version |
| @asyncapi/generator | 3.3.1 | 3.3.0 |
| @asyncapi/generator-helpers | 1.1.1 | 1.1.0 |
| @asyncapi/generator-components | 0.7.1 | 0.7.0 or 1.0.0 |
| @asyncapi/specs | 6.11.2-alpha.1 | 6.11.1 |
| @asyncapi/specs | 6.11.2 | 6.11.1 |
All five malicious versions were removed from npm by 11:18 UTC on July 14. However, existing installations, cached artifacts, container layers, package registries and lock files may continue to reference the compromised releases.
How the Attack Occurred
The attack began with the abuse of an insecure GitHub Actions workflow in the asyncapi/generator repository.
The workflow used the pull_request_target event, which runs in the context of the target repository and can access repository secrets. However, it also checked out and executed code supplied through an external pull request. This combination created a “pwn request” condition in which untrusted pull-request code could execute with access to privileged credentials.
At approximately 05:08 UTC, the attacker opened 37 pull requests against the repository. Most appeared to promote a fraudulent charity donation page, creating noise around a single malicious pull request containing obfuscated JavaScript hidden after a large block of whitespace.
Although the malicious pull request was never merged, the vulnerable workflow ran against its code. The payload scanned the GitHub Actions environment and exfiltrated a privileged credential to a dead-drop page hosted on rentry[.]co.
Public reporting differs on the exact credential obtained. Some researchers describe it as an npm publishing token, while others report that it was a highly privileged personal access token associated with the asyncapi-bot service account. However, the subsequent activity indicates that the attacker obtained sufficient access to push directly to protected AsyncAPI repositories and trigger legitimate publishing workflows.
A GitHub Actions hardening pull request addressing this class of weakness had been opened on May 17, 2026, but remained unmerged when the attack occurred nearly two months later. The proposed changes included splitting privileged deployment logic from untrusted pull-request execution, limiting workflow permissions and disabling unnecessary credential persistence.
Legitimate Workflows Published the Malware
At 06:58 UTC, the attacker pushed a poisoned commit directly to the next branch of the asyncapi/generator repository. The commit inserted malicious JavaScript into three legitimate source files.
AsyncAPI’s real release-with-changesets.yml workflow then built and published:
- @asyncapi/generator@3.3.1
- @asyncapi/generator-helpers@1.1.1
- @asyncapi/generator-components@0.7.1
The packages were published at approximately 07:10 UTC.
The attacker subsequently pivoted to the separate asyncapi/spec-json-schemas repository and pushed multiple malicious commits to its master branch. This triggered another legitimate workflow that published:
- @asyncapi/specs@6.11.2-alpha.1 at approximately 08:06 UTC
- @asyncapi/specs@6.11.2 at approximately 08:30 UTC
The malicious packages carried valid npm trusted-publishing and SLSA provenance information because they were genuinely produced by AsyncAPI’s authorized GitHub Actions workflows.
This incident demonstrates an important limitation of build provenance: provenance can verify which workflow and source commit produced an artifact, but it cannot guarantee that the source commit itself was authorized or safe. In this case, the provenance accurately pointed back to a poisoned commit.
Malware Execution Chain
The compromised packages contained an obfuscated JavaScript statement inserted into otherwise legitimate runtime modules.
The payload did not execute during package installation. Instead, importing the affected module triggered a hidden, detached node -e child process. The process suppressed its input and output streams and used windowsHide: true to avoid displaying a console window on Windows.
Stage 1: Obfuscated downloader
The first-stage implant spawned a detached Node.js process and retrieved an encrypted second-stage payload from the InterPlanetary File System, or IPFS.
The malware wrote a file named sync.js to a platform-specific directory designed to resemble legitimate Node.js application data:
- Windows: %LOCALAPPDATA%\NodeJS\sync.js
- macOS: ~/Library/Application Support/NodeJS/sync.js
- Linux: ~/.local/share/NodeJS/sync.js
- Other systems: ~/.config/node/sync.js
Researchers identified two IPFS content identifiers used by the generator and specifications package branches:
- QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9
- Qmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyf
Stage 2: Encrypted loader
The downloaded sync.js files were approximately 8.2 MB and contained encrypted JavaScript loaders.
The loaders used HKDF-SHA256 for key derivation and AES-256-GCM for authenticated decryption. After decrypting the embedded payload, the malware reversed an additional character transformation and loaded the recovered JavaScript into memory.
Using IPFS allowed the attacker to keep the code embedded in the npm packages relatively small while hosting the larger operational payload outside the registry. It also allowed the externally hosted stage to be changed without publishing another npm version.
Stage 3: Miasma-linked remote access framework
The final stage was a large modular malware framework containing approximately 92,000 lines of code. The recovered runtime identified itself in code comments as M-RED-TEAM v6.4 and used several artifacts associated with the Miasma malware family, including miasma-monitor.service and directories under .config/.miasma.
The framework supported:
- Remote shell command execution
- File upload and download
- Directory enumeration
- File collection and exfiltration
- Payload updates
- Persistence
- Encrypted tasking
- Multiple command-and-control channels
The malware included code for accessing browser credentials and cookies, SSH keys, npm and GitHub tokens, AWS credentials, macOS Keychain data, cryptocurrency wallets and secrets stored in CI/CD or developer environments.
However, researchers found that several credential-harvesting, self-propagation and AI-tool poisoning functions were disabled in the recovered configuration. The remote shell and file-management functionality remained sufficient for an attacker to execute commands and collect information manually.
No definitive attribution has been established. The initial access method resembles previously observed prt-scan activity, while the payload contains Miasma branding and code references. Researchers have not determined whether this represents the same operator, shared tooling, code reuse or deliberate misdirection.
Impact Assessment
This incident primarily threatens software-development and build environments.
Potentially affected assets include:
- Developer workstations
- CI/CD runners
- Build servers
- Automated documentation systems
- Container build environments
- Internal package registries
- Systems using AsyncAPI tooling transitively
- Repositories whose pipelines loaded the affected modules
Because the malware executed during module import, finding a malicious package in a lock file does not automatically prove code execution. Security teams must determine whether the relevant package or infected source file was loaded by a test, build, CLI process or application.
Where execution cannot be ruled out, the system should be handled as potentially compromised.
Indicators of Compromise
Malicious package hashes
| Artifact | SHA-256 |
| @asyncapi/generator@3.3.1 | bfaeb987faa6de2b5a5eb63b1233d055215b09b0349a9394f2175fd7cdf385e4 |
| @asyncapi/generator-helpers@1.1.1 | 34014776d3d3ff11bc4439b02fd7ac0f02a887eb3a052eeafff236e2f6db8ad1 |
| @asyncapi/generator-components@0.7.1 | 082d733db0687dcd768104972b065d4b58cb1e6043688c6c20fa3702337f36ab |
| @asyncapi/specs@6.11.2 | 9b2e65db653ca8575c9b10eefb9a80c6006404812c2ec212bf5675e3c690233b |
| @asyncapi/specs@6.11.2-alpha.1 | d425e4583cc6185d41e95c45eda00550045a5d1919b9a012236a4520d009dbd7 |
| IPFS sync.js payload | 24b9ee242f21a73b55f7bb3297eafb33c60840907386b542ed79fc6b72365168 |
| Decrypted final payload | 9e214f38537e69bf51c7fa1ddd35ae495e9cb897231ec010baf9e4f29407ee9a |
These hashes were published by Socket’s threat-research team.
Network indicators
- C2 server: 85[.]137[.]53[.]71:8080
- Upload server: 85[.]137[.]53[.]71:8081
- Proxy-management service: 85[.]137[.]53[.]71:8091
- IPFS gateway: ipfs[.]io
- Nostr relays: relay[.]damus[.]io, relay[.]nostr[.]com
- Ethereum RPC: ethereum-rpc[.]publicnode[.]com
- BitTorrent DHT: router[.]bittorrent[.]com:6881
- BitTorrent DHT: dht[.]transmissionbt[.]com:6881
Several of these domains provide legitimate public infrastructure. Connections should therefore be correlated with Node.js processes, affected package execution and other campaign indicators rather than treated as malicious in isolation.
Host indicators
Security teams should investigate for:
- sync.js under an unexpected NodeJS user-data directory
- Detached node -e processes
- Node.js processes running from %LOCALAPPDATA%\NodeJS
- Node.js processes running from .local/share/NodeJS
- miasma-monitor.service
- Files under ~/.config/.miasma
- Files under ~/.cache/mesa_shader_cache
- Unexpected IPFS, Nostr or BitTorrent DHT traffic from developer or build systems
Recommended Actions
Organizations should take the following actions immediately:
Identify affected systems
Search lock files, software-composition analysis records, container images, artifact repositories and CI/CD logs for the malicious AsyncAPI package versions. Review builds, tests and applications to determine whether an affected module was imported or executed.
Remove compromised packages
Replace malicious versions with known-clean releases and regenerate all affected npm, Yarn or pnpm lock files. Verify that cached artifacts, internal registries and container layers no longer contain the compromised packages.
Contain and investigate affected hosts
Search developer workstations, build servers and CI/CD runners for sync.js, associated hashes, suspicious Node.js processes, persistence mechanisms and network indicators. Isolate any system showing signs of payload execution.
Rebuild systems and rotate credentials
Rebuild confirmed or potentially compromised environments from a trusted state. After containment, rotate all credentials accessible to those systems, including GitHub and npm tokens, SSH keys, cloud credentials, deployment keys, API keys and CI/CD secrets.
Harden the software supply chain
Review repositories for unauthorized commits, releases and workflow activity. Restrict GitHub Actions permissions, avoid running untrusted pull-request code through pull_request_target, separate privileged release jobs from untrusted workflows and consider delaying automatic adoption of newly published packages.
Stay Safe. Stay Secure.
OP Innovate Research Team
