GitHub Says Internal Repositories Were Breached After Poisoned VS Code Extension Attack

GitHub has confirmed that attackers accessed GitHub-owned internal repositories after compromising an employee device through a poisoned Visual Studio Code extension. The company said its current assessment shows exfiltration of internal repositories only, with no evidence so far that customer enterprises, organizations, or repositories were directly affected.

The incident has been linked to TeamPCP, a financially motivated threat group known for software supply chain attacks against developer tools and open-source projects. The group claimed it obtained roughly 4,000 private repositories tied to GitHub and offered the stolen data for sale on cybercrime forums.

GitHub said the attacker’s claim of about 3,800 repositories is directionally consistent with its investigation. The company removed the malicious extension version, isolated the affected endpoint, rotated critical secrets, and said it continues to monitor infrastructure for follow-on activity.

What GitHub confirmed

GitHub disclosed the incident on May 20, 2026, saying it detected and contained the compromised employee device on May 18. The malicious extension had been published by a third party and was used to reach internal GitHub-owned repositories.

The company said it found no evidence of impact to customer information stored outside of GitHub’s internal repositories. That includes customer-owned enterprises, organizations, and repositories.

However, GitHub also noted that some internal repositories may contain limited customer-related information, such as excerpts from support interactions. If the investigation finds direct impact, GitHub said it will notify affected customers through its normal incident response channels.

GitHub breach at a glance

Item	Details
Company affected	GitHub
Incident disclosed	May 20, 2026
Initial containment	May 18, 2026
Attack vector	Poisoned third-party VS Code extension on an employee device
Data accessed	GitHub-owned internal repositories
Attacker claim	About 3,800 to 4,000 repositories
Customer repository impact	No evidence so far
Response	Endpoint isolated, malicious extension removed, critical secrets rotated

TeamPCP claims it stole GitHub source code

TeamPCP claimed responsibility for the breach and said it had extracted proprietary GitHub source code and internal organization data. The group reportedly offered the dataset for sale, with the asking price starting above $50,000.

The threat actor also published file lists and screenshots to support its claim. GitHub has not endorsed the attacker’s full version of events, but it did say the repository count in the claim is broadly aligned with its investigation.

The distinction matters. TeamPCP claimed access to about 4,000 repositories, while GitHub’s own wording points to roughly 3,800 GitHub-internal repositories and says customer-owned repositories are not believed to have been affected.

How the poisoned extension fits into the attack

The breach highlights the danger of developer tools that run inside trusted coding environments. Visual Studio Code extensions can access project files, terminals, credentials, environment variables, and other sensitive developer resources depending on their behavior and permissions.

In this case, GitHub said the employee device was compromised through a poisoned extension published by a third party. Separate reporting and the Nx team’s postmortem point to the compromised Nx Console extension version 18.95.0 as the malicious extension involved in the wider incident.

The Nx team said the malicious version was published to the Visual Studio Marketplace and Open VSX on May 18, 2026. The package was removed quickly, but users with auto-update enabled may have received the malicious version during the exposure window.

Why developer devices are attractive targets

Developer workstations often hold the keys to larger software environments. A single compromised device can expose source code, cloud tokens, package publishing credentials, SSH keys, GitHub access tokens, and internal documentation.

That makes developer tooling a powerful attack path. Attackers no longer need to break directly into production servers if they can compromise the tools used to build, test, and deploy software.

TeamPCP has repeatedly used this model. The group compromises one trusted project or developer tool, steals credentials from users who install it, and then uses those credentials to compromise more tools or repositories.

Potential risks from the GitHub internal repository breach

• Exposure of GitHub internal source code and engineering details.
• Possible leakage of internal documentation or operational metadata.
• Exposure of limited customer-related support excerpts inside internal repositories.
• Risk of attackers studying internal code for future attacks.
• Possible abuse of any secrets not yet identified or rotated.
• Reputational damage from stolen source code being offered for sale.

GitHub’s response so far

GitHub said it removed the malicious extension version and isolated the affected employee endpoint after detecting the compromise. It also began incident response immediately.

The company rotated critical secrets from May 18 into May 19, prioritizing credentials with the highest potential impact. It is also reviewing logs and watching for any follow-on attacker activity.

GitHub said it will publish a fuller report after the investigation ends. That report should clarify the final scope, what data was accessed, whether any customer-related material appeared in internal repositories, and what further controls were added.

GitHub action	Purpose
Removed malicious extension version	Stopped further exposure from the poisoned package.
Isolated affected endpoint	Cut off attacker access through the compromised device.
Rotated critical secrets	Reduced the risk of stolen credentials being reused.
Analyzed logs	Checked for additional attacker activity and access paths.
Continued infrastructure monitoring	Watched for follow-on activity after containment.

TeamPCP’s wider supply chain campaign

TeamPCP has become one of the most active groups targeting software development ecosystems. The group has been linked to attacks against open-source utilities, security tools, AI-related packages, and developer platforms.

Researchers have also associated the group with Mini Shai-Hulud, a self-spreading malware campaign that steals developer credentials and uses them to push additional malicious packages or code updates.

We are investigating unauthorized access to GitHub’s internal repositories. While we currently have no evidence of impact to customer information stored outside of GitHub’s internal repositories (such as our customers’ enterprises, organizations, and repositories), we are closely…

— GitHub (@github) May 19, 2026

SANS Internet Storm Center has noted that Google Threat Intelligence Group tracks TeamPCP as UNC6780. The same reporting tied the group to earlier compromises involving Trivy, Checkmarx, LiteLLM, and Telnyx.

How this supply chain pattern spreads

Step	What attackers do
1	Compromise a developer, maintainer, or trusted software project.
2	Publish a malicious package, extension, plugin, or tool update.
3	Steal credentials from developers who install or auto-update the tool.
4	Use stolen credentials to access repositories, CI/CD systems, and cloud services.
5	Repeat the process by poisoning more projects or selling stolen data.

What GitHub users should know

GitHub users do not need to assume that their private repositories were stolen based on the company’s current statement. GitHub said it has no evidence of impact to customer data stored outside internal repositories.

Still, organizations should treat this incident as a reminder to review developer access. Private repositories can still contain secrets, tokens, and sensitive deployment details if teams do not enforce strong hygiene.

Companies should also review whether their developers use unmanaged VS Code extensions, auto-updating plugins, or personal access tokens with broad permissions.

Recommended steps for developers and security teams

• Review installed VS Code extensions across developer machines.
• Remove extensions that are unused, untrusted, or no longer maintained.
• Audit GitHub personal access tokens and rotate unnecessary long-lived tokens.
• Use fine-grained tokens with the minimum permissions needed.
• Monitor GitHub audit logs for unusual cloning, token use, or permission changes.
• Scan repositories for secrets and remove exposed credentials.
• Restrict extension installation in managed enterprise environments.
• Consider delaying non-security extension updates until they receive basic review.

Why this breach matters

The GitHub breach shows how modern software supply chain attacks can move through trusted developer tooling rather than direct infrastructure attacks. A poisoned extension can become a bridge into high-value source code environments.

It also shows why fast containment is only part of the response. GitHub must determine exactly what the attackers saw, whether any secrets remained valid, and whether any internal customer-related material appeared in accessed repositories.

For the broader software industry, the lesson is clear. Developer tools need stronger update controls, better publisher protections, tighter credential management, and faster detection when a trusted tool begins acting like malware.

Summary

• GitHub confirmed unauthorized access to GitHub-owned internal repositories.
• The breach came through a poisoned third-party VS Code extension on an employee device.
• TeamPCP claimed access to about 4,000 private repositories and offered the data for sale.
• GitHub said about 3,800 repositories is directionally consistent with its investigation.
• GitHub has no evidence so far that customer-owned repositories were affected.
• The company removed the malicious extension version, isolated the endpoint, and rotated critical secrets.
• The incident highlights the growing risk of developer tool supply chain attacks.

FAQ