Anatomy of the Nx Attack: 18 Minutes, 3,800 Repos

It took eighteen minutes. On 18 May 2026, a malicious version of the Nx Console extension for VS Code sat on the Visual Studio Marketplace for the span of a coffee break — live from roughly 12:30 to 12:48 UTC. Eighteen minutes was enough. By the time it was pulled, thousands of developers had installed it, and attackers had used it to siphon credentials and exfiltrate an estimated 3,800 internal GitHub repositories from affected organizations. The extension has over 2.2 million installs; the only thing that limited the damage was how fast it was caught. The threat group TeamPCP claimed responsibility.

This is a post-mortem of how a breach that fast did that much harm — a precise look at the attack chain, because every link in it is a lesson about the trust we extend to developer tools without thinking. (We've written before about the broader supply-chain threat; this is the anatomy of the single incident that defined it in 2026.)

The timeline

The mechanics, pieced together from The Hacker News, StepSecurity, and Nx's own postmortem:

Step	What happened
Initial access	A contributor's GitHub personal access token (PAT) was scraped in an earlier supply-chain incident
The foothold	That token had push access to the nrwl/nx repo and, directly or indirectly, the VS Code Marketplace publishing credential (VSCE_PAT)
The publish	A trojanized nrwl.angular-console v18.95.0 was pushed to the Marketplace at ~12:30 UTC, 18 May
The payload delivery	On opening any workspace, the extension fetched a 498 KB obfuscated payload from a dangling orphan commit hidden inside the official nrwl/nx GitHub repo
The theft	A multi-stage credential stealer harvested tokens from GitHub, npm, AWS, HashiCorp Vault, Kubernetes, and 1Password
Exfiltration	Stolen secrets were sent out over three independent channels: HTTPS, the GitHub API, and DNS tunneling
Detection & pull	The extension was removed after ~18 minutes — but the damage, ~3,800 repos, was done

Read that chain again and notice how each step exploited a trust assumption nobody usually questions. That's the real story.

Lesson 1: Your IDE extensions are unreviewed code with full access

The first uncomfortable truth: a VS Code extension runs with the same privileges as the developer who installed it. It can read your filesystem, your environment variables, your cloud credentials, your SSH keys. And almost nobody reviews an extension update — you click "install" (or it auto-updates) and trust the marketplace.

The Nx Console compromise weaponized exactly that trust. The moment a developer opened any workspace, the malicious extension executed. No exploit of a vulnerability, no user mistake beyond having a popular, legitimate tool installed — the extension simply did what extensions are allowed to do, but maliciously. The lesson isn't "don't use extensions"; it's that the editor is part of your attack surface and deserves the same scrutiny as any other dependency:

• Limit which extensions are allowed in your organization, and from whom.
• Review the permissions and behavior of extensions that touch sensitive workspaces.
• Run development with the least ambient credential access you can tolerate.

Lesson 2: A stolen token is a master key — scope and rotate accordingly

The breach didn't start with the malicious extension; it started with a scraped personal access token from a prior incident. That single credential had two fatal properties: broad push access to a hugely popular repository, and a path to the marketplace publishing credential.

This is the recurring theme of modern supply-chain attacks — one over-privileged, long-lived token becomes the skeleton key to everything downstream. The defenses are well known and still under-practiced:

• Scope tokens tightly. A token should grant the minimum it needs. A contributor's PAT should not be a path to marketplace publishing rights.
• Prefer short-lived credentials and OIDC over long-lived static tokens that stay valid until someone remembers to revoke them.
• Rotate aggressively, and assume breach. A token stolen months ago and never rotated is exactly how this chain began. Treat any prior incident as a reason to rotate everything reachable, not just what you can prove was touched.
• Separate publishing credentials. The credential that ships software to millions should be the most tightly guarded and isolated secret you own — never reachable from an ordinary contributor's access.

Lesson 3: Attackers hide in places you don't monitor

Two details of this attack are especially instructive about modern tradecraft.

First, the payload was fetched from a dangling orphan commit inside the official nrwl/nx repository. An orphan commit is a commit not attached to any branch — it exists in the repo's object store but isn't visible in the normal branch history. Hiding the payload there meant it was served from a trusted, legitimate domain (GitHub, the project's own repo), sailing past defenses that allow-list trusted sources. The malware didn't phone home to a sketchy server; it phoned home to GitHub.

Second, exfiltration used three independent channels, including DNS tunneling. DNS traffic is something almost every network allows out and few inspect closely — making it a favored covert channel for sneaking data past firewalls that would block obvious HTTP exfiltration. The lesson:

• Monitor for anomalous DNS activity, not just web traffic. DNS tunneling is a known exfiltration path that many organizations still don't watch.
• Don't blindly trust that "it came from GitHub" (or any reputable domain) means it's safe. Provenance of the content, not just the host, is what matters.

Lesson 4: Speed of detection is everything

The one genuinely reassuring part of this story is the response time. Eighteen minutes from publish to takedown is fast — and it's the reason the blast radius was 3,800 repos rather than something far worse. Had the malicious version sat for hours, the damage could have been catastrophic given the extension's 2.2 million-install base.

That flips a familiar lesson on its head. You cannot prevent every compromise — a determined attacker with a valid publishing credential will eventually get something out the door. What you can invest in is the speed of detection and response: monitoring that flags an anomalous publish, automated alerting, and the ability to pull a malicious artifact within minutes rather than days. In supply-chain security, mean-time-to-detect is not a vanity metric; it's the difference between an incident and a catastrophe.

A pattern, not a one-off

The most important context for the Nx Console attack is that it isn't an aberration — it's the clearest example yet of a category that defined software security in 2026: attacks on the developer trust surface. The same year saw compromises of CI plugins, container images, and package registries, often by the same threat actors and using the same playbook. The common thread is that attackers have realized developers and their tools are the soft, high-leverage path into otherwise hardened organizations.

The logic is ruthless and worth internalizing:

• Developers are privileged users. Their machines and pipelines hold the credentials to source code, cloud infrastructure, and production systems. Compromise a developer and you often compromise everything they can reach.
• The tooling is implicitly trusted. Package registries (npm, PyPI), extension marketplaces, base images, CI plugins — developers pull from all of them constantly, with far less scrutiny than they'd apply to, say, an email attachment. That trust is the vulnerability.
• One compromise scales. A poisoned popular package or extension executes across every organization that uses it. The Nx Console extension's 2.2 million installs is exactly the kind of leverage that makes this category so attractive to attackers.

This is why "supply-chain security" has moved from a niche concern to a board-level one. The perimeter that organizations spent decades hardening — firewalls, endpoint protection, network controls — doesn't help when the malicious code walks in through a trusted, auto-updating developer tool that the security team never thought to treat as untrusted input. The Nx attack is the headline case, but the trend is the story: the software supply chain, and specifically the developer's own toolbox, is now a primary battleground.

What to watch

• Provenance and signed builds going mainstream. The defense that would have blunted this — verifying that an artifact genuinely came from the trusted build pipeline, not a hijacked credential — is provenance attestation (SLSA and similar). Watch for marketplaces and registries to make signed provenance a requirement, not an option.
• Marketplace publishing security. Expect VS Code and other extension marketplaces to tighten publishing controls — mandatory MFA, scoped publishing tokens, anomaly detection on new versions. The Nx incident is a forcing function.
• Credential hygiene as the recurring root cause. The same pattern — a stolen, over-privileged, un-rotated token — keeps starting these breaches. Watch whether organizations finally move decisively to short-lived, tightly scoped credentials.
• DNS and covert-channel monitoring. The use of DNS tunneling is a reminder that exfiltration hides in allowed traffic. Watch for wider adoption of egress monitoring that covers more than HTTP.

The Nx Console attack is a near-perfect teaching case precisely because nothing about it was exotic. A stolen token, a trusted tool, a hidden payload, an open exfiltration channel — every step exploited an ordinary trust assumption that most teams never examine. The eighteen-minute window that limited the damage was luck backed by fast response, not architecture. The organizations that take the right lessons — scope and rotate credentials, treat IDE extensions as the attack surface they are, verify provenance, and invest in fast detection — are the ones that won't be the next 3,800 repos.