TeamPCP GitHub Breach: Internal GitHub Repositories Allegedly Accessed

TeamPCP is back in the headlines, and this time the target is not a plugin, a CI/CD pipeline, or an open-source package. The group is claiming access to GitHub itself, one of the most critical pieces of infrastructure in the global software development ecosystem.

This is a developing situation. GitHub has confirmed an investigation is underway, and details are still emerging. Here’s what we know.

What Happened in the TeamPCP GitHub Breach?

TeamPCP posted on an underground hacking forum claiming to have accessed GitHub’s internal source code and private organization data. According to their post, the dataset includes approximately 4,000 private repositories, and they are asking for a minimum of $50,000 from a single buyer.

The group was direct about their intentions: this is not a ransom. They stated they have no interest in extorting GitHub, that only one buyer will receive the data, and that if no acceptable offer is made, they will leak everything publicly. To establish credibility, they offered to send file samples to interested buyers for verification and shared a public list of repository names. The post closed with Session and TOX contact details for potential buyers.

GitHub confirmed the breach on X, saying it is investigating unauthorized access to its internal repositories. The company noted it currently has no evidence that customer data stored outside its internal repositories (including customer enterprises, organizations, and code repositories) has been affected.

GitHub also said it is actively monitoring its infrastructure for any follow-on activity, and that affected customers will be notified through established incident response channels if evidence of impact is found.

How Did the TeamPCP GitHub Breach Happen?

GitHub shared additional details as the investigation progressed. The initial vector was a poisoned VS Code extension that compromised an employee device. GitHub detected and contained the device compromise, removed the malicious extension version, and isolated the endpoint before beginning incident response.

This is a significant detail. The entry point was not a zero-day in GitHub’s infrastructure or a brute-forced credential. It was a developer tool sitting on an employee’s machine. A poisoned IDE extension is exactly the kind of low-visibility, high-trust vector that TeamPCP has repeatedly exploited across its campaigns, and it is a reminder that even well-resourced platforms can be undermined through their own developers’ tooling.

GitHub’s current assessment is that the activity involved exfiltration of GitHub-internal repositories only. The attacker’s claimed figure of around 3,800 repositories is described by GitHub as directionally consistent with their investigation. Critical secrets were rotated as a priority during the initial response, with the highest-impact credentials addressed first.

What Are the Risks?

Even setting aside the immediate question of what’s in those repositories, the downstream risk of this kind of breach is substantial:

• Vulnerability discovery: Hostile actors reviewing internal source code can identify security flaws before they’re patched and weaponize them against GitHub’s platform or its users.
• Supply chain targeting: Internal tooling and deployment logic could reveal attack surfaces in GitHub Actions, package registries, or the release infrastructure that millions of projects depend on.
• Impersonation and phishing: Internal organization structures, personnel details, and communication patterns extracted from private repositories could fuel highly targeted social engineering campaigns against GitHub employees or customers.
• Follow-on access: Secrets, tokens, or credentials embedded in internal repositories, even old or rotated ones, can provide pivots into connected systems.

GitHub has said it rotated critical secrets quickly. But the exposure window between initial access and detection is the unknown variable, and that window is what will ultimately define the real-world impact of this breach.

Previous Breaches by TeamPCP

This is not a group that appeared out of nowhere. TeamPCP has been behind a sustained and escalating series of supply chain attacks throughout 2026, with each incident feeding into the next.

• Trivy (Aqua Security): TeamPCP compromised the Trivy vulnerability scanner via GitHub Actions, triggering a cascade that spread to Aqua Security Docker images and the Checkmarx KICS project.
• LiteLLM: The Trivy breach led to a compromised LiteLLM PyPI package that infected tens of thousands of devices with the group’s “TeamPCP Cloud Stealer” infostealer.
• Checkmarx (first incident): The group compromised Checkmarx’s GitHub Actions workflows and OpenVSX extensions, harvesting CI/CD secrets.
• Checkmarx Jenkins plugin (second incident): TeamPCP returned to Checkmarx, backdooring the Jenkins AST Scanner plugin at version 2026.5.09 and defacing the GitHub repository.
• Mini Shai-Hulud / npm and PyPI: A worm-like campaign compromising over 170 npm packages and PyPI packages from TanStack, Mistral AI, UiPath, OpenSearch, and SAP CAP projects, with exfiltrated data from two OpenAI employee devices confirmed as part of the blast radius.
• Mistral AI: TeamPCP advertised Mistral AI source code for sale, obtained via compromised CI/CD credentials.

The TeamPCP GitHub breach, if fully verified, represents a significant escalation: from targeting software that runs on GitHub, to targeting GitHub itself.

What Should the Developer Community Do Right Now?

GitHub has stated that customer repositories are not believed to be affected. But given TeamPCP’s demonstrated ability to use stolen internal data for follow-on attacks, a cautious posture is warranted across the ecosystem.

For GitHub Users and Organizations

• Watch for official communications from GitHub. The company has committed to notifying affected customers through established channels. Take those notifications seriously and act on them promptly.
• Audit third-party VS Code extensions installed across your team. The initial entry point in this breach was a poisoned IDE extension. Review what’s installed, where it came from, and whether it has access to sensitive environments.
• Review GitHub Actions workflows for any unexpected changes, new secrets requests, or unfamiliar third-party actions being referenced.
• Rotate GitHub tokens and secrets used in CI/CD pipelines as a precautionary measure, especially those with broad repository access.
• Monitor for suspicious commits authored as [email protected] or Dependabot-like branch names, which are known indicators from TeamPCP’s tooling across previous campaigns.

For Security Teams

• Treat any GitHub-adjacent secrets (tokens, deploy keys, OAuth apps, GitHub Apps) as elevated risk until the investigation concludes.
• Watch GitHub’s official communications and the fuller incident report the company has committed to publishing once the investigation is complete.

How Can SOCRadar Help?

As TeamPCP’s campaigns grow in scope and ambition, the threat surface they represent extends well beyond any single vendor. From compromised plugins and poisoned packages to internal repository breaches at platform-level targets, the group’s operations touch virtually every layer of the software development and delivery chain.

SOCRadar’s Supply Chain Intelligence continuously monitors the security posture of the vendors, tools, and platforms your organization depends on, surfacing risk signals early, before a third-party compromise becomes your incident.

SOCRadar’s Dark Web Monitoring keeps watch on the underground forums and threat actor channels where stolen data surfaces first. When source code, credentials, or internal data is advertised for sale, SOCRadar alerts you, giving your team the context and lead time to act before the impact reaches you.

The TeamPCP GitHub breach is a reminder that no platform is too large to be targeted. Visibility into where threats emerge and where stolen data ends up is what turns a reactive posture into a proactive one.