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 three million downloads a week. In this case, the payload executes on import/require, not install.
This does not appear directly connected to the previous compromise of @asyncapiin 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.
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:
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:
The second stage is an 8.25 MB encrypted bundle retrieved from IPFS. It contains configuration data and the main runtime.
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.
Package
Version
@asyncapi/generator
3.3.1
@asyncapi/generator-helpers
1.1.1
@asyncapi/generator-components
0.7.1
@asyncapi/specs
6.11.2
@asyncapi/specs
6.11.2-alpha.1
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.
Verizon's latest DBIR highlights how attackers are exploiting familiar weaknesses at increasing speed and scale. Here's what Wiz research reveals about vulnerabilities, trust relationships, and AI in modern cloud environments.
Get a personalized demo
Ready to see Wiz in action?
"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management
Facts Only
On July 14, 2026, an attacker opened 37 pull requests to the AsyncAPI generator repository.
One pull request exploited a `pullrequesttarget` workflow to steal a Personal Access Token (PAT) belonging to asyncapi-bot.
The stolen token was used to push 11 commits to the asyncapi/spec-json-schemas repository.
Five versions of four npm packages under the @asyncapi namespace were published with malicious payloads.
Affected packages include @asyncapi/generator (3.3.1), @asyncapi/generator-helpers (1.1.1), @asyncapi/generator-components (0.7.1), and @asyncapi/specs (6.11.2, 6.11.2-alpha.1).
These packages collectively receive over three million downloads per week.
The payload is a three-stage infection chain that establishes persistence via systemd user services on Linux.
C2 communication occurs via HTTP, Nostr relays, Ethereum smart contracts, and a libp2p mesh network.
The malware targets browser passwords, cookies, SSH keys, npm/GitHub tokens, AWS credentials, macOS Keychain, and cryptocurrency wallets.
A contributor had proposed a fix for the `pullrequesttarget` vulnerability on May 17, 58 days before the attack.
Executive Summary
A sophisticated supply chain attack targeted the AsyncAPI ecosystem by exploiting a "pwn request" vulnerability in GitHub Actions. By using a misconfigured `pullrequesttarget` workflow, an attacker exfiltrated a highly privileged service account token, allowing them to inject malicious code into several widely used npm packages. These packages, which see millions of weekly downloads, deliver a multi-stage payload that establishes persistent command-and-control (C2) connectivity and exfiltrates sensitive developer credentials.
While the malware exhibits technical markers linked to the Miasma framework—such as specific obfuscation methods and C2 branding—other elements, specifically the dead-drop URL patterns, align with the prt-scan campaign. There is no confirmed link to the previous Shai-Hulud 2.0 attack. The breach underscores a critical window of vulnerability, as a proposed fix for the specific GitHub Actions flaw had remained unmerged for nearly two months prior to the exploitation. Security teams are advised to rotate all secrets and audit environments for the affected package versions.
Full Take
The strongest version of this narrative is a cautionary tale of "security debt." The central tragedy is not the sophistication of the attacker, but the 58-day gap between a community-identified vulnerability and its exploitation. This highlights a systemic fragility in open-source maintenance where the speed of discovery exceeds the speed of remediation.
This account functions as a classic vendor advertorial. It leverages a high-stakes security event to create a "fear-to-solution" pipeline. By meticulously detailing the terrifying capabilities of the M-RED-TEAM framework—targeting everything from SSH keys to crypto wallets—it creates a state of urgency that is immediately resolved by the offering of a "pre-built advisory" and "personalized demo." The evidence for the threat is used as the primary justification for the vendor's specific toolset, effectively turning threat intelligence into a lead-generation engine.
Patterns detected: ARC-0015 Authority Game, ARC-0001 Fear Appeal
The root cause is the erosion of trust in the "trusted contributor" model. We are moving toward an era where the act of contributing code (a pull request) is itself a primary attack vector. The second-order consequence is a likely increase in friction for open-source collaboration as repositories implement more restrictive, automated gatekeeping to prevent "pwn requests."
If this were a coordinated influence campaign, the playbook would involve amplifying the "inevitable failure" of manual open-source oversight to push a narrative that only expensive, automated enterprise security platforms can guarantee safety. The content matches this pattern by positioning the vendor as the sole entity capable of "rapid protection" before broader disclosure.
Bridge Questions:
1. If the fix was identified 58 days prior, what organizational or social barriers prevented the merge?
2. How does the shift toward "staged infection chains" and decentralized C2 (Ethereum, Nostr) change the viability of traditional perimeter defenses?
3. Does the reliance on vendor-specific "reputation databases" create a new centralized point of failure for the software supply chain?