GitHub Data Breach Confirmed After Poisoned VS Code Extension Exfiltrates Internal Repositories

GitHub has confirmed a data breach involving unauthorized access to internal repositories after an employee device was compromised through a poisoned Visual Studio Code extension.

The company said its current assessment is that the activity involved exfiltration of GitHub-internal repositories only. GitHub also said it currently has no evidence that customer information stored outside those internal repositories was affected, including customer enterprises, organizations, and repositories.

The disclosure followed a claim from TeamPCP, which advertised alleged GitHub source code and internal organization data for sale on a cybercrime forum. The group claimed the material included roughly 4,000 private repositories. GitHub later said the attacker’s claim of about 3,800 repositories is directionally consistent with its investigation so far.

GitHub said it detected and contained the compromise, removed the malicious extension version, isolated the affected endpoint, and began incident response. The company also said critical secrets were rotated, with the highest-impact credentials prioritized first, while it continues to analyze logs and monitor for follow-on activity.

TeamPCP Claims GitHub Source Code Was Stolen

TeamPCP claimed it had GitHub internal source code and internal organization data for sale. A forum post attributed to the group said the data was not part of a ransom demand and claimed the material would be sold to one buyer or leaked for free if no buyer was found.

Botcrawl has not independently verified the contents of the alleged dataset. GitHub has confirmed exfiltration of internal repositories, but the company has not published a full technical report yet and has not confirmed that customer repositories, customer organizations, or customer account data were affected.

The confirmed GitHub data breach is still significant because internal repositories can contain source code, internal tooling, tests, build logic, documentation, configuration references, and engineering material that may help attackers understand how a platform is built. The practical risk depends on what was taken, whether any secrets were present, and whether the stolen material can be used for follow-on activity.

The Breach Started With a Poisoned VS Code Extension

The access path is one of the most important parts of the incident. GitHub said the employee device was compromised through a poisoned VS Code extension, which points to developer-tool compromise rather than a direct attack against GitHub’s public repository platform.

That type of access can still be serious. A malicious extension running on a developer endpoint can reach files, credentials, sessions, internal repositories, build systems, cloud tools, and other resources available to that user or device. In this case, GitHub says the activity involved GitHub-internal repositories, and the company responded by isolating the endpoint and rotating critical secrets.

GitHub has not named the malicious extension in its public posts. The company said it removed the malicious extension version, but developers and security teams should not assume extension risk is limited to this incident. Visual Studio Code extensions, package managers, build tools, and local developer environments remain attractive targets because they sit close to source code and credentials.

What GitHub Has Confirmed

GitHub has confirmed unauthorized access to internal repositories, compromise of an employee device through a poisoned VS Code extension, removal of the malicious extension version, endpoint isolation, and critical secret rotation.

The company has also said the attacker’s claim of about 3,800 repositories is directionally consistent with its investigation so far. That does not confirm every claim made by TeamPCP, but it does place the public repository count close to GitHub’s current assessment.

GitHub’s statement also limits the known scope. The company says it has no evidence of impact to customer information stored outside GitHub’s internal repositories, including customer enterprises, organizations, and repositories. That wording does not close the investigation. It describes what GitHub says it knows right now.

What Is Still Unknown

GitHub has not published a complete list of affected repositories, the name of the malicious extension, the full timeline of the employee device compromise, or the specific kinds of internal code and engineering material that were taken.

The company has also not said whether any repository contents contained long-lived credentials, internal deployment details, customer-adjacent tooling, or sensitive platform logic beyond the internal repository data already acknowledged. GitHub said it rotated critical secrets and is validating that rotation, which shows possible credential exposure is part of the response.

Until GitHub publishes its fuller report, the safest reading is that this is a confirmed GitHub data breach involving internal repositories, a confirmed poisoned VS Code extension compromise, and an ongoing investigation into follow-on risk.

Developer Tooling Was the Access Path

This breach fits a broader pattern of attacks against developer tooling. A malicious extension or package does not need to compromise a company’s main production platform directly if it can run on a trusted developer machine with access to internal code and credentials.

Developer endpoints often hold GitHub sessions, SSH keys, cloud credentials, package tokens, build secrets, environment files, and access to private repositories. If one of those endpoints runs malicious tooling, the attacker can work through the permissions already granted to the user, device, or development environment.

That makes the GitHub data breach both a source-code incident and a developer-supply-chain incident. The affected platform is GitHub, but the access path was a poisoned extension running in a trusted development environment.

What Developers and Security Teams Should Check

Developers should review installed VS Code extensions, remove anything unfamiliar or unnecessary, and check whether extension publishers, versions, update history, or permissions changed unexpectedly. Teams should also review endpoint telemetry and repository access logs for unusual activity tied to developer machines.

Organizations should check whether secrets are stored in private repositories, developer workstations, local configuration files, or CI/CD environments. Private repositories are not a safe place for API keys, signing keys, deployment tokens, cloud credentials, or long-lived access tokens. If a developer endpoint is compromised, those secrets should be treated as exposed until proven otherwise.

Security teams should also review repository cloning activity, GitHub token usage, SSH key access, cloud API calls, package publishing activity, and any unexpected repository creation or export events. GitHub said it rotated critical secrets after the breach, and organizations should apply the same logic if a developer machine with sensitive access is suspected of running a malicious extension.

GitHub says it will publish a fuller report once the investigation is complete. For now, the public facts are clear enough to frame the incident accurately. GitHub confirmed a data breach involving internal repositories, the access came through a poisoned VS Code extension on an employee device, TeamPCP claimed to have obtained thousands of private repositories, and GitHub says it currently has no evidence that customer information outside GitHub’s internal repositories was affected.