GitHub's Internal Codebase Is Now in Criminal Hands

Border Cyber Group | May 20, 2026

On the morning of May 20, 2026, Microsoft's GitHub — the platform that hosts the source code for 180 million developers and 90 percent of the Fortune 100 — confirmed that a criminal hacking group had walked out with approximately 3,800 of its internal code repositories. The attacker wasn't a nation-state. There was no zero-day in GitHub's core infrastructure. No elaborate intrusion chain. A single employee installed a poisoned Visual Studio Code extension on their work machine, and that was enough. The group responsible, known as TeamPCP and tracked by Google's Threat Intelligence division as UNC6780, is now advertising the stolen code on criminal forums at an opening ask of $50,000, with a standing threat to release it for free if no buyer materializes.

GitHub's statement was careful, calibrated, and — in the way that corporate incident disclosures tend to be — revealing precisely in what it chose not to say. The company confirmed the breach, confirmed the approximate scale, confirmed that an employee device was the entry point, and assured users that "customer information stored outside of GitHub's internal repositories" showed no evidence of impact. The investigation, they noted, is ongoing. That last clause is the one worth watching.

TeamPCP is not a new name in security circles, though it may be to the wider public. The group has spent 2026 conducting what can only be described as a sustained, methodical campaign against developer infrastructure — not the applications developers build, but the tools they use to build them. In March, TeamPCP compromised Trivy, Aqua Security's open-source vulnerability scanner, using a GitHub Actions misconfiguration. That breach cascaded into Aqua Security's own Docker images, then downstream into the Checkmarx KICS project. From the Trivy compromise, the group deployed a poisoned LiteLLM package to PyPI — the Python package index — which installed their "TeamPCP Cloud Stealer" infostealer on tens of thousands of developer machines worldwide. Downstream victims of that campaign included the European Commission.

The pattern is worth sitting with. TeamPCP is not smashing windows. They are picking locks — specifically, the locks that developers trust implicitly because they are built into the tools of their daily workflow. A VS Code extension. A GitHub Action. A PyPI package. A dependency in a dependency. Each attack exploits the same fundamental dynamic: developers, by professional necessity, run foreign code on their machines constantly. The entire ecosystem of modern software development is built on a substrate of mutual trust that these actors have learned to weaponize with precision.

The question GitHub's disclosure conspicuously does not answer is how long TeamPCP had access before the company detected the intrusion. The employee device was compromised. The malicious extension was installed. At some point — a point nobody has publicly specified — GitHub's security team identified the activity, isolated the endpoint, began rotating credentials, and started counting repositories. Everything that happened between "install" and "detection" is the exposure window, and that window is currently unknown. In breach investigations, the exposure window is often the most consequential variable. It determines what else was accessed, what credentials were valid during that period, and what follow-on infrastructure may already be seeded.

Somewhere, right now, there are developers who saw the Microsoft acquisition of GitHub in 2018 and decided they'd had enough. They migrated to GitLab, or to self-hosted Gitea instances, or to Forgejo, or to Codeberg. Some left immediately. Others waited through a year or two of "nothing has changed" reassurances before making the move. They have been, in certain corners of the internet, the subject of mild ridicule — the open-source purists, the anti-corporate ideologues, the people who couldn't just be pragmatic about where the industry had landed.

Today is a good day to be one of those people.

The vindication is not simply that GitHub got hacked. Any platform can get hacked. The vindication is structural, and it cuts deeper than a single breach. The argument for leaving GitHub after the Microsoft acquisition was never purely sentimental. It was an argument about attack surface, about concentration of risk, and about what it means to place the entirety of the global software supply chain under a single corporate roof — a roof that also happens to belong to one of the most surveilled and targeted technology companies on earth. Microsoft is not just a software company. It is a defense contractor, a cloud infrastructure provider, a government partner across dozens of jurisdictions, and a perennial target of nation-state and criminal actors at a scale that most organizations cannot imagine. When you host your code at GitHub, you are not simply choosing a convenient repository tool. You are placing your intellectual property inside Microsoft's threat model.

That argument looked abstract in 2018. It looks considerably less abstract today.

The self-hosted contingent did not get here by accident. They got here by taking seriously a set of risks that the mainstream developer community preferred to discount, because discounting them was more convenient. The inconvenience of running your own Gitea instance — the maintenance overhead, the backup discipline, the access control hygiene — is precisely what produces a hardened posture. It forces exactly the kind of security deliberateness that a managed platform allows you to avoid thinking about. And when you stop thinking about it, you end up trusting that Microsoft has it handled. Today we know something about how well Microsoft had it handled.

Which brings us to Microsoft's accountability problem, and it is one worth being direct about.

The "it could happen to anyone" framing has already begun circulating in the security press. A malicious VS Code extension. A developer who didn't know. A sophisticated supply chain attack. These things are true as far as they go, and they are also exactly the kind of contextualizing language that enterprise PR departments deploy to soften the landing of a catastrophic failure. Applied to Microsoft operating GitHub, the framing collapses under its own weight.

Microsoft is not a startup with a lean security team and a limited budget. Microsoft is the company that sells endpoint security to the enterprise world — Defender for Endpoint, Defender for Cloud, Defender for Developers. Microsoft is the company that has spent the better part of a decade evangelizing zero-trust architecture to its corporate clients, publishing frameworks, white papers, and best-practice guides on the assumption that no device, no user, and no application should be implicitly trusted. Microsoft is the company that owns the VS Code extension marketplace where the malicious extension was distributed, and that operates the review and signing infrastructure for that marketplace. Microsoft is the company that owns GitHub, employs the developer whose machine was compromised, and is responsible for that developer's endpoint security posture.

A single poisoned extension on a single employee device produced unauthorized access to 3,800 internal repositories. That outcome requires a failure not in one place but in several simultaneously: endpoint visibility, extension vetting, privilege segmentation, and detection latency. The developer had access, from their personal workstation, to a volume of internal code that suggests something went wrong not only with endpoint hygiene but with the principle of least privilege — the foundational security concept that a user should only have access to what they strictly need to do their job. Three thousand eight hundred repositories is not a least-privilege footprint.

When Microsoft advises its enterprise clients on zero-trust implementation, it is advising them, among other things, to assume breach, verify explicitly, and use least-privilege access. The gap between that advice and what Microsoft's own environment apparently looked like is not a small gap.

The timing of this breach sits inside a remarkable cluster of GitHub-adjacent security failures that have accumulated over the past six weeks. In late April, researchers at Wiz disclosed CVE-2026-3854, a critical remote code execution vulnerability in GitHub itself — any authenticated user could execute arbitrary code on GitHub's servers using nothing more than a git push command. Days later, Grafana Labs disclosed that their entire private codebase had been stolen by a separate criminal group, CoinbaseCartel, through a GitHub Actions token misconfiguration. Simultaneously, reports emerged of popular GitHub Action tags being redirected to imposter commits designed to harvest CI/CD credentials from any workflow that called them. And now, the TeamPCP breach of GitHub's own internal repositories.

These are not unrelated incidents sharing a coincidental platform. This is a picture of an ecosystem under sustained, intelligent attack from multiple directions simultaneously. Developer infrastructure — the CI/CD pipeline, the extension marketplace, the dependency registry, the repository itself — has emerged as the highest-leverage attack surface in the current threat landscape, because compromising it doesn't require breaking into a single organization. It requires breaking into the tools that every organization trusts.

GitHub sits at the center of that ecosystem. And Microsoft, for all its security posture marketing, has demonstrated this week that sitting at the center of the most targeted developer infrastructure on earth carries consequences that cannot be fully managed, no matter how large your security team or how much you've spent on Defender.

The people who left are not surprised. They were never surprised. They just got tired of waiting to be proven right.

What happens next is, in some ways, more concerning than the breach itself. GitHub's internal codebase is now in the hands of a group that has demonstrated both the capability and the willingness to use stolen developer tooling as a vector for downstream attacks. The exposure window during which TeamPCP had access to those repositories remains unquantified. The specific VS Code extension used as the initial payload has not been publicly named. The investigation is ongoing.

Somewhere inside those 3,800 repositories there may be code that illuminates how GitHub's own infrastructure works — its internal APIs, its credential management, its deployment pipelines, its security tooling. TeamPCP has already shown that they know how to turn stolen developer intelligence into subsequent attacks. The Trivy-to-LiteLLM-to-PyPI cascade was not improvised. It was deliberate, patient, and technically sophisticated.

The $50,000 asking price on the criminal forum should not be taken at face value. It is an opening bid in a negotiation, and the most valuable customers for GitHub's internal codebase are not script kiddies looking for a deal. The investigation that matters most right now is not GitHub's incident response — it is the question of who else is looking at that code, and what they are planning to do with it.

Watch the next thirty days.

Border Cyber Group covers cybersecurity, cyberwarfare, and digital threat intelligence. bordercybergroup.com