On May 20, 2026, GitHub confirmed that approximately 3,800 of its internal repositories had been exfiltrated and were being sold on cybercrime forums with a minimum asking price of $50,000. The threat actor group TeamPCP claimed responsibility.
The entry point was a Visual Studio Code extension installed on a GitHub employee's device.
Not a zero-day. Not a sophisticated intrusion into hardened infrastructure. A developer tool, installed on a developer's machine, doing what developer tools do: running with broad access to the files, credentials, and environment of the person using it.
The Same Group, The Same Playbook
If TeamPCP sounds familiar, it should. This is the group responsible for the supply chain attack in late March that compromised Trivy's GitHub Actions pipeline, poisoned two versions of LiteLLM, and led directly to the Mercor breach we wrote about last month.
Here is how the progression unfolded:
- March 2026: TeamPCP compromised Trivy (a security scanner), used it to poison LiteLLM (an AI gateway), and swept credentials from every system that pulled the malicious package. Among the stolen data from Mercor: Tailscale VPN configs, SSH keys, API keys, contractor PII.
- May 2026: TeamPCP used a malicious VS Code extension to compromise a GitHub employee's machine and exfiltrate nearly 4,000 internal repositories from one of the most heavily used developer platforms in the world.
Two attacks. Both targeting developer tooling. Both using trusted software in the development workflow as the entry vector. Both resulting in large-scale credential and code exposure.
This is not a pattern of opportunistic attacks. It is a deliberate, systematic effort to compromise the infrastructure that developers trust most, and by extension, to compromise everything that infrastructure touches.
Why Developer Tools Are the Target
A VS Code extension is not a marginal piece of software. It runs inside the editor that developers have open for eight or more hours a day. It has access to the files being edited, the terminal sessions being run, the environment variables that are loaded, and the credentials that development work depends on.
When a developer is working on a project, their environment typically contains API keys for services the project calls, authentication tokens for the platforms it integrates with, SSH keys for the servers it deploys to, and configuration files that describe network infrastructure, access policies, and internal endpoints. This is not poor practice. It is how development works. The credentials need to be accessible to the tools that use them.
A malicious extension running in that environment can read all of it. It does not need to exploit a vulnerability in the operating system or bypass a firewall. It is already inside the context where the secrets live, with permission to be there, because the legitimate version of that extension earned that permission.
GitHub rotated credentials immediately following the breach, a necessary response. But credential rotation after exfiltration addresses the known exposure, not the unknown one. The question is not just which secrets were in the repositories that were stolen, but which secrets were accessible to the extension while it was running.
What Lives in Repositories
The breach involved GitHub's internal repositories, not customer data — GitHub was clear about that. But internal repositories are not empty of sensitive material.
Source code contains hardcoded configurations. It contains references to internal services, network addresses, and authentication endpoints. It contains historical commits that may have included secrets which were later removed from the current codebase but remain accessible in the commit history. It contains infrastructure-as-code that describes exactly how systems are built and connected.
For an attacker mapping a target organization, internal source code is extraordinarily valuable. It is a detailed description of how the organization's systems work, what they connect to, and where the access points are. The $50,000 asking price on cybercrime forums reflects that value.
The Escalating Target: Developer Infrastructure
The broader trend that the Trivy, LiteLLM, and GitHub incidents collectively illustrate is a deliberate focus on developer infrastructure as an attack surface.
Security investment in recent years has hardened traditional perimeters: corporate networks have better monitoring, endpoints have EDR, email has improved filtering. But the software development pipeline, the chain of tools, platforms, packages, and services that developers use to build and deploy software, has received comparatively less scrutiny.
It runs with high privilege. It handles sensitive credentials. It is composed of many moving parts from many sources, most of them open source, most of them maintained by small teams with limited security resources. And it has access, ultimately, to every system that the software it produces is deployed on.
Compromising a step in that pipeline is, in many ways, more valuable than compromising an end-user machine. A malicious package or extension that reaches a developer's environment reaches every system that developer touches.
What Hardware Enforcement Protects
GitHub's internal repositories were accessible because an employee's machine was compromised. Teleportal does not protect GitHub's internal systems from a malicious VS Code extension. No network security product does, because that is a software supply chain problem, and it requires software supply chain solutions: extension vetting, code signing, sandboxed execution environments, and the kind of inventory discipline that knows exactly what is running in a developer's environment.
What hardware enforcement does protect is the network layer that organizations control themselves. The connection between your office and your remote sites. The access path to your internal servers. The link that, if secured only by software-defined credentials, becomes exploitable the moment those credentials appear in a compromised repository or get swept by a malicious tool.
When an attacker finds VPN credentials, API keys, or network configuration files in a stolen repository, as they found Tailscale configs in the Mercor breach, they gain a potential path into the networks those credentials protect. Hardware-enforced network links do not have that credential surface. There is nothing in a repository, nothing in an environment variable, nothing swept by a malicious extension that can be used to impersonate a Teleportal device or gain access to the network it protects.
The GitHub breach is a reminder that developer infrastructure is now a primary target, and that the credentials it produces and contains are a direct path to everything those credentials protect. Removing your network infrastructure from that credential surface is one of the cleaner ways to shrink what is at risk when the next breach happens.
And given TeamPCP's track record over the last sixty days, there will be a next breach.
Sources: CyberSecurity Dive, Varonis
Interested in what Teleportal can do for your network?
Learn More