AsyncAPI npm Packages Compromised via GitHub Actions

A significant security breach has impacted several AsyncAPI npm packages, which collectively receive approximately 2.9 million weekly downloads. The compromise occurred after an attacker exploited a vulnerability in GitHub Actions workflows to gain access to an npm publishing token, leading to the publication of five malicious package versions.

Details of the Attack

The attack originated within the AsyncAPI generator repository, where a GitHub Actions workflow was configured to use the pull_request_target trigger. This setup inadvertently exposed repository secrets when code from external pull requests was executed. The attacker submitted multiple pull requests, one of which was used to exfiltrate the npm token to an external service before publishing the compromised packages.

Security analysts identified the malicious releases on July 14, 2026, tracing the attack from the workflow vulnerability to a persistent remote-access implant. Notably, the infection chain could be initiated merely by importing an affected package, without the need for installation, thereby posing risks to development environments and build systems.

Technical Analysis of the Malicious Code

The compromised package versions include:

  • @asyncapi/specs versions 6.11.2 and 6.11.2-alpha.1
  • @asyncapi/generator version 3.3.1
  • @asyncapi/generator-helpers version 1.1.1
  • @asyncapi/generator-components version 0.7.1

The malicious code was embedded within standard runtime modules, such as schema exports, validation logic, utility functions, and error handling routines. Consequently, a simple require operation could trigger the downloader without relying on npm lifecycle scripts.

Upon execution, the injected code downloaded an encrypted Node.js loader from the InterPlanetary File System (IPFS), saved it as sync.js, and executed it as a detached process. This loader established persistence and provided attackers with a remote shell capable of executing commands and collecting data. Although functionalities for credential theft and self-propagation were present, they were disabled in the observed build.

Persistence Mechanisms and Command-and-Control

The implant employed various methods to maintain persistence across different operating systems:

  • On macOS, it modified shell startup files.
  • On Windows, it created a registry value under the Run key.
  • On Linux, it attempted to write a user service file, though this method was prone to failure due to a lack of a shell wrapper in the execution command.

The malware communicated with an HTTP command-and-control server approximately every 30 seconds, sending encrypted beacons. Even with reconnaissance features disabled, these messages included previews of environment information and checked for configuration files associated with developer tools. More critically, the implant could execute shell commands, providing attackers with a means to collect sensitive information or further infiltrate affected systems.

This incident underscores the critical importance of securing CI/CD pipelines and scrutinizing third-party dependencies. Developers are urged to review their projects for the affected package versions and take immediate remediation steps, including removing compromised packages, rotating exposed credentials, and implementing stricter security measures in their development workflows.