The GitHub Breach and the Developer Supply Chain: What the TeamPCP Cascade Means for Your Business
A poisoned editor extension breached the world's largest source code platform. The real story is the trail of connected companies that led there, and the developer trust model the attackers exploited.
This week, GitHub confirmed that attackers had exfiltrated roughly 3,800 of its internal repositories after a poisoned Visual Studio Code (VS Code) extension was installed on an employee device. The threat group TeamPCP (tracked by Google Threat Intelligence Group as UNC6780) claimed responsibility and listed the stolen material for sale on a cybercrime forum for at least $50,000. GitHub has stated that customer repositories, enterprise organisations, and user data appear to be unaffected.
That sentence is reassuring on its own. Read in the context of the past two months, it is anything but. The GitHub incident is the latest stop on a cascading supply chain campaign that has, since March 2026, run through Aqua Security's Trivy scanner, Checkmarx's KICS and AST GitHub Actions, BerriAI's LiteLLM, the Telnyx Python SDK, dozens of npm packages, and a string of Docker Hub images. Each compromise harvested credentials that enabled the next. The platform that hosts most of the world's code became a target precisely because the developer trust surface around it had already been softened.
This article looks at how the breach happened, the wider web of connected companies caught up in the TeamPCP campaign, and what UK organisations should be doing now to reduce their exposure.
What happened at GitHub
GitHub's public account is brief but informative. On 19 May, its security team detected and contained the compromise of an employee endpoint linked to a poisoned VS Code extension. The malicious version was pulled from the Marketplace, the device was isolated, and critical credentials were rotated within hours. The following day, GitHub confirmed the attacker's claim of around 3,800 exfiltrated internal repositories as "directionally consistent" with its own findings.
GitHub has not formally named the specific extension. Researchers have pointed to the timing of the Nx Console (nrwl.angular-console) compromise on 18 May, when a malicious version was pushed to the Marketplace with more than two million existing installs, as the most plausible candidate, though this remains unconfirmed. What is not in dispute is the mechanism: a developer installed an extension from a trusted marketplace, the extension auto-executed on the workstation, and the attacker rode that initial foothold into internal source code.
The repositories taken reportedly include code relating to Copilot, GitHub Enterprise Server, and internal red team tooling. The principal downstream risk is not the source code itself (much of GitHub's codebase is partially open) but secrets, tokens, and credentials embedded inside those repositories, even old or rotated ones. Each of those is a potential pivot into a connected system. The window between initial access and detection is the unknown variable, and that variable defines real-world impact.
The connected companies: a two-month cascade
TeamPCP did not arrive at GitHub by accident. Since March 2026 the group has been running a sustained campaign against developer tooling, with each compromise feeding the next:
- Aqua Security / Trivy (19 March). TeamPCP force-pushed a malicious release tag (v0.69.4) to the Trivy vulnerability scanner repository, embedding a three-stage credential stealer into a tool used in over 10,000 CI/CD pipelines. The incident was assigned CVE-2026-33634 (CVSS 9.4). Within two minutes on 22 March, all 44 internal Aqua Security repositories were defaced and renamed.
- npm ecosystem (20 March). Within 24 hours of the Trivy compromise, a follow-on worm dubbed CanisterWorm was deployed to npm using stolen publish tokens, infecting more than 50 packages and using an Internet Computer Protocol blockchain canister as a command-and-control resolver to resist takedown.
- Docker Hub (22 March). Additional malicious Trivy container images were published as v0.69.5 and v0.69.6 using compromised credentials.
- Checkmarx (23 March). Using CI/CD secrets harvested from Trivy users, TeamPCP compromised Checkmarx's
kics-github-actionandast-github-actionrepositories, published malicious extensions to the OpenVSX IDE marketplace, and exfiltrated data through typosquatted domains such ascheckmarx.zone. Checkmarx has since confirmed exfiltration of its own GitHub repositories. - LiteLLM (24 March). Two malicious versions (1.82.7 and 1.82.8) of BerriAI's LiteLLM (a Python library Wiz estimates is present in roughly 36% of cloud environments) were published to PyPI using a stolen token. They were live for around three hours before quarantine. The build pipeline had been using Trivy for security scanning.
- Telnyx Python SDK (late March). A fourth widely deployed package was also poisoned in the same coordinated wave.
- Grafana Labs (April). A separate but contemporaneous supply chain attack saw attackers access GitHub repositories belonging to Grafana Labs. The company refused ransom demands and mitigated through tightened access controls.
- GitHub itself (19 May). The poisoned VS Code extension compromise.
The pattern is consistent. Each victim was a trusted node in the development workflow: a scanner, a static analysis tool, an AI gateway, an editor extension. Each had privileged access to credentials, build pipelines, or developer endpoints. And each compromise yielded the credentials needed to attack the next.
Why developer tooling is now the perimeter
Two structural realities make these attacks viable, and they are not specific to GitHub.
The first is that security scanning and CI/CD tooling occupy uniquely privileged positions. A vulnerability scanner that runs inside a build pipeline has simultaneous access to cloud credentials, source code, container registries, and deployment infrastructure. Compromising the scanner means compromising everything the scanner can see. The same logic applies to IDE extensions: code editors run with the user's full privileges, can read any file on disk, and frequently hold tokens for GitHub, cloud providers, and package registries.
The second is that the trust model around developer marketplaces is fundamentally optimistic. VS Code auto-updates extensions by default. Wiz Research recently found more than 100 valid VS Code Marketplace publisher tokens and 30+ OpenVSX access tokens leaked inside extension packages on disk. A single leaked publisher token gives an attacker push access to every install of every extension that publisher owns. There is, in most cases, no meaningful signal at install time that anything is wrong.
The result is a perimeter that most organisations do not treat as one. Developer workstations are typically less hardened than user laptops, run elevated tooling, hold long-lived tokens, and connect freely to public registries. When the platform that hosts the world's code says "we were phished through an editor extension," the implication for the rest of the industry is direct: the developer workstation is the perimeter, and the editor's plugin ecosystem is part of that perimeter.
What this means for UK organisations
You do not need to be the next GitHub for the TeamPCP campaign to matter to you. If your developers run Trivy, use Checkmarx GitHub Actions, install community VS Code extensions, depend on npm or PyPI, or pull container images from Docker Hub, you have already touched the blast radius of this campaign, even if you have not been directly compromised. The realistic risk picture has three layers:
- Direct exposure. Did you run any of the poisoned versions inside your CI/CD pipelines between 19 March and now? Build logs and lockfiles are the source of truth here, not memory.
- Credential leakage. Tokens, secrets, and cloud credentials present in the affected environments during the exposure windows should be assumed compromised and rotated, even if no malicious activity has been observed.
- Latent persistence. Several of these compromises included persistence mechanisms in CI workflows, meaning malicious code could be reintroduced after initial cleanup. One-shot remediation is not enough.
Practical controls that genuinely reduce risk
A defensible response combines short-term hygiene with structural changes to how developer trust is granted:
- Pin dependencies and GitHub Actions to immutable commits, not tags. Tags are mutable by default in Git. Most organisations protect branches but not tags, which is precisely how TeamPCP achieved tag poisoning at Aqua Security and Checkmarx. Pin to commit SHAs.
- Lock down VS Code and IDE extensions. Disable auto-update for production developer machines, maintain an allowlist of vetted extensions, and consider organisation-level controls in VS Code and JetBrains environments. Treat IDE plugins as software with privileged execution rights, because they are.
- Scope and rotate developer tokens aggressively. GitHub personal access tokens with organisation-wide write access are catastrophic when leaked. Prefer fine-grained tokens, short lifetimes, and OIDC-based federation for CI/CD wherever possible. Service accounts should not hold permanent broad-scope PATs.
- Treat developer endpoints as Tier 1 assets. Apply the same EDR, monitoring, and least-privilege rigor to developer workstations that you apply to admin systems. Egress monitoring matters: most of the TeamPCP payloads were detected because a CI runner or developer endpoint contacted an unexpected external domain.
- Audit CI/CD secrets and reduce blast radius. Cloud credentials, signing keys, and registry tokens should be scoped to the minimum necessary repository and pipeline, with no cross-environment reuse. Where short-lived credentials are supported, use them.
- Watch for persistence in workflows. After any suspected compromise, review GitHub Actions workflow files, scheduled jobs, and runner configurations for unexpected modifications, not just package versions.
- Subscribe to credible supply chain advisories. The exposure windows in this campaign were short (LiteLLM was live for around three hours), so detection depends on knowing quickly. Aqua, Checkmarx, GitHub, Wiz, and StepSecurity all published timely advisories.
Frequently asked questions
Were GitHub customer repositories affected by the May 2026 breach?
Based on GitHub's current public statements, the exfiltration was limited to GitHub-internal repositories, with no evidence of impact to customer organisations, enterprises, or user repositories. That assessment may evolve as the investigation continues, and customers with secrets that may have been referenced in GitHub-internal systems should still apply normal credential rotation hygiene.
Should we stop using Trivy, Checkmarx, or LiteLLM?
Not necessarily. All three vendors have remediated the affected versions and rotated credentials. The lesson is not "abandon these tools" but "pin to vetted versions, monitor egress from CI/CD, and assume any credentials accessible during the exposure windows are compromised."
How do we know if we ran a poisoned version?
Review CI/CD build logs, lockfiles, and container image histories for the affected version numbers (for example Trivy v0.69.4 to v0.69.6, LiteLLM 1.82.7 and 1.82.8) across the exposure windows. Static configuration files do not tell the full story. Actual pulled versions matter, particularly where floating tags or "latest" pulls are in use.
Is this primarily a problem for software companies?
No. Any organisation that builds, customises, or deploys software internally is exposed, including financial services firms, retailers, manufacturers, and the public sector. CI/CD pipelines and developer endpoints exist wherever code is built, and the credentials they hold typically reach into production cloud environments.
Will paying ransom resolve a supply chain compromise?
No. Grafana Labs publicly refused TeamPCP's ransom demands and remediated through internal controls. Paying does not guarantee that exfiltrated data is destroyed, that credentials are not reused, or that persistence is removed. The work of credential rotation, log review, and control hardening is the same either way.