AsyncAPI Supply Chain Hit: Multi-Stage Botnet Loader in npm
Just caught wind of a significant supply chain breach affecting the @asyncapi namespace. Researchers from OX Security, SafeDep, Socket, and StepSecurity have identified four malicious packages currently distributing a multi-stage botnet loader.
If you are using AsyncAPI, you need to verify your versions immediately. The compromised packages include:
@asyncapi/generator-helpers@1.1.1@asyncapi/generator-components@0.7.1@asyncapi/generator@3.3.1@asyncapi/specs(v6.11.2, v6.11.2-alpha.1)
The payload is described as a multi-stage loader, which suggests the initial package download is just a dropper. This makes static analysis tricky since the final payload is fetched later. This looks like a classic account takeover scenario targeting a popular library.
I recommend auditing your environments immediately. You can check your package-lock. or run the following to identify installed versions:
npm ls @asyncapi/generator-helpers @asyncapi/generator-components @asyncapi/generator @asyncapi/specs
This is a stark reminder that npm install is effectively executing untrusted code. How is everyone handling dependency verification in CI/CD right now? Are you relying on lockfiles alone, or do you have runtime policies (like OPA or Socket) blocking execution of pre-install hooks?
Good catch on the pre-install hooks. We block all preinstall and postinstall scripts in our CI pipeline by default via .npmrc. It breaks some packages, but it forces the dev team to manually review what needs execution.
# .npmrc
ignore-scripts=true
It's a blunt instrument, but it stops these generic loaders dead in their tracks. Given the rise in supply chain attacks, the convenience of auto-running scripts just isn't worth the risk anymore.
From a SOC perspective, this is messy. Since it's a botnet loader, expect C2 beacons rather than immediate ransomware. If you're hunting, look for child processes of node.exe spawning unexpected shells or PowerShell.
ProcessCreate
| where InitiatingProcessFileName == "node.exe"
| where FileName in ("cmd.exe", "powershell.exe", "bash")
| project Timestamp, DeviceName, InitiatingProcessCommandLine, FileName, CommandLine
Anyone have IOCs for the C2 domains yet? The article mentions researchers found it, but IOCs weren't published in the brief.
We use Socket.dev for this exact reason. They flagged the @asyncapi/generator update almost instantly due to the suspicious behavior in the install script.
If you can't afford commercial tooling, setting up a simple npm audit --production in your pipeline is the bare minimum, though it won't catch zero-day supply chain injections like this without updated signatures. SBOM generation is becoming non-negotiable for quick impact analysis.
Solid advice. For those without commercial tooling, a quick audit of your package-lock. is faster than a full re-install. Run a grep to see if you're holding one of the malicious versions:
grep -E "@asyncapi/(generator-helpers|generator-components|generator|specs)" package-lock. | grep -E "1.1.1|0.7.1|3.3.1|6.11.2"
If you get a hit, treat the host as compromised. These loaders often scrape environment variables during execution, so rotate all secrets immediately.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access