Supply Chain Attack Hits AsyncAPI npm Packages
Security researchers from OX Security, SafeDep, Socket, and StepSecurity have flagged four compromised packages in the AsyncAPI npm namespace. The affected packages 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).
These packages were not just tampered with — they were weaponized to deliver a multi-stage botnet loader. The attack is a stark reminder that even well-maintained open-source projects can become vectors for malware when credentials fall into the wrong hands.
How the AsyncAPI Malware Worked
The malicious code was hidden in the package tarballs, not in the source repositories. This is a classic supply chain trick: the code looked legitimate on GitHub, but the published npm artifacts contained the payload.
Once installed, the loader executed a multi-stage process. It reached out to a command-and-control server to fetch additional payloads, which could include anything from DDoS bots to credential stealers. The researchers noted that the malware was designed to persist on the infected system, making it particularly dangerous for CI/CD environments where these packages are often installed.
Stage One: The Initial Payload
The first stage involved a script that ran during package installation (the “preinstall” hook). This script decoded a hidden blob and executed it, establishing a foothold on the machine.
Stage Two: Botnet Recruitment
The second stage downloaded a botnet client from a remote server. This client connected to a centralized controller, allowing the attackers to issue commands to all infected machines at once.
Who Was Affected and What to Do
Anyone who installed these specific versions of the AsyncAPI packages between the time of the compromise and the discovery is at risk. The affected versions are:
- @asyncapi/generator-helpers@1.1.1
- @asyncapi/generator-components@0.7.1
- @asyncapi/generator@3.3.1
- @asyncapi/specs@6.11.2 and 6.11.2-alpha.1
If you have any of these in your project, you should immediately audit your lock files, rotate any credentials that might have been exposed, and scan for unusual outbound network connections. The npm registry has since removed the malicious versions, but that doesn’t help if you already pulled them down.
Lessons for Open Source Maintainers
This incident underscores a few hard truths. First, publishing to npm requires more than just strong passwords — two-factor authentication is non-negotiable. Second, maintainers should consider using trusted publishers and signing their packages, so that even if credentials are stolen, the published artifacts can be verified.
For consumers, the lesson is to verify package integrity. Tools like npm audit and lockfile verification can catch some issues, but they won’t catch everything. A healthy dose of skepticism about new versions of critical dependencies is wise.
This isn’t the first time the npm ecosystem has been hit. Similar attacks have targeted other popular packages, and they won’t be the last. The open source supply chain security landscape is evolving, but so are the attackers.
Detection and Response
If you suspect you’ve been compromised, look for these indicators:
- Unexpected network connections from your build servers
- Unusual processes running under the Node.js runtime
- Files created in temporary directories that don’t belong to your project
The researchers have published hashes of the malicious artifacts, so you can cross-check your installed versions. If you find a match, treat it as a security incident — not just a bad dependency.
Botnet malware is particularly nasty because it’s designed to be quiet. It won’t crash your app or throw errors. It just sits there, waiting for commands. That’s why proactive monitoring of your build environment is essential.
In the end, this attack is a reminder that the software supply chain is only as strong as its weakest link. For AsyncAPI users, the fix is straightforward: update to the latest patched versions and review your security posture. For the rest of us, it’s a cautionary tale about the risks we all carry in our node_modules.
