GitHub says poisoned VS Code extension exposed 3,800 repos

GitHub said on 20 May that a compromised employee device running a poisoned VS Code extension led to the exfiltration of roughly 3,800 internal repositories.

In its incident disclosure, the company said it detected and contained the compromise on 18 May, rotated critical secrets across Monday and Tuesday, and found no evidence that customer information stored outside GitHub’s internal repositories was affected.

The disclosure matters partly because GitHub had already described almost this exact attack pattern in March. In a security-roadmap post about GitHub Actions, the company warned that attackers were increasingly targeting CI/CD automation itself, using compromised dependencies, over-permissioned credentials, and unrestricted network access to spread across large numbers of repositories. It reads a bit like a pre-mortem.

“We detected and contained a compromise of an employee device involving a poisoned VS Code extension,” GitHub wrote in the post. The company added that the attacker’s claim of access to about 3,800 repositories was “directionally consistent” with its own investigation.

Nx, the maintainer of the Nx Console extension, published the clearest upstream account of how that extension was compromised. The company said a malicious v18.95.0 release was briefly published on 18 May, and that anyone who installed it between 12:30 and 13:09 UTC should treat their machine as compromised and rotate credentials.

According to Nx’s postmortem, the chain started earlier at TanStack, where attackers exploited a vulnerability in a GitHub Actions publishing pipeline and used a legitimate OIDC trusted-publisher binding to push 84 malicious package versions across 42 packages. Nx said one contributor’s developer machine then resolved one of those malicious packages during a routine install, which led to the poisoned extension release. This is the sort of sentence that makes supply-chain security sound abstract right up until it reaches an employee laptop with access to internal code.

GitHub said the exfiltrated material was limited to GitHub-owned repositories, though some of those repositories may contain customer-related information such as support excerpts. TechCrunch and BleepingComputer both reported the same broad figure of about 3,800 repositories after GitHub’s disclosure.

The predictable part is not that GitHub was breached, but that a developer workstation and trusted tooling sat in the middle of the blast radius. In its March roadmap post, GitHub wrote that too many CI/CD vulnerabilities are still easy to introduce and hard to detect. That warning was aimed at customers, but it now doubles as a concise description of what appears to have happened inside GitHub itself.

There are still important gaps. GitHub has not yet published the fuller report it said would follow, so it has not publicly detailed what protections were present on the employee device, what internal segmentation limited the breach, or exactly which categories of repository data were taken. It was also GitHub, not an outside auditor, that said it had no evidence of impact to customer information outside internal repositories.

GitHub said it would publish more details once its investigation is complete.

Key Takeaways

GitHub said on 20 May that a poisoned VS Code extension on an employee device led to the theft of about 3,800 internal repositories.
The company said it detected and contained the compromise on 18 May and rotated critical secrets across Monday and Tuesday.
GitHub said it has no evidence that customer information stored outside its internal repositories was affected.
Nx said the malicious Nx Console v18.95.0 release was available for less than 40 minutes on 18 May.
GitHub had warned in March that attackers were targeting CI/CD automation and over-permissioned tooling in exactly this way.