Notifications
Clear all
Topic starter
02/08/2026 9:47 am
TL;DR: Attackers stole an npm publish token from an AsyncAPI GitHub Actions workflow, then used it to backdoor five npm packages that together draw about 2.9 million weekly downloads, according to Aikido. The incident shows how a single workflow misstep can become supply chain compromise, persistence, and downstream credential exposure.
NHIMG editorial — based on content published by Aikido: AsyncAPI npm packages backdoored via GitHub Actions
Questions worth separating out
Q: What breaks when a CI/CD workflow can access secrets from untrusted pull requests?
A: The workflow stops being a safe validation boundary and becomes a secret-exposure path.
Q: Why do npm publish tokens need NHI-style governance?
A: Because they behave like privileged non-human identities.
Q: How do security teams know if a package compromise has become runtime execution?
A: Look for behaviour that occurs when the package is imported, not only when it is installed.
Practitioner guidance
- Harden pull_request_target workflows Move secret-bearing publish steps out of untrusted pull request contexts and require explicit trust separation before any workflow can touch npm publish tokens or other repository secrets.
- Rotate and scope publish identities Treat npm publish tokens, CI/CD service accounts, and related secrets as high-value non-human identities.
- Hunt for runtime execution, not just package presence Search developer laptops, build hosts, and CI runners for sync.js, detached Node processes, and unexpected outbound connections to IPFS or HTTP command channels.
What's in the full article
Aikido's full blog covers the operational detail this post intentionally leaves for the source:
- The exact malicious package versions and hashes needed for repository, mirror, and SBOM hunting.
- The full attacker timeline, including PR IDs, token exfiltration steps, and publish sequence across the AsyncAPI repositories.
- Indicators of compromise for host paths, C2 infrastructure, and platform-specific persistence locations.
- The recovery guidance for cleaning caches, purging the bad tarball, and rebuilding trusted environments.
👉 Read Aikido's analysis of the AsyncAPI npm package backdoor via GitHub Actions →
AsyncAPI package backdoor: what GitHub Actions secret theft enabled?
Explore further
02/08/2026 12:39 pm
Standing automation trust is the real failure mode here. The breach worked because a publish identity was allowed to inherit secret access before the untrusted contribution had been fully separated from the trusted workflow. That is a non-human identity governance problem as much as a supply chain problem, because the token behaved like a privileged actor with no effective boundary. Teams need to treat CI/CD workflows as identity-bearing systems, not just execution glue.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of Secrets Sprawl 2026.
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
A question worth separating out:
Q: Who is accountable when a compromised workflow publishes secrets or malicious changes?
A: Accountability sits with the teams that own repository policy, workflow controls, and privileged access governance, not just the developer whose token was stolen. Organisations should map owner, admin, and automation rights to named control owners so incident response can trace both the compromise path and the permission decisions that enabled it.
👉 Read our full editorial: GitHub Actions secret theft turned AsyncAPI npm packages into malware
