TeamPCP Breached GitHub by Poisoning a Tool Developers Already Trusted

On May 20, 2026, GitHub confirmed what many in the security community had already begun piecing together. The company had been breached. Approximately 3,800 of GitHub's internal repositories had been exfiltrated by a threat actor group called TeamPCP. The stolen assets included infrastructure configurations, deployment scripts, staging credentials, and internal API schemas.

The entry point was not a zero-day vulnerability or a sophisticated network intrusion. It was a VS Code extension that a GitHub employee had already installed on their machine.

How TeamPCP got in

The breach did not begin at GitHub. It began weeks earlier, as part of a broader software supply chain campaign that SANS Internet Storm Center tracked in detail. TeamPCP had been systematically targeting open-source ecosystems since at least late 2025, compromising developer tools and npm packages to harvest credentials at scale. In early May 2026, the group successfully extracted credentials from the TanStack project through a malicious npm package. Those credentials were then used on May 11 to publish a trojanized version of the Nx Console, a widely used VS Code extension for managing monorepo projects.

The extension looked legitimate. It had a credible provenance, a recognizable name, and was already present in many developers' environments. When a GitHub employee installed or updated it, TeamPCP had their foothold. From there, the group moved through GitHub's internal systems and walked out with 3,800 repositories worth of source code, credentials, and architectural detail.

As Wired reported, GitHub is just the latest victim in a sustained supply chain campaign that has hit hundreds of projects. The group is not opportunistic. They are methodical, patient, and they have demonstrated a clear understanding of how developer trust works and how to weaponize it.

Why developer tools are the new attack surface

This breach is a supply chain story, but it is also an identity story. The VS Code extension did not exploit a vulnerability in GitHub's perimeter security. It exploited something more fundamental: the trust relationship between a developer and their toolchain.

Every extension, plugin, package, and integration that a developer installs becomes, in effect, a non-human identity operating in that developer's environment. It runs with the developer's permissions. It has access to the files the developer has access to. It can read credentials stored in configuration files, environment variables, and local secrets managers. When that extension is compromised, everything the developer trusted it with is compromised too.

This is the engine room problem that traditional security tools are not built to see. A developer installing a VS Code extension does not trigger a firewall alert. It does not show up as a suspicious login event. It does not generate a CASB notification. From the perspective of most security tooling, nothing happened. The extension went in, the credentials went out, and the breach unfolded entirely within a layer that most organizations are not watching.

Vorlon's 2026 CISO Report found that 99.4% of organizations experienced at least one SaaS or AI ecosystem security incident in 2025, despite running an average of 13 dedicated security tools. The GitHub breach illustrates exactly why that number is so high. The tools are watching the front door. The attack came through the engine room.

What visibility at the integration layer would have changed

The stolen assets in this breach were not bulk consumer data. They were staging credentials, internal API schemas, and infrastructure blueprints. These are the keys to the kingdom for a threat actor planning a follow-on attack. With staging credentials, an attacker can authenticate to systems that assume internal trust. With API schemas, they understand the architecture they are targeting. With deployment scripts, they understand how to operate within the environment without triggering anomaly detection.

This is the blast radius problem. A single compromised non-human identity, in this case an extension running with a developer's permissions, can expose credentials and structural knowledge that cascades far beyond the initial breach.

Vorlon maps every agent, identity, integration, and sensitive data flow across connected services, including the credentials and API keys those integrations carry. When a new integration appears in the environment, or when an existing one begins behaving outside its baseline, that is a visible event. Staging credentials that suddenly appear in outbound data flows, or API schemas being accessed by a process that has never touched them before, are the kinds of signals that behavioral detection at the integration layer is built to catch.

Vorlon's app directory covers over 1,000 connected services, and new integrations can be added within ten business days. The goal is not just coverage of known enterprise SaaS. It is visibility into the full ecosystem, including the developer toolchain where attacks like this one begin.

What security teams should do now

Audit installed VS Code extensions across your developer fleet. Most organizations have no centralized inventory of what extensions developers have installed. That needs to change. Know what is running in developer environments, verify the source and integrity of each extension, and establish a process for reviewing new installs.

Treat developer tool credentials as high-value targets. The credentials stored in developer environments, including environment variables, configuration files, and local secrets, carry significant access. They should be rotated on a schedule, scoped to the minimum necessary permissions, and monitored for unexpected use outside normal working patterns.

Monitor for credential use from unexpected contexts. A staging credential that has only ever been used from a specific internal IP range being used from a new location or at an unusual hour is a detectable event. Build alerting rules that flag this behavior in your SIEM, particularly for credentials associated with infrastructure access.

Extend your software supply chain security to developer tooling. Most software composition analysis and supply chain security programs focus on production dependencies. The GitHub breach was made possible through a development tool, not a production package. Expand your scope accordingly. Review the update and provenance policies for VS Code extensions, IDE plugins, and developer utilities the same way you review npm dependencies.

Map your non-human identities. Service accounts, API keys, OAuth tokens, and extension permissions are all non-human identities operating in your environment. Most organizations have limited visibility into how many of these exist and what they can access. An inventory of NHIs, combined with monitoring of their behavior, is one of the most direct ways to reduce the blast radius of a supply chain compromise.

TeamPCP did not find a hole in GitHub's defenses. They found a door that developers had already opened, waited for the right moment, and walked through it. The lesson is not that developers should stop using extensions. It is that the security perimeter has to extend to the tools developers trust every day.