The hacker group TeamPCP claimed to have breached approximately 4,000 of GitHub’s private internal repositories containing source code, posting the allegation on the Breached hacking forum alongside a demand of at least $50,000 for the stolen data. GitHub confirmed it is investigating and monitoring infrastructure for follow-on activity, stating there is “no evidence of impact to customer information stored outside of GitHub’s internal repositories.”
GitHub Confirms Investigation Into TeamPCP’s Repository Claim
GitHub acknowledged the breach claim the same day it appeared on Breached, confirming it is actively monitoring its infrastructure for signs of further exploitation. The company’s statement drew a deliberate line between internal repositories and customer-hosted code, asserting the two remain separate. Investigators have not confirmed or denied the volume of repositories TeamPCP claims to have accessed.
The scale of potential exposure matters regardless of the final scope. GitHub serves over 180 million developers and more than 4 million organizations worldwide, including 90% of Fortune 100 companies. Access to internal source code repositories — even those holding platform-side code rather than customer projects — could give an attacker a detailed map of GitHub’s authentication layers, internal API surfaces, and deployment infrastructure, information that could inform future exploitation attempts well after the current incident closes.
TeamPCP’s $50,000 Ransom and Threat to Leak Publicly
TeamPCP posted the breach claim alongside an extortion ultimatum: pay at least $50,000 or the data will be released publicly for free. Public leak threats are a standard pressure mechanism in data extortion campaigns, designed to accelerate a settlement by threatening reputational and competitive damage from unrestricted disclosure. GitHub has not commented on the ransom demand.
Why Internal Source Code Access Has Long-Tail Risk
Internal engineering code does not expose customer repositories directly, but historical incidents involving access to platform source code have enabled attackers to locate undisclosed vulnerabilities in the same platforms months later. Insider knowledge of how a platform’s authentication and service architecture is constructed gives adversaries a sustained intelligence advantage that persists long after the original incident is closed.
TeamPCP’s History of Supply Chain Attacks on Developer Infrastructure
TeamPCP has a documented record of targeting developer distribution platforms, including PyPI, the npm registry, and Docker Hub — the primary channels through which open-source dependencies flow into production software. Targeting GitHub’s internal repositories represents an escalation in scope: from poisoning packages distributed through those channels to potentially gaining visibility into the infrastructure that hosts the world’s largest software repository.
The Simultaneous TanStack npm and Grafana Connection
The GitHub breach claim appeared on the same day that separate reporting confirmed TeamPCP was behind a TanStack npm supply chain attack that served as the initial vector in the Grafana source code theft. In the Grafana incident, TeamPCP weaponized a TanStack npm package to steal GitHub workflow tokens, which then provided persistent access to Grafana’s private repositories. The simultaneous campaigns against Grafana, the TanStack npm ecosystem, and now GitHub itself form a pattern of concurrent intrusions across developer infrastructure rather than isolated opportunistic attacks.
The confirmed Grafana compromise lends credibility to the GitHub breach claim, demonstrating that TeamPCP has both the technique and the access chains to move from npm supply chains into private GitHub repository contents at scale.
