AsyncAPI npm Packages Poisoned via Malicious PR

How the attack worked

The compromise began not with a stolen credential but with a pull request. Attackers submitted a PR to the asyncapi/generator repository that targeted a docs-preview automation workflow. That workflow used pull_request_target while also checking out the untrusted head commit of the PR, combining two unsafe choices that placed attacker-controlled code inside the base repository's privileged security context. The submitted content was designed to fetch and evaluate remote JavaScript, giving the attacker a foothold to eventually publish poisoned versions of AsyncAPI-related npm packages.

From there, five versions across four packages were republished with a hidden loader. When any downstream build or application imported one of these packages, the injected code ran immediately, spawning a child process that downloaded a second-stage payload, sync.js, from a public IPFS gateway and connected to command-and-control infrastructure.

Why it succeeded

Several factors let this campaign slip past common defenses. The malicious code executed at module-load (import/require) time rather than during install, so the widely used npm install --ignore-scripts mitigation had no effect. The poisoned packages were also published through the project's legitimate GitHub Actions OIDC release workflow, which meant the resulting artifacts carried valid provenance signatures accurately tied to the real repository, commits, and workflow, even though the triggering commits themselves were unauthorized. This shows that verified publishing pipelines and signed provenance can still carry compromised code if the upstream automation is manipulated.

What to watch for

• A pull request that triggers a privileged workflow using pull_request_target while checking out untrusted PR code
• Documentation or content files that attempt to download and evaluate remote JavaScript
• Unexpected detached Node.js child processes appearing during builds or application startup
• Network connections to IPFS gateways or unfamiliar IP addresses and ports
• New directories masquerading as legitimate Node.js paths containing unexpected files like sync.js

Building resistance

Teams that build or maintain open source tooling should treat pull request automation as a high-risk entry point and avoid running untrusted PR code with access to secrets or privileged tokens. Because valid provenance does not guarantee a safe build, organizations should monitor for import-time execution patterns and unusual child processes rather than relying solely on install-time protections. If a build system or developer workstation imported a compromised version, credentials and secrets should be rotated from a clean host, and npm and Yarn caches should be purged along with a search for the sync.js artifact across affected environments.

How did attackers compromise the AsyncAPI npm packages?

A malicious pull request targeted a docs-preview workflow that used pull_request_target and checked out untrusted PR code, giving the attacker's content access to the base repository's security context and enabling code execution.

Does npm install --ignore-scripts protect against this attack?

No. The malware executed at module-load time when the package was imported or required, not during install, so the common --ignore-scripts mitigation did not prevent it.

Were the poisoned packages still cryptographically signed?

Yes. The legitimate GitHub Actions OIDC release workflow published the poisoned packages with valid provenance signatures, even though the underlying commits were unauthorized.

What should teams do if they imported an affected package?

Remove all affected versions, purge npm and Yarn caches, hunt for the sync.js payload, and rotate credentials from a clean host since second-stage execution can expose tokens.