According to The Hacker News, researchers from OX Security, SafeDep, Socket, and StepSecurity have identified a series of compromised packages within the official @asyncapi namespace on the npm registry. This Supply Chain Attack involves the injection of a multi-stage botnet loader into widely used development tools. By targeting the AsyncAPI ecosystem, threat actors aim to compromise the machines of developers and build servers that integrate these packages into their workflows.
The incident specifically affects several packages under the AsyncAPI umbrella. The identified versions include @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 malicious code is designed to execute during the installation or execution phase of these packages, ensuring the infection starts as soon as a developer runs a build or pulls the latest updates.
The primary TTP involves a sophisticated multi-stage infection process. Upon installation, the compromised package triggers a script that fetches a secondary payload from an external C2 server. This payload typically serves as a loader for more advanced malware, such as botnets capable of data exfiltration, credential harvesting, or further Lateral Movement within the corporate network. Because these packages are often part of automated CI/CD pipelines, the malware can bypass traditional perimeter defenses and execute with the permissions of the build agent or developer workstation.
AsyncAPI npm package supply chain attack analysis
The AsyncAPI initiative is a popular open-source project used for defining asynchronous APIs, making it a high-value target for attackers. This specific campaign highlights a growing trend where legitimate, high-reputation namespaces are compromised rather than using simple “typosquatting” techniques. By gaining access to the @asyncapi scope, the attackers leverage the inherent trust developers place in official repositories. This makes the threat harder to identify using basic automated tools that only flag unknown or suspicious package names.
The multi-stage loader identified in this campaign is particularly evasive. It often uses environment checks to ensure it is not running in a sandbox or a security researcher’s analysis environment before proceeding with the final infection. This makes it difficult for some EDR solutions to catch the initial malicious behavior if the installation script appears benign or performs standard network requests. The loaders are also known to use obfuscated JavaScript to hide their true intent from static analysis tools.
How to detect compromised npm packages in build pipelines
To effectively detect compromised npm packages in build pipelines, security teams must implement deep inspection of dependency trees. Standard npm audit commands may not always identify Zero-Day compromises before they are officially reported in the CVE databases. Instead, SOC analysts should look for IoC such as unexpected outbound connections from build servers to unknown domains during the npm install phase.
Monitoring for unauthorized file system changes or the spawning of suspicious child processes—such as curl, wget, or PowerShell—from the Node.js process can provide early warnings of a compromise. Organizations should also consider using “lockfiles” (such as package-lock.json) and verifying the integrity hashes of every package to ensure they match known-good versions. Any deviation in the hash for a package version that has already been cached should be treated as a high-severity alert.
Mitigation and Strategic Defense
The immediate priority for any organization using AsyncAPI tools is to audit their current dependencies. If any of the affected versions are found, they must be removed and replaced with verified clean versions. Developers should also rotate any credentials or environment variables that were stored on systems where the compromised packages were executed.
How to secure npm dependencies against botnet loaders
Securing the software supply chain requires more than just reactive patching. When considering how to secure npm dependencies against botnet loaders, companies should adopt a Zero Trust approach to third-party code. This includes:
- Pinning Dependencies: Use specific, audited versions of packages rather than using wildcard ranges in your
package.jsonfile. - Private Registry Proxies: Implement tools like Artifactory or Nexus that can scan packages for malware and vulnerabilities before they are made available to internal development teams.
- Network Segmentation: Restrict build environments from reaching the public internet except for a whitelist of approved update servers and registries.
- SCA Implementation: Utilize Software Composition Analysis tools that provide real-time alerts on namespace compromises and maintain an up-to-date Software Bill of Materials (SBOM).
While no CVE has been formally assigned to this specific campaign at the time of reporting, the severity of a compromised official namespace cannot be overstated. Security professionals must treat this as a high-priority incident and verify that their SIEM is logging all relevant telemetry from developer endpoints and cloud build environments.
Related: HalluSquatting: AI Coding Assistants Tricked into Botnet Malware, Glassworm Botnet Infrastructure Disrupted: Solana and DHT C2 Analysis