Nx supply chain compromise shows how NHI exposure scales fast

At a glance

What this is: A compromised nx package chain used post-install malware to collect developer credentials, place them in attacker-controlled GitHub repositories, and reuse them in follow-on account abuse.

Why it matters: This matters because NHI exposure is often discovered only after credentials have already been harvested and used, so IAM teams need faster revocation, tighter secret hygiene, and better repo-level monitoring.

Context

Nx is a build and workspace tool, but in this incident it became a delivery path for credential theft because a malicious post-install step ran on developer machines and within IDE-driven workflows. The core governance failure is not only package compromise, but the assumption that developer tooling is outside the scope of identity and secret controls.

For IAM and NHI practitioners, the important lesson is that developer tokens, npm credentials, GitHub access, and local environment secrets form one exposed trust chain. When a package install can read, package, and exfiltrate credentials before security teams see the event, lifecycle controls must extend to the developer workstation and build environment.

Key questions

Q: What breaks when a compromised package can read secrets during installation?

A: The main failure is that package installation becomes an identity event. If the environment exposes tokens, keys, or certificates while a dependency executes, the attacker does not need application-level access first. They can steal reusable credentials and move into cloud, CI/CD, or internal systems that trust those secrets.

Q: Why does secret theft create a wider impact than the initial compromise?

A: Because a stolen token is a live identity, not just data. Once the attacker can authenticate, they can create repositories, expose private projects, or trigger automated abuse without further malware on the original device. That is why revocation and rotation need to follow compromise indicators immediately.

Q: What signs show that developer identity recovery is too easy to abuse?

A: If support teams can reset privileged accounts manually, or if email and SMS recovery are still permitted for code-bearing identities, the recovery path is probably weaker than the login path. That creates a social-engineering target even when the primary authenticator is strong.

Q: Should organisations treat IDE extensions and package managers as identity risk points?

A: Yes, because both can trigger code execution that reaches developer credentials before security controls intervene. The governance question is not whether the tool is convenient, but whether it can invoke installs, read secrets, or authenticate with platform tokens in ways that bypass ordinary review.

Technical breakdown

How the post-install hook became the entry point

A post-install hook executes automatically after package installation, which means the attacker does not need to wait for a separate runtime exploit. In this case, the malicious nx package used that trusted installation path to run code on developer systems and in extension-driven workflows. That is a supply chain problem, but it becomes an identity problem when the code can immediately access developer secrets, GitHub tokens, and environment variables. The critical mechanism is trust inheritance: package managers and IDE helpers often execute with more access than teams realise.

Practical implication: treat package-install execution as a credential-bearing event and restrict what install-time scripts can read.

How stolen secrets were packaged for attacker reuse

The malware did not merely copy files. It scanned for wallet and key material, encoded what it found into results.b64, and placed the output in a new GitHub repository under the victim account. That pattern matters because it converts local secret discovery into a durable attacker-controlled collection point. Once tokens and API keys are staged in a repository the attacker can enumerate, the exposure window is no longer tied to the infected machine. It becomes a remote access and persistence problem, especially where private repositories or account tokens are involved.

Practical implication: monitor for unexpected repository creation and treat new attacker-owned repos as evidence of credential compromise.

Why follow-on abuse turns credential theft into account takeover

The article shows that the harvested GitHub tokens were then used in a further automated attack, including making private repositories public. That is the escalation path teams often miss: secret theft is not the endpoint, it is the enabler for broader account and data exposure. In NHI terms, this is standing credential abuse with immediate blast-radius expansion. Once the attacker can act with a valid token, conventional detection that only looks for malware on the endpoint arrives too late to prevent misuse.

Practical implication: couple secret detection with immediate revocation and repo-audit checks, not just endpoint triage.

Threat narrative

Attacker objective: The attacker aimed to harvest usable developer credentials and turn them into broader GitHub account and repository compromise.

1. Entry occurred through a malicious post-install command in the nx build kit and related extension-driven installs, which executed trusted code on developer machines.
2. Credential harvesting followed as the malware scanned local files, environment variables, and configuration paths for API keys, tokens, and wallet material.
3. Escalation happened when the harvested credentials were staged in attacker-controlled GitHub repositories and then reused in automated follow-on abuse.
4. Impact included private repositories being exposed publicly and a broader credential compromise across developer and organisation accounts.

Breaches seen in the wild

• 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.
• OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.

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 tooling now belongs inside identity governance. The boundary between software supply chain risk and NHI governance has collapsed because package installs can exfiltrate credentials before any human sees a prompt. That means GitHub tokens, npm tokens, and local environment secrets should be governed as operational identities, not just convenience artifacts. Practitioners should assume that any install path capable of executing code is also capable of abusing identity material.

The exposed secret is rarely the final loss. The more important failure mode is the time between credential theft and revocation, because that interval determines whether the attacker can reuse the token for repo exposure, data access, or lateral movement. This incident shows why detection-heavy programmes underperform when offboarding and revocation are slow. Security teams should design for immediate invalidation, not post-event review.

GitHub repository creation can be a compromise signal. In this pattern, a sudden repository with an unusual prefix is not an administrative artifact, it is evidence of secret exfiltration and account abuse. That makes repository monitoring part of identity telemetry, not just engineering hygiene. A named concept for this failure mode is credential staging repositories: attacker-created repos used to store harvested secrets long enough for remote retrieval. Practitioners should build alerting around that behaviour.

IDE auto-update and extension trust create hidden identity pathways. The article shows that compromised developer extensions can trigger package execution even when engineers do not explicitly touch the package themselves. That expands the attack surface from source control to editor ecosystem governance, especially where AI assistants and automation tools can invoke package managers on behalf of the user. Security teams should treat editor-managed installs as governed execution environments.

From our research library:

• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Read next: API Key Management Guide

What this signals

Credential staging repositories: attacker-created repos used to store harvested secrets are becoming a practical detection target, not an edge case. When your environment allows code execution during install or extension update, repository monitoring should be treated as part of identity telemetry rather than an engineering-only signal.

The broader programme lesson is that NHI governance has to move closer to developer workflow control. Secret exposure, token reuse, and account abuse now arrive through build tools, IDE helpers, and automation hooks, so revocation speed and install-time containment matter more than after-the-fact forensics.

Teams should assume that exposed developer credentials will be reused quickly unless rotation is automated and scoped identities are tightly limited. That is the gap this incident exposes: security teams often detect the compromise before they disable the identity, which leaves enough time for attacker-driven repository tampering and public exposure.

For practitioners

• Audit developer token lifecycles Inventory GitHub, npm, cloud, and automation tokens used by engineering teams, then revoke anything that is stale, shared, or scoped wider than required.
• Monitor for attacker-controlled repositories Alert on unusual repository creation patterns, especially short-lived or prefixed repositories tied to code execution events or account anomalies.
• Restrict install-time script execution Block or tightly control package post-install execution in build and workstation environments where secrets are reachable during install.
• Check editor and extension auto-update paths Review IDE extensions, preinstall recommendations, and automatic update behaviour that can trigger hidden package installs on developer machines.
• Rotate credentials after exposure indicators When a compromise indicator appears, rotate tokens, passwords, and API keys immediately and verify that the old values are no longer accepted.

Key takeaways

• The compromise shows that package install paths can become credential-exfiltration channels when post-install code can reach developer secrets.
• The scale matters because stolen tokens were reused for follow-on repository abuse, not just collected as inert data.
• Fast revocation, strict install-time controls, and repository monitoring are the controls most likely to shrink the blast radius.

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.
• Credential Staging Repository: A credential staging repository is an attacker-controlled repository used to store harvested secrets so they can be retrieved remotely later. The pattern turns local theft into durable exfiltration and is especially dangerous when created inside a victim account or organisation boundary.
• 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.
• Install-Time Exfiltration: The removal of data from a system during dependency installation rather than during normal application runtime. It is dangerous because it happens early, is often trusted by default, and can bypass controls that focus only on executed application features.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the developer and automation workflows where compromise now starts.