Hijacked AsyncAPI npm Packages Slipped a Botnet Loader Into Developer Machines
Four packages under the popular @asyncapi namespace were tampered with to deliver a multi-stage malware loader, in the latest reminder that the open-source supply chain is a soft target.
Key points
- Four packages in the @asyncapi namespace on npm, the code library used by millions of JavaScript developers, were tampered with to deliver malware.
- The affected releases are @asyncapi/generator-helpers 1.1.1, @asyncapi/generator-components 0.7.1, @asyncapi/generator 3.3.1, and @asyncapi/specs versions 6.11.2 and 6.11.2-alpha.1.
- The poisoned packages installed a multi-stage botnet loader, meaning software that quietly pulls down further malware and hands control of the machine to an attacker.
- The activity was flagged by four separate security firms: OX Security, SafeDep, Socket, and StepSecurity.
Someone got into the AsyncAPI project's publishing account and pushed booby-trapped versions of its code to npm.
npm is the giant online library where JavaScript developers download small building blocks of code, called packages, to slot into their own software. When a trusted package gets tampered with, every developer who installs the bad version pulls the poison straight onto their laptop or server.
That is what happened here. Four packages in the @asyncapi namespace, a widely used toolkit for working with event-driven APIs, were replaced with malicious versions. The trap was first written up by The Hacker News, citing research from OX Security, SafeDep, Socket, and StepSecurity.
The compromised releases are @asyncapi/generator-helpers 1.1.1, @asyncapi/generator-components 0.7.1, @asyncapi/generator 3.3.1, and @asyncapi/specs 6.11.2 (plus a pre-release, 6.11.2-alpha.1).
What did the malicious code actually do?
It installed a botnet loader in stages. A botnet is a network of hijacked computers a criminal can command from afar. A loader is the small opening act: it lands first, phones home to a server the attackers control, then downloads whatever they want to run next.
Staging the attack this way is deliberate. The initial package looks small and boring. The nasty payload arrives later, from somewhere else, which makes it harder to spot in a quick code review.
If you want a web-security analogy, this is the npm version of a watering-hole attack: poison a resource that lots of trusted people already drink from, and let them carry the infection home.
Should ordinary developers be worried?
If you or your team pulled any of those exact versions into a build, yes. Treat that machine as suspect.
Check your project's lockfile, the record of exactly which package versions were installed, for the versions listed above. If you find them, roll back to a known-good earlier release of the same package, rotate any credentials that lived on the affected machine, and rebuild from a clean environment.
For everyone else, the practical takeaway is smaller. The AsyncAPI maintainers have pulled the poisoned versions, and npm has removed them from the registry. New installs of the current versions should be clean.
How did the attackers get in?
The published research points to a stolen or misused publishing token, the digital key a maintainer uses to push a new release to npm. It is the same category of failure we have seen in dozens of these incidents: not a clever new exploit, just a credential in the wrong hands.
That matters because the fix is not exotic. Enforce two-factor authentication on every maintainer account. Use short-lived, scoped publishing tokens instead of long-lived ones. Sign releases. Watch for unexpected version bumps.
AsyncAPI is a serious, well-run project. If it can happen to them, it can happen to anyone with a widely-used package and a busy maintainer. The npm supply chain keeps getting hit because the payoff, one poisoned package reaching thousands of downstream builds, is enormous.
Expect more of these. Not fewer.
