GitHub Actions secret theft turned AsyncAPI npm packages into malware

At a glance

What this is: This is a supply chain compromise in which a GitHub Actions workflow flaw enabled token theft, malicious npm package publishing, and a persistent Node.js implant.

Why it matters: It matters because build and publish pipelines can turn repository secrets into broad downstream compromise, forcing IAM, PAM, and NHI teams to treat CI/CD tokens as high-risk identities.

By the numbers:

• At 05:08 UTC on July 14, the attacker opened 37 pull requests against the generator repository.

👉 Read Aikido's analysis of the AsyncAPI npm package backdoor via GitHub Actions

Context

GitHub Actions workflows can become an identity problem, not just a build problem, when repository secrets are exposed to untrusted pull request context. In this case, an attacker used that exposure to steal an npm publish token and then turn trusted package distribution into a malware delivery path. For IAM and NHI teams, the core issue is not the package name but the publish identity attached to the pipeline.

The primary governance gap is standing trust in automation that can access secrets before code has been fully trusted. That gap matters across software supply chain security, CI/CD hardening, and non-human identity governance because tokens, service accounts, and workflow credentials are all acting identities with material blast radius. This is a typical example of how a single control failure can cascade into package compromise and runtime persistence.

Key questions

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. Any token or service account available to that run can be stolen and reused to publish malicious code, sign artefacts, or move into adjacent systems. That is why secret access must be separated from untrusted code execution and tightly scoped to the exact publish step.

Q: Why do npm publish tokens need NHI-style governance?

A: Because they behave like privileged non-human identities. A publish token can authenticate software, modify supply chain trust, and reach thousands of downstream environments through a single release. That makes lifecycle control, rotation, revocation, and narrow permissioning essential, especially when the token is stored in automation that executes without human oversight.

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. Detached Node processes, dropped files such as sync.js, unexpected outbound IPFS or HTTP traffic, and changes in user-level startup paths are strong indicators that malicious code has moved from dependency risk into active execution.

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.

Technical breakdown

How pull_request_target exposed the publish token

The pull_request_target trigger runs in the context of the base repository, which means it can access secrets even when the code comes from an external pull request. That design is useful for automation, but it creates a trust boundary problem if untrusted content can influence the workflow before validation. In this case, the attacker used a flood of pull requests and an obfuscated payload to exfiltrate the npm publish token. The result was not merely CI compromise but identity abuse of a privileged automation token.

Practical implication: restrict secret access in pull_request_target workflows and separate untrusted validation from secret-bearing publish steps.

Why normal runtime imports became the delivery mechanism

The malicious code was embedded in modules that execute during normal use, not in npm lifecycle hooks. That matters because a simple require() became enough to trigger a detached downloader, which then wrote sync.js to a per-user data path and launched it in the background. This pattern blends package compromise with runtime execution, making static package approval insufficient if teams do not inspect module load paths and post-install behaviour. The implant’s persistence comes from ordinary application use, not from an obvious installer event.

Practical implication: inspect runtime import paths and module behaviour, not just install scripts, when assessing package trust.

How the implant maintained persistence and command execution

The payload used an encrypted IPFS-delivered loader, local file drops, and platform-specific persistence techniques to survive restarts. It also maintained a beacon-and-command loop over HTTP, with plaintext fallback when encrypted commands were absent, which means transport security did not eliminate execution risk. Because the shell command path was only lightly constrained, the operator could execute arbitrary commands once the implant was active. This is a classic example of a supply chain foothold evolving into a remote shell on developer and build systems.

Practical implication: hunt for detached Node processes, dropped sync.js files, and unusual outbound C2 before assuming the compromise is limited to package integrity.

Threat narrative

Attacker objective: The attacker’s objective was to convert trusted package distribution into persistent remote control over developer and build environments.

1. Entry occurred when the attacker abused a pull_request_target workflow to steal an npm publish token from the repository secret context.
2. Escalation followed when the attacker used the stolen token to publish trojanized npm packages and place malicious code in normal runtime modules.
3. Impact came from a persistent Node.js implant that fetched encrypted loaders, established command execution, and created a remote shell on affected systems.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Package compromise is increasingly a runtime identity issue, not only a dependency integrity issue. The malicious code executed on module load, which means trust decisions at install time were not enough to prevent execution. This is where NHI governance intersects with software supply chain security: tokens, package publish permissions, and build automation all need lifecycle control, revocation discipline, and narrow purpose scoping. Practitioners should assume that any reusable automation identity can become a delivery vector.

GitHub Actions and npm now sit inside the same attack surface as cloud IAM and PAM. The attacker did not need a novel exploit chain once the token was available, because the workflow already encoded excess privilege into ordinary automation. That is consistent with broader identity security patterns in which standing credentials, weak segregation of duties, and delayed remediation create the breach window. The practical conclusion is simple: if a workflow can publish software, it deserves the same governance as any privileged service account.

Ephemeral review gaps create durable supply chain exposure. The fix PR had been available for nearly two months, which shows how long a known workflow weakness can remain exploitable when secret-bearing automation is not tightly governed. The named concept here is publish-token blast radius: the distance between a single compromised workflow token and the number of systems that inherit trust from it. Security teams should use that concept when ranking CI/CD identities for tighter controls and faster rotation.

Attackers are increasingly using package ecosystems as identity amplifiers. Once a publish token is stolen, the attacker can borrow the reputation and distribution reach of the maintainer identity to push code into many environments at once. That means governance cannot stop at source code review or malware detection. The practitioner takeaway is to reduce the authority of build-time identities before they can be turned into mass-delivery mechanisms.

From our research:

• 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.
• Forward look: Use Top 10 NHI Issues to prioritise workflow identities, token scope, and secret exposure paths before a package compromise reaches production.

What this signals

The strategic signal for security teams is that release automation is now part of identity governance, not just DevSecOps hygiene. When a publish token can be stolen from a workflow and converted into a runtime implant, the control question shifts to how much authority each automation identity actually needs and how quickly it can be revoked. That is the same logic applied in broader NHI governance, and it should now extend to package publish pipelines as well.

Publish-token blast radius: the distance between one compromised CI/CD token and the number of downstream systems that inherit trust from it. Teams should reduce that radius with tighter secret scoping, hardened release boundaries, and review of package import paths. Where the attack surface includes agentic tooling or AI-assisted development, the same identity logic should apply to tool credentials and build automation. See the OWASP NHI Top 10 and the MITRE ATT&CK Enterprise Matrix for adjacent threat mapping.

As this pattern spreads, practitioners should expect more incidents where the compromise starts in a workflow secret and ends in a package, container, or developer endpoint. That means detection needs to cover detached child processes, unexpected outbound transport, and identity abuse across build and publish chains. For programme owners, the priority is to connect CI/CD secret governance to broader identity lifecycle control, including rotation, offboarding, and least privilege.

For practitioners

• 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. Rotate them from a clean environment, scope them to the minimum repository and package set, and revoke any token exposed to workflow execution.
• 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. Imported packages matter more than installed packages because the payload fires on require().
• Rebuild trusted build environments Reimage compromised hosts, clear caches and mirrors, and re-establish provenance from known-good package versions before allowing them back into the build chain. Preserve volatile evidence first so you can verify whether shell commands or credentials were exposed.

Key takeaways

• This breach shows that a CI/CD workflow can become a secret-bearing non-human identity with enough power to publish malware.
• The scale matters because the compromised packages reached about 2.9 million weekly downloads, turning one token theft into broad supply chain exposure.
• Workflow segregation, publish-token rotation, and runtime hunting for detached Node activity are the controls most likely to prevent a repeat.

Key terms

• Pull_request_target workflow: A GitHub Actions trigger that runs in the context of the base repository, not the contributor’s fork. That means it can access repository secrets while processing untrusted pull request content, which creates a sharp trust boundary and a common route to secret theft if not carefully segmented.
• Publish token: A credential that authorises a package maintainer or automation process to publish or overwrite software artefacts. In identity terms, it is a high-value non-human credential with direct supply chain impact, so it needs rotation, scope limitation, and strict lifecycle ownership.
• Detached child process: A spawned process that continues running after the parent exits. Attackers use detached processes to preserve execution, hide activity from the original parent, and maintain background tasks such as downloaders, implants, or command runners without an obvious interactive session.
• Supply chain implant: Malicious code inserted into trusted software distribution so it executes in downstream environments. The risk is not only tampering with code integrity, but inheriting trust from the publisher, which turns one compromised release into many exposed systems.

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.

👉 Aikido's full post covers the attacker timeline, compromised package list, and host-level indicators of compromise.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance and secrets management for practitioners who need to secure automation identities and access paths. It helps security and identity teams translate governance into operational controls across modern enterprise programmes.