Why the GitHub Breach is a ZSP Wake-Up Call

A GitHub breach occurred on May 18, 2026 when a threat actor called TeamPCP pushed a malicious version of Nx Console (a widely used VS Code extension with 2.2 million installs) to Microsoft’s official Visual Studio Marketplace. The compromised version was live for eighteen minutes before being pulled, but in that window, it ran a credential stealer on every machine that auto-updated, harvesting GitHub tokens, AWS keys, SSH keys, and password manager material from developers’ local environments.

One of those developers worked at GitHub. Within hours, TeamPCP had used their credentials to clone approximately 3,800 of GitHub’s internal private repositories – source code, deployment scripts, infrastructure configurations, and Copilot internals – and listed the stolen data for sale on a cybercrime forum for $50,000.

No exploited vulnerability or brute force, just a stolen token with no guardrails to limit how far it could reach.

How it happened

The attack follows a pattern that TeamPCP has refined across more than 500 open source tools in 2026 alone. The group identifies widely used developer tooling, compromises a publisher account or contributor token, and pushes a malicious version through the official distribution channel. The poisoned package runs a credential stealer the moment it executes, exfiltrating secrets from the developer’s local environment. Those credentials are then used to compromise additional tools, whose users become the next wave of victims.

In this case, the entry point was the Nx Console extension. The payload harvested credentials silently and automatically, reaching every developer with auto-updates enabled. GitHub detected the intrusion, isolated the affected endpoint, and began rotating credentials. But by then, the repositories had already been cloned.

Standing privileges were the real vulnerability

The supply chain angle is real, and the Nx Console compromise deserves scrutiny. But focusing on the delivery mechanism obscures the more consequential failure: the stolen credentials had access to 3,800 repositories because that’s what the developer had been persistently provisioned to access.

This is how GitHub access works at most organizations, and GitHub itself was no exception. Repository permissions, org membership, and clone access accumulate over time and rarely get revisited. There is no active work session to expire, no task scope to enforce. Access persists indefinitely, which means a stolen credential carries the full weight of everything that employee has ever been granted.

The attacker didn’t need sophistication. They needed one valid credential attached to enough standing access to make the theft worthwhile. In this case, that threshold was cleared by a wide margin.

What Zero Standing Privilege changes

Under a Zero Standing Privilege (ZSP) model, no user – human or machine – holds persistent access to systems or resources by default. Access is granted just-in-time, scoped to a specific task, and expires when the work is done. The principle is already standard practice for cloud infrastructure and production database access at security-mature organizations, but is considerably less common in developer environments.

Applied to the GitHub breach, the impact is direct: a stolen token from a developer’s machine reflects only what they were actively authorized to do at that moment rather than the accumulated permissions of their entire tenure. If that developer had been granted JIT access to a specific set of repositories for an active project, the credential theft still happens, but the cloned repository count does not reach 3,800.

That’s the difference between a contained incident and a breach of this scale.

GitHub is just the latest example

For teams that have already applied rigorous access controls to cloud infrastructure and production databases, the GitHub breach surfaces a gap that is easy to overlook: developer environments are a privileged access surface, and they are frequently governed as if they are not.

Apono’s GitHub integration brings ZSP enforcement to repository access, utilizing just-in-time grants tied to active work, automatic expiration, and full audit trails across every access event. It applies the same access architecture that security teams have already adopted for cloud and database access to the environment where source code, deployment logic, and infrastructure configuration actually live.

But the principle extends beyond repositories. The same Nx Console payload that harvested GitHub tokens also harvested AWS keys and cloud credentials. If the most sensitive assets in your environment are in cloud infrastructure, standing IAM roles and persistent cloud access are the exposure to address. If they are in production databases, persistent query credentials carry the same risk. The access architecture is the same across environments, the entry point just depends on where the attacker lands first.

The relevant question is not which environment needs ZSP enforcement. It is which environment an attacker will use to pivot into the rest.

The access story underneath the supply chain story

Supply chain attacks are a delivery mechanism. What they delivered is credential theft, and the blast radius of a stolen credential is determined entirely by how much standing access is attached to it. 

For organizations that have already made standing access the exception rather than the default, a breach like this is a contained incident with a limited blast radius. For those that haven’t, the attacker’s only limit is how far the credential reaches. 

Want to see where standing access is creating risk in your environment?

Explore how Apono helps security teams replace persistent access with just-in-time, just-enough privileges across modern infrastructure.

Get a Zero Standing Privilege (ZSP) assessment.