TL;DR: A stolen npm publish token let attackers backdoor five AsyncAPI packages, Aikido reports, reaching about 2.9 million weekly downloads. Package publish access in CI can turn an import path into a runtime implant path.
Editorial analysis by NHI Mgmt Group, based on content published by Aikido: “AsyncAPI npm packages backdoored via GitHub Actions”.
Key questions
Q: Why do package publish tokens create supply chain risk when reused in CI pipelines?
A: Because publish tokens often combine broad registry authority with weak contextual limits.
Q: What are the signs that an npm package has moved from dependency to implant?
A: Look for code that runs on import, downloads payloads at runtime, writes executable files to user directories, or spawns detached child processes.
Q: What breaks when a GitHub Actions workflow with pull_request_target can reach publish secrets?
A: The workflow stops being a neutral automation step and becomes a privileged access path.
Practitioner guidance
- Harden privileged GitHub Actions triggers Remove secret access from workflows that process untrusted pull requests, especially pull_request_target jobs that can reach publish credentials.
- Separate package publishing from build execution Require reviewed, isolated release jobs for npm publication and ensure build workflows cannot directly mint or use registry tokens.
- Search for import-time execution on developer hosts Look for detached Node processes, unexpected sync.js drops, and package imports that correlate with outbound IPFS, Nostr, or Ethereum traffic.
Bottom line: The incident shows how a CI workflow secret can become a package publishing foothold and then a runtime implant delivery path.
Glossary terms: Pull_request_target workflow, Supply chain implant, Detached child process, Publish token
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Workflow secrets are becoming non-human identities with publish authority. When a GitHub Actions job can reach package registry credentials during untrusted request handling, the workflow is no longer just automation. It is a delegated identity path that needs lifecycle control, event scoping, and publish separation. The practical conclusion is that CI/CD secrets must be governed like any other privileged machine credential.
A question worth separating out:
Q: How should security teams respond when a package registry account or workflow token is compromised?
A: Treat it as a supply chain incident, not a single secret leak. Revoke the credential, remove malicious versions from registries and mirrors, identify every repository and host that imported the package, and rotate adjacent credentials from a clean environment. Then validate that the release path is no longer reachable from untrusted workflow execution.
👉 Read our full editorial: GitHub Actions secret theft turned AsyncAPI npm packages into malware