# Supply-Chain Strike: AsyncAPI npm Packages Infected with Multi-Stage Credential Stealer
A sophisticated supply-chain attack delivered a credential-stealing remote access trojan to millions of developers through five malicious versions of popular AsyncAPI packages on npm, exploiting a misconfigured GitHub Actions workflow to bypass security controls and publish trojaned code with legitimate digital signatures.
## The Threat
On July 14, 2026, attackers compromised two AsyncAPI GitHub repositories and injected malware into project files, publishing five malicious package versions to npm's public registry. The attack had a brief but devastating exposure window of approximately four hours and seven minutes (07:10 to 11:18 UTC), during which the trojaned packages accumulated an estimated 2.25 million weekly downloads across multiple packages in the @asyncapi namespace.
The affected packages included:
| Package | Malicious Version | Weekly Downloads |
|---------|------------------|-----------------|
| @asyncapi/generator | 3.3.1 | 101,000 |
| @asyncapi/generator-helpers | 1.1.1 | 43,000 |
| @asyncapi/generator-components | 0.7.1 | 34,000 |
| @asyncapi/specs | 6.11.2-alpha.1, 6.11.2 | 2.1 million |
All five malicious package versions have since been removed from npm, but developers with existing installations or lock files created during the exposure window remain at risk.
## Background and Context
AsyncAPI is a widely-used open-source specification and toolkit for building event-driven applications, relied upon by thousands of organizations across industries. The project maintains a GitHub repository with legitimate npm packages that developers download millions of times weekly as core dependencies in their applications.
This attack represents a particularly dangerous vector in the software supply chain: rather than targeting the npm registry directly through stolen credentials or exploiting npm's security infrastructure, the attackers went upstream to compromise the projects' build and release pipeline. By exploiting a misconfigured GitHub Actions workflow, they were able to inject malicious code before publication—a strategic move that ensured their trojaned packages would carry legitimate SLSA provenance attestations from npm's GitHub OIDC trusted-publisher integration.
In the evolving landscape of supply-chain attacks, this approach represents a maturation of tradecraft. Previous attacks have relied on stolen npm publishing tokens or social engineering maintainers. This attack bypassed both by operating at the CI/CD layer, where legitimate automation carries inherent trust.
## Technical Details: A Three-Stage Malware Delivery
Security researchers from Step Security, Socket, and Wiz mapped a sophisticated three-stage attack flow:
Stage One: Obfuscated Downloader
The initial payload injected into the npm packages was an obfuscated JavaScript statement hidden within project files. When the infected package was imported into a developer's application, this statement executed automatically, triggering a downloader routine. This first-stage implant was intentionally minimal—designed to evade static analysis and execute with minimal detection surface.
Stage Two: IPFS-Hosted Payload Delivery
The downloader fetched a second-stage script from the IPFS (InterPlanetary File System) peer-to-peer network, a distributed content delivery system that makes takedown and tracking significantly more difficult than traditional centralized hosting. This second stage contained configuration details and the main malware runtime, launched as a hidden background process with no visible window or system tray indicator.
Stage Three: 92,000-Line Malware Framework
The final payload, according to Wiz researchers, is a 92,000-line malware framework with modular architecture that establishes persistence on infected systems and establishes command-and-control (C2) communications through multiple channels:
This multi-channel approach dramatically complicates detection and blocking—defenders cannot simply firewall a single IP or domain.
### The Miasma Connection (and Uncertainty)
The malware framework uses artifact names and configuration files associated with the Miasma backdoor, which appeared in previous supply-chain attacks. However, SafeDep researchers noted significant uncertainty about attribution: the malware is "either a private, parallel build by the same operators or a separate group that adopted the Miasma brand after the source was published." This ambiguity itself is concerning—it suggests either a coordinated group with multiple tools or a sufficiently public malware framework that competitors are reusing it.
### The Data Harvesting Campaign
The malware's stated capabilities included stealing:
The malware also included automated downloads of Gitleaks and HackBrowserData—legitimate security tools repurposed for offensive data extraction.
Critical Finding: Cybersecurity company Aikido discovered that the data harvesting functions did not work as implemented—the exfiltration routines were non-functional and terminated before collecting data. However, Aikido researchers noted that the malware's shell access means attackers could manually execute harvesting operations regardless. Additionally, Ox Security reported that the malware performed a local check for Russia—if detected, it terminated itself, suggesting operational security controls by the threat actor.
## Implications for Organizations
### Who Was Affected
Any developer or organization that installed these five packages during the four-hour exposure window is potentially affected. The sheer scale—2.25 million weekly downloads—means that thousands of applications may be running trojaned code in production environments.
High-risk categories include:
### The Persistence Risk
This attack differs from ephemeral npm incidents because:
1. Existing installations persist even after package removal from npm. Any machine that installed the trojaned package during the exposure window may still have malware running.
2. Lock file contamination: Projects using package-lock.json or yarn.lock files may continue reinstalling trojaned versions during npm install operations unless explicitly regenerated.
3. Hidden process execution: The malware launches as a background process with no obvious system indicators, potentially running undetected on developer machines and CI/CD systems for extended periods.
### Credential and Secret Exposure
If the malware successfully established persistence on development machines or CI/CD systems before remediation, all credentials available to that environment are considered compromised:
## Recommendations
### Immediate Actions (0-24 hours)
1. Check installation timelines: Review your project's npm installation logs for package installs between 07:10-11:18 UTC on July 14, 2026. If @asyncapi/* packages were installed during this window, your systems may be affected.
2. Inspect lock files: Search package-lock.json, yarn.lock, or pnpm-lock.yaml for the malicious package versions listed above.
3. Kill malicious processes: Look for hidden Node.js processes, particularly any running NodeJS/sync.js. Use process monitoring tools to identify unexpected background processes.
4. Remove malicious files: Search your systems for the hidden payload directory and remove it completely.
### Medium-term Actions (24-72 hours)
5. Regenerate lock files: Delete existing lock files and run npm install or yarn install to generate clean files with patched package versions.
6. Update to patched versions: Upgrade all @asyncapi packages to versions released after July 14, 2026.
7. Rotate all credentials: Treat this as a credential compromise event. Rotate or invalidate:
- GitHub personal access tokens and deploy keys
- Cloud provider credentials
- Database passwords and connection strings
- API keys for all integrated services
- Cryptocurrency wallets (if applicable)
### Long-term Actions (ongoing)
8. Audit CI/CD security: Review GitHub Actions workflows for misconfigured permissions and insufficient branch protection rules.
9. Monitor for C2 communications: Implement network monitoring for unusual outbound connections to IPFS nodes, Ethereum RPC endpoints, Nostr relays, or libp2p networks.
10. Implement secrets scanning: Deploy tools like GitLeaks, TruffleHog, or native GitHub secret scanning to detect any exposed credentials in your codebase.
---
## HackWire Analysis
This attack represents a troubling inflection point in supply-chain security. The sophistication lies not in the malware itself—which was notably non-functional—but in the methodology of trust exploitation. By compromising the build pipeline rather than stealing credentials, the attackers ensured that npm's own security infrastructure (SLSA attestations, OIDC trusted publishers) vouched for their malicious code.
The non-functional data harvesting is equally telling. It suggests either rushed development, operational caution, or confidence that persistence alone is valuable. In a supply-chain context, planting a backdoor on thousands of developer machines for future use is often more valuable than immediate credential theft—you're positioning yourself inside the build processes of applications your target enterprises depend on.
What's particularly concerning is the multi-channel C2 approach using blockchain, IPFS, and Nostr. These mechanisms are specifically designed to resist traditional network defense and law enforcement takedown. An organization that detects this malware and blocks HTTP C2 channels may believe it's remediated the threat, only to discover that Ethereum contract-based commands continue arriving. This is defensive evasion at scale.
The Miasma attribution uncertainty is the final red flag. Whether this is the same group or copycat operators, it demonstrates that successful supply-chain attack techniques are now replicable and reproducible. The bar for mounting million-download-scale attacks has lowered significantly.
The immediate technical impact (non-functional data harvesting) should not obscure the strategic threat: this was a beachhead operation with clear intent to establish persistence inside enterprise build systems. The fact that it failed partially is luck, not defense. Organizations should assume any machine in their build environment during the exposure window requires forensic analysis and complete credential rotation.
— HackWire Editorial
---
## Related Coverage