AsyncAPI: 5 Malicious npm Packages with Valid SLSA Attestations…

Attackers compromised two AsyncAPI GitHub repositories via a misconfigured pull_request_target workflow, then used legitimate CI/CD pipelines with OIDC trusted publishing to sign and publish five malicious package versions to npm. The packages carried valid SLSA provenance attestations on Sigstore/Fulcio, yet contained the Miasma modular botnet framework with six independent C2 channels and module-load execution that bypasses npm install --ignore-scripts.

On July 14, 2026, between 07:10 and 11:18 UTC, five malicious versions of AsyncAPI npm packages remained available for download with perfectly valid SLSA provenance attestations. The attackers stole no npm tokens and breached no registry: they compromised two GitHub repositories by exploiting a misconfigured workflow, then used legitimate CI/CD pipelines with OIDC trusted publishing to cryptographically sign the malware. The result was a distribution that appeared technically flawless.

Execution occurs at module load (require()), not during npm install. This detail renders the standard --ignore-scripts mitigation useless and forces a rethink of JavaScript supply chain security assumptions.

Key Takeaways

Five malicious versions published across four @asyncapi packages with over 2.25 million cumulative weekly downloads, according to BleepingComputer
SLSA attestations on Sigstore/Fulcio were authentic: they certified that the authorized workflow produced the package, not that the triggering commit was legitimate
Module-load execution bypasses --ignore-scripts; the malware activates when an application calls require(), not during installation
The Miasma payload uses six independent C2 channels (HTTP, Nostr, IPFS, BitTorrent DHT, libp2p GossipSub, Ethereum smart contract) with cross-platform persistence
The pull_request_target vulnerability was known since April 2026: a proof of concept had been submitted but the fix pull request remained open and unmerged

How the Repositories Were Compromised

The attack targeted two repositories: asyncapi/generator (next branch) and asyncapi/spec-json-schemas (master branch). The first malicious push, with commit SHA 3eab3ec9304aa26081358330491d3cfeb55cc245, landed on the next branch at 06:58:42 UTC, as documented by StepSecurity. Twelve seconds after the push, the GitHub Actions workflow executed the release.

The mechanism exploited no zero-day in GitHub Actions, but a known dangerous configuration. According to Wiz researchers Rami McCarthy and Merav Bar, the asyncapi/generator repository contained a workflow file that used pull_request_target to trigger on pull requests, but checked out the pull request's code instead of the base branch. This is critical because pull_request_target runs in the base repository's context with full access to secrets.

The git identity used for the commits was a placeholder: "Your Name" with email you@example.com and GitHub login "invalid-email-address". The dossier does not specify whether this indicates a compromised personal token, a breached GitHub App, or another push access mechanism.

The Provenance Paradox: When Cryptographic Signatures Mislead

The technical turning point of the attack is the production of valid SLSA attestations on malicious packages. StepSecurity analyzed the Sigstore Fulcio certificates: each package carried metadata recording repo:asyncapi/generator:ref:refs/heads/next, the exact workflow file, the commit SHA, and the run URL.

As StepSecurity researcher Rohan Prabhu observed: "Both attacks are CI/CD pipeline compromises, not stolen npm tokens or malicious maintainers". The distinction is substantial: the OIDC trusted publishing mechanism worked exactly as designed, conferring cryptographic authenticity on code injected from the outside. Provenance and code legitimacy have become disjoint categories.

"The resulting packages carry legitimate SLSA provenance attestations, proving only that the project's authorized workflow produced them, not that the triggering commits were legitimate. Provenance does not protect against a compromised push credential." — StepSecurity

require() Execution and the --ignore-scripts Bypass

Most npm supply chain defenses focus on lifecycle scripts (preinstall, postinstall). Experienced users run npm install --ignore-scripts to neutralize payloads that activate in that phase. This attack ignores that vector entirely.

The malicious code is an obfuscated JavaScript implant of approximately 7.7 KB injected into package files. When an application or CI/CD executes require() on the module, the dropper activates: it spawns a detached Node.js process that downloads a second stage. According to Microsoft: "Because the trigger is an import rather than an install script, the common npm install --ignore-scripts mitigation does not neutralize it". StepSecurity confirms: "This dropper fires when the poisoned module is require()d during normal use of the generator: the moment a build or CI job actually calls into the library, not at npm install time".

The second stage is an encrypted sync.js file of approximately 8.25 MB, downloaded from IPFS via two distinct CIDs for the two attacked repositories: QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9 for generator and Qmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyf for spec-json-schemas. Decryption uses HKDF-SHA256 and AES-256-GCM, producing a 3.09 MB Miasma payload.

Miasma: A Modular Framework with Six C2 Channels

The final payload is the Miasma framework, composed of 744 modules according to The Hacker News. Its C2 architecture is designed for resilience: six independent channels reduce reliance on a single point of control. Beyond classic HTTP, the framework uses Nostr relays, IPFS, BitTorrent DHT, libp2p GossipSub mesh P2P, and Ethereum smart contracts to receive commands and distribute updates.

Persistence mechanisms cover Linux (systemd, crontab), macOS (launchd), and Windows (Registry autostart). Anti-analysis includes sandbox and VM detection, Russian language verification, dead man's switch on stolen token, and evasion of eight security tools: CrowdStrike, SentinelOne, Microsoft Defender, CarbonBlack, Cylance, Osquery, Tanium, and Qualys.

Despite the Miasma branding, attribution remains uncertain. OX Security, via researcher Moshe Siman Tov Bustan, explicitly denies links to previous campaigns: "this malware isn't the same as [past Miasma/Shai-Hulud/TeamPCP campaigns], nor is it attributed to them". SafeDep suggests instead "either a private, parallel build by the same operators or a separate group that adopted the Miasma brand after the source was published". Aikido Security adds caution: "The Miasma branding may reflect code reuse, imitation, or deliberate mislabeling. No definitive attribution is made here".

Microsoft tracks the malware as MiasmStealer/Supychain. Credential-stealing, AI tool poisoning, and registry propagation capabilities were present in the code but toggled off, according to Microsoft and Aikido: the dossier does not clarify whether this was due to incomplete deployment or deliberate staging.

What to Do Now

Priority actions for teams using AsyncAPI or managing similar pipelines:

Audit pull_request_target workflows across all repositories: verify they check out the base branch, not the pull request code, and that they lack access to secrets unless strictly necessary
Inspect build and CI/CD logs between 07:10 and 11:18 UTC on July 14, 2026 for require() calls to @asyncapi packages in compromised versions, not just install script executions
Implement runtime network monitoring in CI/CD pipelines: StepSecurity confirmed C2 IP 85.137.53.71 via Harden-Runner telemetry that blocked connections to 85.137.53.71:8080, dht.transmissionbt.com, and router.bittorrent.com at 08:59:49-50 UTC
Review SLSA attestation trust policy: the presence of a Sigstore attestation does not replace verification of the source code and workflow configuration that generated it

Why This Attack Changes Supply Chain Terms

The AsyncAPI incident is not a story of stolen tokens or a breached npm registry. It demonstrates that security infrastructure introduced to solve previous problems—provenance attestations, OIDC trusted publishing, SLSA—can become elements of the attack when the adversary moves the target upstream, to the pipeline itself. The cryptographic signature becomes a veil, not a shield.

Module-load execution demands a paradigm shift: defense can no longer stop at installation boundaries. And the proof of concept known since April 2026, with the fix unmerged at the time of the attack, raises a governance question: how many documented configuration vulnerabilities sit waiting in the pull request queues of critical open source projects?

Information verified against cited sources and current as of publication.

Sources

Sources and references