Ho-ly G*t: TeamPCP Claims Theft of Thousands of GitHub Internal Repositories
GitHub said it is investigating unauthorized access to internal repositories after a compromised employee device was linked to a poisoned Visual Studio Code extension, marking another example of attackers targeting developer environments to reach sensitive source code and credentials.
The Microsoft-owned code-hosting platform said its current assessment is that the incident was limited to GitHub-internal repositories, and that it has found no evidence so far that customer repositories, customer-owned private code, or customer data outside GitHub’s internal environment were affected.
The threat actor claiming responsibility, TeamPCP, said it stole roughly 4,000 internal GitHub repositories. GitHub has said the attacker’s claim of about 3,800 repositories is “directionally consistent” with its own investigation.
A Poisoned Extension Inside the Developer Environment
According to GitHub’s public statements, the intrusion began with a compromised employee device involving a malicious version of a VS Code extension. That detail points to a familiar but increasingly dangerous attack path: rather than breaking directly into a company’s cloud infrastructure, attackers compromise the tools developers already trust.
GitHub said it isolated the affected endpoint, removed the malicious extension version, began rotating secrets, and continued reviewing the exposed repositories for any credentials or sensitive internal material that may have been present.
The company has not publicly released a full technical report on the malware, and some details remain unconfirmed. However, separate reporting on TeamPCP’s recent campaigns has tied the group to supply-chain attacks involving developer tools, package ecosystems, GitHub Actions, npm, PyPI, and VS Code extensions.
1/ We are sharing additional details regarding our investigation into unauthorized access to GitHub's internal repositories.
— GitHub (@github) May 20, 2026
Yesterday we detected and contained a compromise of an employee device involving a poisoned VS Code extension. We removed the malicious extension version,…
TeamPCP Claims Responsibility
TeamPCP, which has also been tracked by threat-intelligence researchers as UNC6780, claimed responsibility for the GitHub incident and reportedly offered the stolen repositories for sale on a cybercrime forum.
The group claimed it was not trying to extort GitHub directly and instead wanted a single buyer for the data. Multiple reports said the asking price was at least $50,000.
To support its claim, TeamPCP published evidence that appeared to include repository listings or file samples. GitHub has not confirmed the full scope of the stolen material publicly, but said the approximate repository count claimed by the actor aligned with what its investigation had found so far.
What Was and Wasn’t Affected
Based on GitHub’s public statements, the known impact appears to be limited to GitHub’s own internal repositories.
GitHub said it has not found evidence that the incident affected:
- Customer-owned private repositories
- Public GitHub user repositories
- Customer account data outside GitHub’s internal environment
- GitHub Enterprise customer environments
That said, the company’s wording matters. “No evidence so far” is not the same as a final all-clear. GitHub said it was continuing to monitor and investigate the incident.
The more immediate concern is whether any exposed internal repositories contained secrets, credentials, internal tooling, documentation, or other material that could create follow-on risk. GitHub said it began rotating critical secrets and reviewing the affected repositories as part of its containment process.
Why the Incident Matters
The incident highlights a growing problem for software companies: the developer workstation has become a major attack surface.
Security programs often focus heavily on production systems, cloud permissions, CI/CD pipelines, and source-code access controls. But local development tools - editors, plugins, package managers, terminal utilities, and build helpers - often sit close to sensitive credentials and internal code.
A malicious extension running on a developer’s machine can potentially steal tokens, scrape configuration files, access local repositories, and interact with internal systems through the developer’s existing permissions. That makes developer tooling an attractive shortcut around more heavily monitored infrastructure.
The Takeaway
The GitHub incident is not currently being described as a customer-data breach. The stronger conclusion is narrower but still serious: attackers allegedly used a compromised developer endpoint and malicious VS Code extension to access and exfiltrate thousands of GitHub-internal repositories.
For security teams, the lesson is clear. Developer tooling needs the same level of scrutiny as production infrastructure. That includes stricter extension approval policies, endpoint monitoring for developer machines, secret-scanning controls, rapid credential rotation, and tighter limits on how long local tokens remain useful.
In other words, the IDE is no longer just where software gets written. It is part of the security perimeter.
