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

On July 14, 2026, an attacker opened 37 pull requests to the AsyncAPI generator repository. Almost all attempted to add a fake charity donation page. Camouflage in the noise, a single PR exploited a misconfigured GitHub Actions workflow to steal a highly privileged Personal Access Token. 

Four malicious npm packages (five total versions) were published under the @asyncapi namespace. The packages contain a multi-stage payload that establishes persistence and connects to command and control infrastructure. Combined, these packages see over 140,000 downloads per day. In this case, the payload executes on import/require, not install.

This does not appear directly connected to the previous compromise of @asyncapi in the Shai-Hulud 2.0 attack.

What Happened?

The attacker exploited a vulnerability class known as a “pwn request” in GitHub Actions. The asyncapi/generator repository contained a workflow file that used pull_request_target to trigger on pull requests, but then checked out the pull request’s code rather than the base branch.

This is dangerous because pull_request_target runs in the context of the base repository with full access to secrets. When the workflow checks out attacker-controlled code from the pull request and executes it, those secrets become accessible.

Unfortunately, the potential for this vulnerability had been identified months before the attack. On April 29, a contributor opened a PR investigating the issue with a proof-of-concept payload. On May 17, they followed up a proposed fix that split the workflow into two separate jobs to isolate secret access from untrusted code. That fix was still open, unmerged, when the attacker struck 58 days later.

At 05:08 UTC, the attacker opened PR #2155 containing a markdown file with obfuscated JavaScript hidden after approximately 1,000 bytes of whitespace. The payload was designed to scan the GitHub Actions runner’s environment for secrets and exfiltrate them to a dead-drop URL on the rentry.co pastebin.

Automated review flagged the obfuscation and while the PR was never merged, the damage was already done. The workflow completed at 05:16 UTC and the attacker was able to retrieve the stolen credentials.

The compromised token appears to be a PAT belonging to asyncapi-bot, a service account with access across the AsyncAPI organization.

Malicious Packages Published

Using the stolen PAT, the attacker pushed a malicious commit directly to the `next` branch at 06:58 UTC. This triggered the release workflow, which published the initial three compromised packages to npm at 07:10 UTC.

The attacker then pivoted to the asyncapi/spec-json-schemas repository, pushing 11 commits between 07:51 and 08:28 UTC. Two additional malicious versions of @asyncapi/specs were published.

All five versions contain the same payload injected into different files. The malicious code is hidden on the first line of legitimate source files, padded with whitespace to push it off-screen in most editors.

Connections to other attacks 

The payload shares some technical characteristics with the Miasma malware framework previously documented in supply chain attacks. The obfuscation layer uses javascript-obfuscator with a custom base64 alphabet, the same configuration seen in prior incidents.

The Stage 3 runtime explicitly self-identifies as "M-RED-TEAM v6.4" in code comments describing beacon encryption and C2 communication protocols. The extracted configuration file sets giteaPackagesOrg to "miasma-test-org." The payload uses miasma-monitor.service within the persistence code. The Nostr relay C2 uses "miasma” branded tags. 

However, the Rentry dead-drop URL uses the slug "elzotebo," matching naming patterns from the prt-scan campaign, which has been linked to previous pull request-based attacks. The prt-scan campaign has not been linked to Miasma. 

Beyond the references and initial obfuscation method the payload contains minimal resemblance to previous Miasma and Shai-Hulud payloads. Instead of a worm, it appears to contain a fully fledged commands framework with classic Trojan capabilities (Dirlist, GetFile, PutFile, etc.) with a direct connection to command and control infrastructure.

At this time, we are not making any definitive attribution.

Payload  

The payload follows a staged infection chain: 

1. The first stage is executed on package import.  It spawns a detached child process that downloads the next stage from IPFS, saving it to a platform-specific directory:

   1. Linux: ~/.local/share/NodeJS/sync.js

   2. macOS: ~/Library/Application Support/NodeJS/sync.js

   3. Windows: %LOCALAPPDATA%NodeJSsync.js

2. The second stage  is an 8.25 MB encrypted bundle retrieved from IPFS. It contains configuration data and the main runtime.

3. The third stage is a 92,000-line malware framework with modular architecture. It establishes persistence via systemd user services on Linux and communicates with command and control infrastructure over multiple channels including HTTP, Nostr relays, Ethereum smart contracts, and a libp2p mesh network.

The payload includes credential theft capabilities targeting browser saved passwords and cookies (Chrome, Brave, Firefox, Edge), SSH keys, npm and GitHub tokens, AWS credentials, macOS Keychain, and cryptocurrency wallets. Once installed, the malware appears to accept remote commands for file operations, directory listing, and data exfiltration.

What steps should security teams take?

Wiz detected this attack through its automated malicious package monitoring system and immediately added hash-based detection to its reputation database followed by advisory release and package based detection, enabling rapid protection for Wiz customers before broader disclosure.

• Organizations should immediately investigate developer workstations, CI/CD environments, and repositories for signs of compromise. Teams should audit systems for the affected packages.

• Because the malware targets developer credentials and secrets, organizations should assume potential exposure of GitHub tokens, SSH keys, cloud credentials, and CI/CD secrets, and rotate them accordingly.

• Finally, organizations should strengthen software supply chain defenses by implementing dependency allowlisting, SBOM generation, package verification, and improved monitoring of developer and build environments.

How Can Wiz Help?

Wiz customers should refer to the pre-built advisory in the Wiz Threat Intel Center for actionable steps to investigate, remediate, and harden their environments. Wiz Research will continue to update that advisory as the situation develops.

Indicators of Compromise