Nx supply chain compromise exposed AI tool abuse and secret theft

At a glance

What this is: This is an analysis of the Nx supply chain compromise, where malicious npm package versions were used to steal developer secrets and abuse AI CLI tools.

Why it matters: It matters to IAM practitioners because developer tokens, SSH keys, and build-time secrets are now part of the same NHI governance problem as runtime access and offboarding.

By the numbers:

• The attack window lasted approximately 5 hours and 20 minutes, during which 8 malicious versions were published across two major version branches.

👉 Read StepSecurity's analysis of the Nx supply chain compromise and AI tool abuse

Context

The security problem here is not just package tampering. It is the combination of trusted dependency distribution, developer workstation exposure, and credential sprawl across GitHub, npm, SSH, and environment files. In practice, a single malicious post-install hook can bridge software supply chain compromise and NHI theft in minutes, especially when build and developer tooling inherit broad trust.

AI CLI tooling adds a new trust boundary that most software supply chain controls do not yet model well. When local assistants can be coerced into scanning the filesystem or assisting with exfiltration, the issue is no longer only code integrity. It becomes a governance problem for machine-accessible credentials, developer identity, and the runtime permissions granted to interactive AI tools.

Key questions

Q: What breaks when developer tokens are stolen through a supply chain attack?

A: The main failure is that stolen tokens let attackers act as trusted automation rather than as obvious intruders. They can publish packages, alter repositories, or access APIs using legitimate identities, which defeats simple perimeter controls. The response must focus on revocation, scope reduction, and ownership, not only malware removal.

Q: Why do non-human credentials amplify supply chain risk in developer pipelines?

A: Because they are reusable across systems, often over-scoped, and frequently minted in automation contexts that are assumed safe. When a runner, token, or service account is compromised, the attacker can move from one system to many without additional user interaction. The risk rises sharply when rotation, revocation, and workload identity ownership are fragmented.

Q: How do security teams know whether device revocation is actually working?

A: They should test the full authorisation path, not just the revoke request. A working control must remove effective access from the next access check, including legacy records and fallback branches. If a token can be revoked but the device still returns roles, revocation is only partial and the lifecycle model is broken.

Q: Who is accountable when a package repository compromise exposes enterprise credentials?

A: Accountability sits with the teams that own publishing access, dependency governance, secrets management, and endpoint containment. Frameworks such as OWASP NHI and NIST CSF matter because the failure is not only malware execution, but the absence of lifecycle control over the identities and secrets that the pipeline depended on.

Technical breakdown

How malicious post-install hooks turn packages into execution points

A post-install hook runs automatically after a package is installed, which means attackers do not need the victim to execute a separate payload. In this incident, the malicious telemetry.js file executed immediately after installation and could inspect the developer environment at scale. That pattern is especially dangerous in ecosystems where package managers run with broad filesystem visibility and where build systems routinely trust dependencies to behave as declared. The technical failure is not simply malicious code, but the assumption that installation-time scripts are safe by default.

Practical implication: restrict or monitor install-time script execution for high-risk packages and treat post-install behaviour as an execution event, not a routine dependency step.

Why compromised developer tokens are high-value NHI assets

The malware harvested npm tokens, GitHub CLI tokens, SSH private keys, and environment files because each of those artefacts functions as a non-human identity credential. Unlike a password prompt, these tokens often provide direct API access, long-lived trust, and reusable privilege across repositories and pipelines. That makes them ideal for repository exposure, malicious publishing, and lateral access through organisation-linked tooling. Once stolen, the attacker can operate as a legitimate automation principal unless lifecycle controls, revocation, and scope limits are enforced.

Practical implication: inventory developer-issued tokens and SSH keys as NHI credentials and apply the same lifecycle, rotation, and revocation discipline used for service accounts.

How AI CLI tools become reconnaissance channels

The novel part of this incident is the coercion of local AI assistant CLIs such as Claude, Gemini, and q. The malware passed dangerous flags that disabled safety controls and then used the tools to recursively search the filesystem for wallet files, credentials, and secrets. In effect, the attacker turned legitimate AI tooling into an assistant for discovery and exfiltration. That is a supply chain issue, but it is also an identity issue because the tool itself becomes a privileged runtime actor with access to developer context.

Practical implication: govern AI CLI tools as interactive privileged software, with explicit policy on permissions, filesystem scope, and the credentials they can observe.

Threat narrative

Attacker objective: The attacker’s objective was to harvest developer and organisation credentials, expand access through trusted repositories, and exfiltrate valuable secrets at scale.

1. Entry occurred through a compromised npm package published with a malicious post-install script that executed automatically on installation.
2. Credential harvesting followed as the malware collected GitHub tokens, npm tokens, SSH keys, environment secrets, and wallet data from developer machines.
3. Escalation and exfiltration used stolen credentials to publish malicious packages and to expose or fork private repositories containing sensitive organisational data.

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

This incident confirms that developer secrets are now operational NHI assets, not incidental tooling artefacts. GitHub tokens, npm credentials, and SSH keys all function as machine identities when they authorise API access and repository actions. Once they are treated as interchangeable convenience artefacts, organisations lose control over where privilege begins and ends. The practitioner takeaway is to govern developer credentials as part of the NHI estate, not as a separate dev productivity concern.

Supply chain compromise and NHI compromise are converging into one attack surface. The Nx case shows that a package install can become both an execution event and an identity theft event, which breaks the old assumption that software integrity and credential governance can be managed separately. The named concept here is installation-time identity exposure: the moment a trusted dependency, build step, or installer can observe and reuse secrets. Security teams should treat package installation as a controlled privilege boundary.

AI CLI trust sprawl is becoming a governance gap of its own. If a local assistant can read files, enumerate secrets, and assist with reconnaissance, then the tool has become part of the organisation’s identity and access surface. That creates a new category of shadow AI risk where legitimate developer tools operate with more context than security teams have modelled. Practitioners need to decide which AI tools may observe credentials, where their outputs are stored, and how their permissions are constrained.

Rapid secret revocation matters more than secret discovery alone. The article shows how quickly stolen credentials can be reused to create public repository exposure and preserve data in forks. That is a lifecycle failure, not just an alerting failure. Organisations that can detect leaked secrets but cannot revoke them fast enough will still lose control of downstream access and exfiltration paths.

Repository visibility controls are now part of identity containment. Making exposed repositories private again is not merely a content-management action. It is a compensating control for credential misuse, because attackers often use leaked credentials to alter repository state before defenders complete investigation. The practitioner conclusion is that identity governance for code platforms must include ownership, token scope, and emergency containment playbooks.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• Guide to the Secret Sprawl Challenge explains why discovery without lifecycle control still leaves organisations exposed.

What this signals

Installation-time identity exposure is the right mental model for this class of attack. If your build and developer tooling can observe secrets during dependency installation, then secret governance belongs in the software delivery pipeline, not only in the vault. That is why runtime controls, token scope reduction, and install-script policy need to be reviewed together.

The practical signal for IAM and security teams is that developer endpoints now sit inside the credential lifecycle. Repository access, package publishing, and AI assistant permissions should all be mapped against the same ownership and revocation model used for NHI governance. Where appropriate, align that model with the OWASP Non-Human Identity Top 10 and the MITRE ATT&CK Enterprise Matrix.

Security programmes should also prepare for secret exposure that happens outside code, including AI-assisted tooling and local automation. The control question is no longer whether a secret exists somewhere in a repo, but whether the organisation can detect, classify, and revoke it before a compromised identity uses it. That is a governance maturity issue as much as a detection issue.

For practitioners

• Treat developer tokens as governed NHI credentials Inventory GitHub, npm, SSH, and similar credentials as non-human identities, assign ownership, and enforce expiry, revocation, and scope review on the same schedule as other machine credentials.
• Disable or restrict install-time scripts where feasible Block automatic execution of post-install hooks for packages that do not need them, and alert on dependency installs that invoke filesystem-wide collection or network activity.
• Constrain AI CLI permissions on developer endpoints Limit which local AI assistants can access files, shell commands, and secrets, and require explicit policy for dangerous flags such as trust-all-tools or permission-skipping modes.
• Build a rapid token revocation runbook for code platforms Pre-stage steps to revoke OAuth tokens, installed apps, SSH keys, GPG keys, and publishing credentials when repository compromise is suspected, and test the sequence before an incident occurs.
• Search for exposed repository forks and renamed clones Monitor for repository renaming patterns, unexpected forks in user accounts, and public copies of private code so that exfiltration through repository exposure is contained quickly.

Key takeaways

• The breach shows that package installs, developer tokens, and AI tools can combine into a single credential theft path.
• The evidence points to a fast-moving compromise with thousands of potentially exposed developers and a short but highly productive attack window.
• The control that changes the outcome is not just detection, but fast lifecycle revocation for every affected non-human credential.

Key terms

• Preinstall Hook: A preinstall hook is package code that runs before an application installs or starts. In supply-chain attacks, it becomes a hidden execution point that can steal secrets, alter environments, or drop further payloads before normal controls see the package's behaviour.
• Developer NHI: A developer NHI is a non-human identity used in software engineering workflows, such as API tokens, npm credentials, GitHub tokens, SSH keys, and automation secrets. These identities often have broad access and long lifetimes, which makes them high-value targets when build tools or developer machines are compromised.
• Install-time identity exposure: The moment a package or dependency can execute code and reach credentials during installation or import. In practice, it means software delivery steps can become identity compromise points if tokens, secrets, or automation keys are accessible before the package is trusted.
• AI CLI Trust Boundary: An AI CLI trust boundary is the control line around local model assistants that can access files, shell commands, and context on a developer machine. If that boundary is weak, the assistant can become an unwitting discovery and exfiltration aid for attackers.

What's in the full analysis

StepSecurity's full blog post covers the operational detail this post intentionally leaves for the source:

• The complete compromise timeline across the initial npm takeover and the second-wave repository exposure activity.
• Detailed indicators of compromise, including filesystem artefacts, token artefacts, and repository naming patterns.
• The full malicious telemetry.js behaviour and the command-line flags used to coerce local AI assistants.
• Step-by-step remediation instructions for affected organisations and package versions.

👉 StepSecurity's full post covers the compromise timeline, malware behaviour, and remediation steps.

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. It helps identity and security practitioners connect token lifecycle control to broader access governance.