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.
- Affected releases: @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, software that quietly pulls down further malware and hands control of the machine to an attacker.
- OX Security, SafeDep, Socket and StepSecurity each flagged the activity independently.
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's exactly 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 findings came from OX Security, SafeDep, Socket and StepSecurity, and were first written up by The Hacker News. We've tracked credential-hijacking attacks on npm packages since 14 July, when criminals used the same playbook against a popular JavaScript security tool, and the pattern keeps repeating.
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 remotely. The loader lands first, phones home to a server the attackers control, then fetches whatever comes next.
Staging it this way is deliberate. The initial package looks harmless; the payload arrives later from somewhere else, which makes it harder to catch in a quick code review. Think of it as the npm version of a watering-hole attack: poison something trusted developers already reach for and let them carry it 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 clean earlier release, rotate any credentials that lived on the affected machine, and rebuild from scratch. For everyone else the risk is lower: the AsyncAPI maintainers pulled the poisoned versions and npm has removed them from the registry.
How did the attackers get in?
Published research points to a stolen or misused publishing token, the digital key a maintainer uses to push a new release to npm. It's the same category of failure behind dozens of these incidents: not a clever new exploit, just a credential in the wrong hands.
The fix isn't exotic. Enforce two-factor authentication on every maintainer account. Use short-lived, scoped publishing tokens instead of permanent ones. Sign releases. Watch for unexpected version bumps. We've said versions of this before, going back to our coverage of poisoned npm packages used as a DDoS weapon on 14 July.
AsyncAPI is a serious, well-run project. If it can happen to them, it can happen to any widely-used package with a busy maintainer. One poisoned release reaching thousands of downstream builds is a large enough payoff that attackers will keep trying.
Expect more. Not fewer.
