Nx supply chain attack shows how AI-assisted theft scaled

At a glance

What this is: This analysis shows how the Nx npm supply chain compromise used a compromised GitHub Actions workflow and malicious post-install code to steal developer secrets at scale.

Why it matters: It matters because build pipelines, developer tokens, and AI-assisted tooling are now part of the identity attack surface, so IAM, PAM, and NHI controls must cover software delivery paths as well as human access.

By the numbers:

• Researchers estimate that 2,349 distinct secrets were leaked, including GitHub tokens, cloud credentials, and AI service keys.
• At least 90% of the leaked GitHub tokens remained valid after the incident.
• Attackers published 8 malicious versions between 6:32 PM and 8:37 PM EDT before the packages were removed the same night.

👉 Read Apiiro's analysis of the Nx supply chain attack and secret theft

Context

The core problem is not only malicious code in a package registry, but the trust model behind modern software delivery. When publishing access, CI/CD workflows, and developer credentials are linked too loosely, a single compromise can turn the build system into a secret-harvesting channel that reaches far beyond the original repository.

For identity teams, the relevant question is how human developer access, machine credentials, and NHI governance intersect inside software pipelines. This kind of incident is typical of modern supply chain abuse: the initial foothold is technical, but the blast radius is controlled by identity and secrets hygiene.

AI-assisted developer tooling now adds another layer of risk because attackers can use legitimate CLI agents and automation patterns to accelerate reconnaissance and exfiltration. That makes pipeline trust, token lifecycle control, and workspace isolation part of the identity security conversation, not just AppSec or DevOps concerns.

Key questions

Q: What breaks when secrets are exposed in a software supply chain incident?

A: The immediate break is not just code integrity, but credential integrity. Exposed tokens and cloud keys can let an attacker reuse trusted identities, reach build systems, or access infrastructure that was never meant to be exposed through package updates. Once that happens, the incident stops being a single-package problem and becomes a governance failure across CI, secrets management, and downstream trust boundaries.

Q: Why do compromised build pipelines create identity risk beyond AppSec?

A: Because build pipelines often hold publishing rights, signing secrets, and automation tokens that function like privileged identities. When those credentials are reused across systems, the compromise extends into IAM and NHI governance, not just source code integrity. Security teams need to treat pipeline trust as an access-control problem with lifecycle and revocation requirements.

Q: How do security teams know whether a leaked secret still matters?

A: They verify liveness. A leaked secret matters most when it still authenticates, still has broad scope, or still maps to a privileged workload or service account. Teams should combine detection with ownership, scope review, and immediate rotation so that the remediation queue reflects real access risk rather than scan noise.

Q: Who is accountable when a release workflow publishes malicious code through trusted publishing?

A: Accountability spans repository owners, release engineers, and platform teams that control branch protections and workflow permissions. Trusted publishing shifts responsibility upward into the CI/CD identity layer, so organisations need clear ownership for who can trigger releases, approve workflow changes, and monitor execution behaviour.

Technical breakdown

Compromised GitHub Actions workflows as a publishing path

The initial entry point was a compromised GitHub Actions workflow, which gave the attackers access to package publishing operations. In supply chain attacks, the workflow itself becomes the trust bridge because it can inherit secrets, signing permissions, and release authority from automation that teams assume is safe. Once that bridge is abused, the attacker can distribute malicious artefacts through normal release channels, bypassing the need to compromise every downstream maintainer account individually.

Practical implication: treat release workflows as privileged identities and separate publishing permissions from routine CI execution.

Post-install malware and credential harvesting

The malicious npm packages used post-install scripts to run telemetry.js on Linux and macOS systems after installation. That matters because post-install execution turns a dependency into an active runtime participant with access to local files, shell context, and cached credentials. The malware searched for SSH keys, API tokens, npm credentials, GitHub tokens, and wallet data, which is a classic secret-exfiltration pattern amplified by the developer workstation's broad access footprint.

Practical implication: restrict package lifecycle scripts, inspect dependency behaviour at install time, and minimise secrets stored on developer endpoints.

AI CLI tools as an attacker accelerator

The incident also showed attackers using developer-facing AI CLI tools such as Claude Code, Gemini CLI, and Amazon Q with unsafe flags to support reconnaissance and exfiltration. The technical issue is not the model itself but the delegated execution context: once a tool can inspect files, run commands, or summarise sensitive content, it becomes a force multiplier for theft. This is an emerging overlap between software supply chain compromise and agentic AI misuse, where the tool is not the target but the operator of the theft workflow.

Practical implication: govern AI developer tools as privileged execution paths and monitor them for file access, command delegation, and data export.

Threat narrative

Attacker objective: The attacker objective was to steal reusable developer and cloud credentials at scale so they could extend access beyond the initial package compromise.

1. Entry occurred through a compromised GitHub Actions workflow that exposed publishing access to the Nx package ecosystem.
2. Credential access followed when malicious npm versions executed post-install scripts and harvested SSH keys, API tokens, GitHub tokens, npm credentials, and wallet data from developer systems.
3. Impact came from exfiltrating the stolen material into public GitHub repositories, preserving valid tokens for follow-on abuse and widening the attack surface beyond the original package compromise.

Breaches seen in the wild

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

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 developer trust is now a supply chain liability: the Nx incident shows that release automation, package publishing, and developer endpoints can all become identity-bearing attack surfaces. The compromise was not only about malicious code, but about who or what had authority to publish, execute, and exfiltrate. For practitioners, this is a governance failure in the lifecycle of developer trust, not just a malware event.

Secret exposure windows are now the real blast-radius metric: the practical problem is not whether secrets exist, but how long they remain usable after disclosure. In this case, the reported persistence of valid tokens means revocation latency mattered as much as detection. That is a direct argument for tighter token lifetime controls, faster offboarding, and stronger separation between human credentials and NHI-style automation secrets.

Developer-facing AI tools are becoming part of the identity perimeter: when a tool can read local files, inspect repositories, or interact with secrets, it deserves governance similar to privileged automation. The named concept here is AI-assisted exfiltration chain, meaning a sequence where legitimate AI tooling accelerates discovery, collection, and export of sensitive data. Practitioners should treat these tools as controlled execution environments, not convenience utilities.

Supply chain defence now requires identity-aware pipeline segmentation: teams can no longer rely on package trust or CI trust as separate concerns. Publishing rights, workflow permissions, and local credential scope need to be segmented so a single compromise cannot bridge code, secrets, and downstream distribution. That is where IAM, PAM, and NHI governance converge for software delivery.

The broader lesson is that autonomous abuse succeeds where lifecycle controls lag: attackers did not need persistent footholds if they could rapidly harvest and move secrets before revocation. That pushes identity security toward short-lived credentials, narrow publishing entitlements, and continuous monitoring of developer activity. The control model must assume that automation can be weaponised faster than conventional response cycles.

From our research:

• 2,349 distinct secrets were leaked in one AI credential abuse campaign, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• From our research: The average estimated time to remediate a leaked secret is 27 days, according to The State of Secrets in AppSec.
• For practitioners: Review 52 NHI Breaches Analysis for root-cause patterns that help separate short-lived exposure from recurring governance failure.

What this signals

AI-assisted exfiltration is now a governance problem, not just an attack technique: once developer tools can read files, run commands, and summarise sensitive output, they need explicit policy, auditability, and role separation. Teams that already map machine credentials, workflow permissions, and developer tokens into a lifecycle model will be better positioned to contain abuse before it becomes cross-environment access.

Secret sprawl remains the control gap that attackers exploit fastest: the point of failure is rarely a single leaked token in isolation, but the combination of broad access, weak revocation discipline, and multiple storage locations. That is why identity programmes need to align pipeline inventory with secret lifecycle controls and treat public-code exposure as a revocation trigger.

Attack chains like this strengthen the case for lifecycle-first identity design: once publishing rights, automation tokens, and AI tools all participate in the same delivery path, governance has to follow the flow of authority rather than the org chart. The relevant external control baseline is OWASP Non-Human Identity Top 10, especially the controls around secret sprawl, rotation, and over-privilege.

For practitioners

• Isolate package publishing from routine CI execution Move release permissions into a separate, tightly controlled workflow and require explicit approval for publishing steps that can access signing material or registry credentials.
• Reduce secrets on developer endpoints Keep SSH keys, API tokens, npm credentials, and cloud credentials out of long-lived local storage wherever possible, and bind access to short-lived, task-scoped tokens instead.
• Disable or constrain dependency lifecycle scripts Review install-time behaviour for npm packages and block or sandbox post-install execution where the package does not absolutely require it for legitimate operation.
• Treat AI CLI tools as privileged utilities Log and restrict use of developer-facing AI tools that can read files or run commands, especially when they operate with access to repositories, secrets, or build environments.
• Rotate and verify exposed tokens immediately Assume any credential touched by the affected pipeline may be usable by an attacker, then revoke, reissue, and validate tokens before restoring normal delivery operations.

Key takeaways

• The Nx compromise shows how a supply chain intrusion becomes an identity incident when publishing workflows can expose reusable secrets.
• Reported leakage of 2,349 secrets and lingering valid GitHub tokens demonstrate that exposure window, not just detection, determines blast radius.
• Teams should segment release authority, shorten credential lifetime, and govern AI developer tooling as a privileged execution path.

Key terms

• SaaS Supply Chain Attack: A SaaS supply chain attack is an intrusion path that uses trusted integrations, tokens, or third-party services to reach a target environment indirectly. The attacker relies on inherited trust between applications rather than breaking the main system first, which makes detection and containment harder.
• Post-install script abuse: Post-install script abuse happens when malicious code runs automatically during package installation and performs actions before a developer can inspect the package. It is dangerous because the install step itself becomes the execution path, letting attackers harvest data or alter the system immediately.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• AI-Assisted Exfiltration Chain: An AI-assisted exfiltration chain is an attack sequence where legitimate AI tooling helps an attacker find, collect, or export sensitive data faster. The risk comes from delegated access and execution context, not from the model alone, which makes governance and logging essential.

What's in the full analysis

Apiiro's full analysis covers the operational detail this post intentionally leaves for the source:

• Package-level indicators and affected Nx version checks for incident response teams
• Apiiro's Software Graph and SCA workflow for tracing where compromised dependencies entered the environment
• Malicious code detection and commit-blocking controls used to stop similar supply chain payloads
• The vendor's remediation workflow for rotating SSH keys, API tokens, and other exposed secrets

👉 Apiiro's full post covers compromise checks, remediation steps, and detection workflow details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and identity lifecycle control. It helps security practitioners build the vocabulary and control model needed to govern modern automation and credential risk.