Aikido Security

BleepingComputer

Socket

<h2>What happened</h2>
<p>On July 14, 2025, five npm packages in the AsyncAPI namespace were published carrying a multi-stage malware dropper. The affected packages — <code>@asyncapi/generator@3.3.1</code>, <code>@asyncapi/generator-helpers@1.1.1</code>, <code>@asyncapi/generator-components@0.7.1</code>, <code>@asyncapi/specs@6.11.2</code>, and at least one related package — had a combined weekly download count exceeding 2.25 million. All five malicious versions have since been removed from npm, but the exposure window lasted roughly four hours.</p>
<h2>How the attacker got in</h2>
<p>No npm token was stolen. The attacker pushed a trojanized commit to the repository’s unprotected <code>next</code> branch using a generic git identity. That branch was configured to auto-trigger the project’s legitimate GitHub Actions release workflow, which published the packages to npm using GitHub’s OIDC trusted-publisher integration.</p>
<p>The result: the packages carry valid npm OIDC provenance attestations and SLSA provenance records. This is worth sitting with for a moment. Provenance attestations only prove <em>which workflow</em> produced a package — not that the commit feeding that workflow was legitimate. If a release-triggering branch isn’t protected, attestations provide a false sense of security.</p>
<p>Two separate GitHub repositories were compromised in the same operation, suggesting a coordinated attack rather than opportunistic branch squatting.</p>
<h2>What the malware does</h2>
<p>The payload is injected into <code>src/utils.js</code>, hidden behind whitespace, and fires at <code>require()</code> time — not during <code>npm install</code>. This matters because most security tooling watches for malicious install scripts (<code>preinstall</code>, <code>postinstall</code>). Anything that only scans lifecycle hooks would miss this entirely.</p>
<p>On import, the code spawns a hidden detached Node.js child process that fetches an encrypted second-stage payload — called <strong>Miasma</strong> — from an IPFS gateway. The payload is written to disk as <code>sync.js</code>, disguised as a NodeJS system process.</p>
<p>Miasma is a botnet framework with a fairly complete feature set:</p>
<ul>
<li><strong>Remote shell</strong> — beacons to a C2 server every 30 seconds and executes arbitrary shell commands</li>
<li><strong>Credential harvesting</strong> — targets npm tokens, GitHub tokens, cloud credentials, SSH keys, CI/CD secrets, browser data, AI tool data (Cursor, Claude, VS Code are specifically checked for), and cryptocurrency wallets</li>
<li><strong>File operations and persistence</strong> — config fields like <code>safeMode</code> and <code>actualPersist</code> appear to disable persistence, but call-graph analysis shows persistence actually runs regardless</li>
<li><strong>Multi-protocol C2</strong> — communicates over HTTP, Nostr relays, Ethereum smart contracts, and a libp2p mesh</li>
<li><strong>Self-propagation code</strong> — present but currently toggled off</li>
<li><strong>Evasion</strong> — the detached process and disguised filename are designed to blend into normal Node.js activity</li>
</ul>
<h2>Who’s at risk</h2>
<p>Any developer workstation or CI/CD environment that imported one of the affected packages during the exposure window should be treated as compromised. The trigger is <code>require()</code>, so this includes any build or test run that loaded the package — not just explicit installs.</p>
<h2>What to do</h2>
<p><strong>Immediate steps:</strong></p>
<ol>
<li>Check your lockfiles and <code>node_modules</code> for the affected versions. Hunt for imports, not just installs — <code>grep</code> for <code>require('@asyncapi/generator')</code> and equivalents across your codebase and CI configs.</li>
<li>Look for a <code>sync.js</code> process running as NodeJS, and check for outbound connections to unfamiliar IPs on 30-second intervals.</li>
<li>Rotate everything that was accessible from affected environments: npm tokens, GitHub tokens, cloud credentials, SSH keys, and CI/CD secrets.</li>
<li>Rebuild any compromised hosts rather than trying to clean them.</li>
</ol>
<p><strong>Longer-term:</strong></p>
<ul>
<li>Pin dependencies to verified versions and audit lockfiles and SBOMs regularly.</li>
<li>Treat branch protection on release-triggering branches as seriously as npm token hygiene. An unprotected <code>next</code> branch with publish permissions is an open door.</li>
<li>Don’t rely solely on provenance attestations as a trust signal — they confirm the pipeline, not the commit.</li>
<li>Add detection for Node.js child processes spawned at import time, not just at install time.</li>
</ul>


Collections

Five AsyncAPI npm packages were backdoored on July 14, 2026, via a malicious commit pushed to an unprotected GitHub branch that auto-triggered the legitimate release workflow. The packages received real npm OIDC provenance attestations, making them appear clean to automated checks. The embedded malware, called Miasma, fires on a plain require() rather than install hooks, spawns a hidden Node.js child process, fetches an encrypted second-stage payload via IPFS, and connects to a C2 server every 30 seconds to execute shell commands, harvest credentials, and identify high-value developer targets (Cursor, Claude, VS Code). Affected environments should be treated as fully compromised, with all credentials rotated and sync.js processes investigated. The attack highlights that provenance attestations only verify the pipeline, not the legitimacy of the underlying commit, and that branch protection on release-triggering branches is as critical as npm token hygiene.

AsyncAPI npm packages backdoored with Miasma botnet via unprotected GitHub branch

<p>Another day, another NPM security breach</p>
