Nx supply chain compromise shows how NHI exposure scales fast

At a glance

What this is: A malicious nx supply chain compromise used postinstall code to harvest secrets, create attacker-controlled GitHub repositories, and reuse the stolen credentials in subsequent abuse.

Why it matters: It matters because developer tooling now sits inside the identity boundary, and compromised build/package workflows can expose NHI, human, and platform credentials before security teams notice.

By the numbers:

• 17 minutes
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 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.

👉 Read Semgrep's analysis of the nx supply chain compromise and secret theft

Context

Nx supply chain compromise is a developer tooling incident that became an identity security problem because the malicious post-install path harvested secrets, then reused them to extend access. The primary issue is not just malicious code in a package, but the way modern development environments give package installs, IDE extensions, and AI-assisted tooling the ability to touch credentials, repositories, and local shell profiles.

For IAM and NHI teams, this is a boundary failure between software supply chain risk and credential governance. Service tokens, API keys, and GitHub credentials were treated as durable assets even though the attack path turned them into short-lived exfiltration material; that is exactly the kind of exposure where NHI lifecycle controls, rotation discipline, and offboarding logic matter most.

The starting position is not atypical. Similar incidents have shown that compromise often begins with trusted developer tooling, then expands into repository access, package publishing, and persistent credential abuse.

Key questions

Q: What breaks when a supply chain compromise can read local developer secrets?

A: The trust model breaks because local secrets become attacker-controlled identity material before defenders can respond. If package installs, extensions, or assistant tooling can read tokens and environment variables, the compromise jumps from code execution to account abuse. Security teams need to assume that any readable secret on an affected workstation may already be reusable elsewhere.

Q: Why do exposed NHI and developer tokens create such a fast follow-on risk?

A: Because attackers can usually replay them long before normal review or ticket-based remediation happens. Once a token is harvested, the next step is often repository access, package publishing, or cloud abuse. This is why rotation, revocation, and scope reduction matter more than detection alone.

Q: What do security teams get wrong about secret rotation?

A: They often treat rotation as a substitute for removing the underlying credential model. Rotation lowers exposure time, but it still leaves a secret to steal, bootstrap, and govern. If a workload can avoid holding the secret at all, that is a stronger control than simply changing it more often.

Q: How should organisations govern IDE extensions in developer environments?

A: Use allowlists, central logging, and behavioural controls together. Extensions that request workspace, file system, or network access should be reviewed as access-bearing software, and any connection to unknown endpoints or unexpected process launches should trigger investigation before the extension reaches broader use.

Technical breakdown

Postinstall hooks as an execution boundary

Postinstall hooks run automatically after package installation, which makes them a powerful but risky execution point in npm ecosystems. In a compromised package, that hook can inspect local files, environment variables, and shell state before a developer notices anything unusual. Because the execution happens in a trusted workflow, traditional review controls often miss it unless package provenance, lockfile integrity, and dependency attestation are enforced. In this incident, the hook became the entry point for both credential harvesting and local persistence.

Practical implication: treat install-time code as privileged execution and restrict package provenance, especially for tools that run inside developer workstations and build pipelines.

Why harvested secrets become reusable identity material

Once the malware collected .npmrc contents, environment variables, and other keys, it converted them into identity material that could be replayed elsewhere. Secrets are not just sensitive data, they are authentication artifacts that grant access until they are revoked, rotated, or invalidated. When attackers can export those credentials into an attacker-controlled repository, the secret lifecycle breaks down completely. The result is not only exposure but also credential reuse against repositories, package registries, and cloud services that trust the same tokens.

Practical implication: map every secret to an owner, an expiry state, and a revocation path so exfiltrated credentials cannot remain valid after discovery.

IDE extensions and AI tools broaden the attack surface

The incident shows how IDE extensions, auto-update paths, and AI tooling can become indirect package execution channels. If an extension auto-installs or auto-updates a dependency, it can trigger the same postinstall behavior as a manual npm install without the user consciously initiating a package change. That matters because the attack surface now includes developer experience tooling, not just repositories and CI runners. As the number of agentic and assistant-driven development workflows grows, the identity boundary extends into every tool that can invoke code on behalf of a user.

Practical implication: inventory extensions and assistant tooling alongside dependencies, then restrict auto-update paths that can execute unreviewed code.

Threat narrative

Attacker objective: The attacker wanted durable credential access and downstream repository control, not just a one-time package compromise.

1. Entry via a compromised nx package or extension auto-update that executed malicious postinstall code on developer machines.
2. Credential access through local harvesting of .npmrc, environment variables, wallet files, and other secrets, then staging the output in an attacker-visible GitHub repository.
3. Impact through reuse of stolen GitHub tokens and other credentials to create public exposure, alter repository visibility, and expand access across accounts.

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

The real failure is secret reuse across developer tooling, not just package compromise. Once a postinstall hook can access local credentials, the attacker is no longer attacking code integrity alone. They are attacking the identity layer that links developer workstations, GitHub tokens, npm tokens, and cloud access into a single trust chain. The practitioner conclusion is simple: the secret lifecycle must be shorter than the compromise detection window.

Standing developer credentials remain the easiest bridge from supply chain compromise to account abuse. The article shows how harvested GitHub tokens were reused to manipulate repository visibility and amplify exposure. That is a classic case of standing privilege persistence, where a token survives long enough to be repurposed by the attacker. The governance lesson is that revocation and rotation are identity controls, not post-incident cleanup.

Developer experience tools now need the same governance scrutiny as CI/CD systems. Auto-update extension paths, assistant integrations, and package managers all execute code with user-level trust. That creates a governance blind spot if teams only monitor repositories and ignore local execution surfaces. The practitioner conclusion is to bring endpoint, IAM, and software supply chain ownership into the same control conversation.

Secret sprawl is now an operational identity problem, not a hygiene issue. The attack succeeds because secrets are scattered across local files, environment variables, registries, and collaboration tools. When those assets are not tied to owners, scopes, and revocation states, compromise turns into lateral access. The practitioner conclusion is to manage secrets as an identity estate with lifecycle controls, not as incidental configuration.

AI-assisted development expands the blast radius when trust boundaries are unclear. The incident references AI tools and local command execution paths, which shows how quickly one compromise can reach multiple toolchains. For identity governance, this sharpens the need to treat agentic and assistant-enabled workflows as part of the NHI surface whenever they can invoke tools or read secrets. The practitioner conclusion is to govern tool delegation the same way you govern privileged human access.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• Guide to the Secret Sprawl Challenge helps teams move from secret discovery to lifecycle control, rotation, and revocation.

What this signals

Secret exposure now needs to be measured in minutes, not days. If a compromise can harvest credentials from a workstation and reuse them almost immediately, then manual review cycles are structurally too slow. The practical response is to pair visibility with automatic revocation and to anchor that work in established identity controls such as NIST SP 800-53 Rev 5 Security and Privacy Controls and the MITRE ATT&CK Enterprise Matrix.

Developer tooling is now part of the identity perimeter. That means package managers, IDE extensions, and assistant plugins should be governed like execution surfaces, not productivity extras. Guide to the Secret Sprawl Challenge is the right internal lens when teams need to connect secret discovery to ownership and revocation.

Credential sprawl is the named failure mode here. The attack only becomes durable when one exposed secret can unlock several systems at once. For programmes that manage NHI and human access together, the operational signal is clear: reduce shared tokens, shorten lifetimes, and make revocation the default path when compromise is suspected.

For practitioners

• Rotate exposed credentials immediately Revoke GitHub tokens, npm tokens, API keys, and any cloud secrets that may have been present on affected workstations or in the compromised repositories. Prioritise credentials with repository write access and package publishing rights because those are the fastest paths to further abuse.
• Search for install-time compromise indicators Review npm logs, lockfiles, editor extension histories, and shell profiles for evidence of the malicious postinstall path, including telemetry.js execution and unexpected entries in .zshrc or .bashrc. Include repository and security-log review because deleted attacker repositories may still indicate compromise.
• Inventory developer tooling with execution reach Catalogue IDE extensions, package managers, AI assistants, and auto-update mechanisms that can execute code or pull dependencies without explicit approval. Remove or restrict anything that can invoke package installs or postinstall hooks from user workstations and build environments.
• Reduce secret persistence windows Move high-risk credentials toward short-lived tokens, automated rotation, and immediate invalidation workflows so stolen values expire quickly. Align owners, scopes, and revocation procedures so that exposed secrets do not remain usable after a compromise is detected.
• Tie developer access to least-privilege controls Separate repository administration, package publishing, and cloud access so one compromised token cannot cascade across systems. Use role scoping and periodic access review to limit the impact of any local credential theft.

Key takeaways

• This incident shows that supply chain compromise becomes an identity problem the moment local secrets can be harvested and reused.
• The scale is defined by speed and reuse, not only by the initial package compromise, because stolen credentials can be operational within minutes.
• Organisations should treat developer secrets as a managed identity estate, with rotation, invalidation, and tool governance as primary controls.

Key terms

• Postinstall Hook: A postinstall hook is code that runs automatically after a package is installed. In a supply chain compromise, it becomes a trusted execution point that can read local files, environment variables, and credentials before the user understands what happened.
• 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.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Supply Chain Credential Abuse: Supply chain credential abuse occurs when attackers compromise trusted software, dependency, or tooling paths to steal or reuse credentials. The attacker is not only targeting the software artifact but the identity material that the software can reach during normal execution.

What's in the full analysis

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

• Step-by-step compromise indicators for the affected nx package versions and extension paths
• Specific command lines and local file checks for validating exposure across developer workstations
• Semgrep rule content for detecting vulnerable nx usage in repositories and scans
• Updated remediation workflow for token rotation and environment review after compromise

👉 Semgrep's full post covers the affected versions, compromise checks, and remediation steps

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect identity controls to the operational realities of developer tooling, automation, and credential lifecycle risk.