GitHub Breach 2026: How a VS Code Extension Exposed 3,800 Repos
A detailed look into the May 2026 GitHub supply chain breach, where a compromised Nx Console VS Code extension led to the exfiltration of 3,800 internal repositories.
If you’ve been following the tech news over the past couple of days, your timeline has probably been a mess of security alerts and emergency patch notes. The developer ecosystem just experienced one of the most sophisticated supply chain attacks we’ve seen recently—and the biggest shockwave was that GitHub itself was breached.
We’ve spent the last decade building incredible automation. CI/CD pipelines, auto-updating extensions, and seamless package management make our lives as developers infinitely easier. But this week, those exact conveniences were weaponized against us.
Here is a breakdown of what actually happened, and why it represents a fundamental shift in how we need to think about trust in our tooling.
The “Verified Publisher” Problem
The root of the GitHub breach wasn’t a sophisticated zero-day in their core infrastructure. It started with a VS Code extension.
On May 18, 2026, a malicious build of the Nx Console VS Code extension (version 18.95.0) was published to the Visual Studio Marketplace. The attacker, a cybercrime group known as TeamPCP (also tracked as UNC6780), didn’t spoof the publisher. Instead, they used a legitimate, stolen Nx maintainer token—harvested earlier via a TanStack supply chain attack (CVE-2026-45321).
Because the publisher account was legitimate, the extension carried the marketplace’s “Verified Publisher” badge. It was live on the Visual Studio Marketplace for only 18 minutes (from 12:30 to 12:48 UTC) before it was pulled. But that brief window was all it took.
On a GitHub employee’s endpoint, the extension auto-updated during that period. The trojanized extension silently ran a shell command that harvested credentials from 1Password vaults, SSH keys, AWS credentials, and Anthropic Claude configurations. TeamPCP then used the exfiltrated SSH keys to clone approximately 3,800 of GitHub’s internal repositories. Fortunately, GitHub’s current assessment indicates that no customer data stored outside of its internal repositories was affected.
The Contagion Spread
GitHub wasn’t the only victim of this supply chain campaign. The initial TanStack compromise that led to the stolen token also impacted other major tech companies, including OpenAI, Mistral AI, and Grafana Labs.
TeamPCP has been executing this same playbook for months, targeting open-source infrastructure like AquaSecurity’s Trivy vulnerability scanner, Checkmarx KICS, and Bitwarden CLI. The interlinked nature of the attack is the point: the attackers break into one trusted tool, harvest developer credentials, and use those credentials to break into the next trusted tool.
Are We Too Trusting?
This incident exposes a massive gap in how we handle developer tooling. We have been trained to look for verified badges and official publishers. But as this attack proved, a legitimate publisher account does not guarantee a legitimate publish event.
For years, we’ve treated local developer environments as safe havens. A VS Code extension runs with the same privileges as the editor itself, meaning a single poisoned package gives an attacker the exact same access as the developer running it. When a malicious payload executes just by letting your IDE auto-update, our current defense layers are insufficient.
The Verdict
The days of blindly trusting auto-updates are over. If your team is using ephemeral CI runners, local extensions, or pulling dependencies without strict version pinning and active extension monitoring, you are structurally exposed.
The tooling ecosystem is going to have to evolve rapidly to address this. We need richer security contexts, isolated execution for IDE extensions, and perhaps an end to default auto-updates for critical developer tools. Until then, it might be time to lock down your package versions and take a hard look at exactly what your editor is running in the background.