Nx supply chain attack shows how AI-assisted theft scaled

At a glance

What this is: A supply chain compromise of the Nx ecosystem turned trusted package publishing and post-install execution into a path for secret theft, with attackers also using AI CLI tools to widen the attacker's reach.

Why it matters: IAM, PAM, and NHI teams should treat developer tooling, publishing workflows, and AI-assisted automation as part of the identity attack surface, because compromised trust paths can expose valid secrets at scale.

By the numbers:

• Researchers estimate that 2,349 distinct secrets were leaked in the Nx attack.
• At least 90% of the leaked GitHub tokens remained valid after the incident.

Context

The core security gap in this incident is trust placed in the software supply chain and in the developer environment that supports it. When package publishing, CI/CD workflows, and local developer tooling are tightly coupled, a compromise in one place can quickly become credential exposure elsewhere.

This was not just package tampering. The attack crossed into identity and access governance because it harvested SSH keys, API tokens, GitHub tokens, npm credentials, cloud credentials, and AI service keys. That makes the incident relevant to NHI governance, developer identity controls, and secrets lifecycle management, not only dependency hygiene.

The attack pattern is increasingly common in modern delivery pipelines: trusted automation becomes the delivery path, and secrets become the payload. That is now a realistic baseline risk for organisations with developer-heavy software estates.

Key questions

Q: What are the signs that a package publishing workflow has been compromised?

A: Common warning signs include unexpected package version bumps, releases from inactive or former employee accounts, changes to dependency behavior without a planned release, and traffic or transaction patterns that do not match normal application use. Security teams should also watch for unsigned or unreviewed updates, sudden publishing outside normal change windows, and user reports that align with a recent package release.

Q: Why do developer secrets make supply chain incidents much harder to contain?

A: Because developer secrets often act like non-human identities with broad runtime reach. If the same token can publish code, access cloud services, or trigger automation, one compromise can spread across multiple systems without needing a new exploit. Containment becomes difficult when credential scope is wider than the code path that exposed it.

Q: What are the signs that a malicious package attack is affecting developers?

A: Common signs include unexpected public repositories created during the incident window, unusual package install behaviour, unexplained credential use, and evidence that developer machines or CI agents accessed sensitive files. In this case, package-lock changes, anomalous GitHub activity, and sudden token reuse would all be high-value indicators.

Q: Should teams treat AI developer tools as part of privileged access governance?

A: Yes. If an AI CLI can read local files, invoke shell commands, or access repositories, it should be governed like privileged automation rather than a harmless productivity tool. Teams should define ownership, scope, logging, and approval boundaries for those tools before they become part of the attack surface.

Technical breakdown

Compromised publishing workflow as the entry point

The entry condition was not a vulnerability in the Nx packages themselves, but compromised access to the GitHub Actions workflow used to publish them. Once attackers gained publishing access, they could release malicious versions that looked operationally legitimate to downstream consumers. This is a classic supply chain pattern: the attacker abuses the trusted build and release path rather than breaking the codebase directly. In identity terms, the publishing workflow acted like a high-value machine identity with far more reach than a normal developer account would need.

Practical implication: treat release workflows as privileged identities and remove any excess standing access from package publishing paths.

Post-install malware and credential harvesting

The malicious packages used post-install scripts to execute telemetry.js on Linux and macOS systems, scanning for sensitive files and credentials. That matters because install-time execution shifts the threat from static package inspection to runtime behaviour on developer endpoints and build environments. The malware targeted SSH keys, API tokens, npm credentials, GitHub tokens, wallet data, and cloud credentials, which shows how one package compromise can become a multi-credential harvest operation. This is especially dangerous when secrets are stored in predictable locations or reused across tools.

Practical implication: limit install-time script execution and reduce the number of reusable credentials exposed on developer systems.

AI CLI abuse inside the attack chain

A notable twist was the use of developer-facing AI CLI tools such as Claude Code, Gemini CLI, and Amazon’s q to support reconnaissance and exfiltration. These tools were not the initial vulnerability, but they amplified attacker workflow and made the operation more scalable. That turns AI assistants into operational infrastructure when they are allowed broad file, shell, or tool access. For identity governance, this is an early sign that AI tooling can behave like an NHI with delegated reach if access and execution boundaries are weak.

Practical implication: govern AI developer tools as privileged execution paths, not as harmless productivity add-ons.

Threat narrative

Attacker objective: The attackers aimed to steal valid developer and cloud credentials at scale, then use those secrets for broader compromise and persistence.

1. Attackers obtained publishing access through a compromised GitHub Actions workflow and used it to publish malicious Nx package versions.
2. Once installed, the packages executed post-install malware that scanned developer endpoints for SSH keys, API tokens, npm credentials, GitHub tokens, and wallet information.
3. Stolen data was encoded and uploaded to public GitHub repositories, while AI CLI tools were used to support reconnaissance and exfiltration.
4. The objective was to harvest reusable secrets at scale and preserve access paths after the malicious packages were removed.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Developer publishing workflows are now privileged identity systems. The attack did not need to compromise source code quality first because the release path itself was the control plane. That means CI/CD publish jobs, workflow tokens, and release approvals need to be governed as machine identities with explicit scoping and offboarding. Practitioners should stop treating publishing automation as a low-risk back office function.

Secret exposure windows are the real attack surface in supply chain compromise. The article shows that 2,349 secrets were leaked and that many stolen GitHub tokens remained valid after disclosure. That is a governance failure, not just an incident outcome, because long-lived and reusable credentials survive the event that exposed them. The practical lesson is that secret lifecycle control matters more than relying on downstream detection alone.

AI-assisted intrusion is becoming a force multiplier for credential theft. The use of developer-facing AI CLI tools inside the attack chain shows how agent-like tooling can extend attacker reach when it inherits shell and file access. This is not yet a separate category of breach, but it is a clear sign that AI tooling can become part of the trusted execution surface. Security teams should classify these tools by privilege, not by convenience.

Supply chain governance now intersects directly with NHI governance. Packages, workflow tokens, cloud keys, and AI service credentials all behaved like non-human identities in this incident because they were machine-used, machine-validated, and machine-abused. That makes OWASP NHI concerns such as secret leakage, long-lived secrets, and overprivileged NHI directly relevant to software delivery. The field needs to treat identity sprawl in developer ecosystems as a primary risk, not a side effect.

Strengthening package integrity is necessary but insufficient without runtime credential containment. Even if malicious packages are detected quickly, exposed secrets can remain useful long after the package is removed. That pushes governance toward shorter-lived credentials, tighter pipeline trust, and better containment around developer environments. Practitioners should design for exposure resilience, not just faster package takedown.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Supply chain identity sprawl: package publishing, workflow tokens, developer credentials, and AI service keys now behave like one connected trust fabric. Once that fabric is stretched across endpoints and build systems, a single compromise can expose many valid credentials before defenders even see the malicious package.

The practical programme response is to shrink the number of credentials that can be reused across developer tooling, package publishing, and AI-assisted workflows. That means stronger lifecycle control for secrets, tighter publishing trust, and clearer ownership for tools that can execute commands or reach repositories.

The relevant benchmark is no longer whether a package is scanned quickly enough. The real question is whether stolen credentials remain useful long enough for an attacker to turn package compromise into account takeover or follow-on access.

For practitioners

• Tighten publishing workflow privileges Review package publishing workflows, GitHub Actions permissions, and release tokens so only narrowly scoped identities can publish to production package namespaces.
• Reduce secret persistence on developer systems Move SSH keys, API tokens, npm credentials, cloud credentials, and AI service keys out of predictable filesystem locations and shorten their usable lifetime wherever possible.
• Block or restrict install-time scripts Treat post-install execution as a high-risk behaviour for third-party packages and require explicit approval or sandboxing for packages that run code during install.
• Inventory AI developer tools as privileged access paths List AI CLI tools that can read files, execute commands, or reach repositories, then assign them ownership and review the permissions they inherit from developers.
• Hunt for public exfiltration artifacts Search for repositories named s1ngularity-repository or variants, review package-lock files for affected Nx versions, and inspect CI/CD logs and developer machines for anomalies.

Key takeaways

• The Nx incident showed that supply chain compromise can become an identity event when publishing access, developer credentials, and AI tooling are all part of the same trust path.
• The scale of the exposure matters because 2,349 distinct secrets were leaked and many stolen tokens were still valid after the attack.
• The control gap is not just package inspection but the combination of workflow privilege reduction, secret lifecycle control, and restricted install-time execution.

Key terms

• Supply chain attack path: A supply chain attack path is any route by which a trusted external tool, dependency or partner becomes the mechanism for compromise. It matters because attackers often abuse legitimate integrations instead of exploiting the core system directly, which makes detection and containment harder.
• Postinstall Script: A package lifecycle hook that runs automatically after installation. It is useful for legitimate setup tasks, but it also creates an execution path that can be abused to run malicious code as soon as a dependency is installed.
• Developer Identity Context: The set of permissions, tokens, and authenticated sessions available on a developer workstation or in a build environment. When that context is too broad, malicious code can move from local execution into source repositories, registries, or cloud services.
• AI CLI Tool: An AI CLI tool is a command-line interface that lets a developer agent or assistant interact with local files, code, or external services. When granted shell or filesystem access, it can become part of the privileged execution surface and therefore requires explicit governance.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical terms. It helps practitioners connect identity controls to the broader security programme they run every day.