The GitHub Internal Repositories 2026 data breach began when a GitHub employee installed a poisoned Nx Console Visual Studio Code extension created through the TanStack supply-chain attack, leading to exfiltration of roughly 3,800 company-internal repositories. GitHub said it detected and contained compromise of the employee device on May 18, 2026, and immediately began incident response.
GitHub's official assessment limits the activity to exfiltration of internal repositories. Some of those repositories can contain customer-originated information such as excerpts from support interactions, while the company found no evidence of impact to customers' own enterprises, organizations, or repositories. No unique person count was published, so pwnCount and totalRecords remain zero as unknown.
How Was the Incident Confirmed?
An official security update by GitHub CISO Alexis Wales directly confirms that a poisoned third-party VS Code extension compromised an employee device and that GitHub-internal repositories were exfiltrated. The company said the attacker's claim of approximately 3,800 repositories was directionally consistent with its ongoing investigation. That figure measures repositories, not people or customer records.
BleepingComputer reported GitHub's confirmation and the roughly 3,800-repository scope on May 20; a May 21 follow-up reported the company's identification of the malicious extension as Nx Console. The reports independently corroborate the employee-device compromise, internal-repository exfiltration, customer boundary, and secret rotation in GitHub's blog. Additional claims in the actor's sale listing are not treated as confirmed scope.
How Did the Nx Console Attack Chain Work?
According to the Nx team, the TanStack supply-chain attack leaked a developer's GitHub CLI credentials and allowed the attacker to run workflows in the Nx repository. A malicious copy of Nx Console version 18.95.0 was then briefly published through Visual Studio Marketplace and Open VSX. Its payload was designed to collect secrets for services including GitHub, npm, AWS, Kubernetes, GCP, and Docker from developer machines.
Installation of the poisoned extension by a GitHub employee led to compromise of the work device and its GitHub access. GitHub removed the malicious marketplace version, isolated the endpoint, and began rotating critical secrets in impact order. The chain originated through a trusted-looking developer tool reaching an employee device, not a general authentication vulnerability in the GitHub platform.
What Data Was Exfiltrated?
The company-confirmed data class is information stored in GitHub's internal corporate repositories. Roughly 3,800 repositories is the technical scope GitHub said was directionally consistent with its investigation; it did not publish an inventory of each repository, unique file count, or total data volume. Although the actor claimed it was selling source code, LeakData uses only the company-confirmed class “internal repository data” as definitive scope.
GitHub specifically said some internal repositories contain customer-originated information, including excerpts from support interactions. This does not prove every repository contained customer data or every support customer was affected. The company said it would use established incident-response and notification channels if impact was identified, but did not publish a person, customer, or support-record total.
Were Customer Repositories or GitHub Cloud Affected?
The official update found no evidence of impact to customers' own enterprises, organizations, and repositories hosted on GitHub. Confirmed exfiltration is limited to GitHub's internal repositories. The platform's hundreds of millions of developers, millions of organizations, and overall repository count therefore cannot be converted into a breach total.
No incident-specific action was required for GitHub Enterprise Cloud customers. GitHub Enterprise Server administrators were asked to update the public GPG signing key on their instances after the company rotated it as a precaution. GitHub said all binaries it hosted were valid; the rotation request does not mean a malicious GHES binary was distributed.
How Were Signing Keys and Secrets Handled?
GitHub rotated critical secrets from Monday May 18 into Tuesday, prioritizing the highest-impact credentials. It continued analyzing logs, validating rotations, and monitoring infrastructure for follow-on activity. A May 26 update said the GitHub Enterprise Server signing key was also being changed out of an abundance of caution based on the repositories that had been attacked.
The GHES signing key validates GitHub as the source of a binary during a manually initiated update. Failure to install the new public key could prevent future patches and releases from verifying, but GitHub did not report corruption of existing hosted binaries. LeakData records key rotation as a response measure and does not infer that the key was abused or that malicious updates reached customer systems.
How Should This LeakData Record Be Read?
The breachDate is May 18, 2026, when GitHub detected and contained compromise of the employee device. The verified event is endpoint access through the poisoned Nx Console extension and exfiltration of roughly 3,800 GitHub-internal repositories. Because 3,800 is a repository count, it is not placed in pwnCount or totalRecords.
Readers should treat internal repository data and possible customer-support interaction excerpts inside those repositories as confirmed data classes. There is no evidence of impact to customers' own organizations and repositories or to GitHub Enterprise Cloud. The record can be updated if a full investigation report or notification total is published; the current zero means the number of people is unknown.
