Skip to content
ReportThe 2026 State of TPRMDownload
Third-party incident briefing: a monthly analysis series

The platform beneath your vendors

June 2026Edition 02 | 10 min read | Supply chain / Developer tooling / TPRM
TeamPCP returns to our briefing, this time targeting GitHub itself. This edition examines what the poisoned VS Code extension behind the GitHub breach reveals about developer tooling, threat actor continuity, and the vendor one layer beneath every other vendor in your stack.
Mobile attack chain reconstruction for the GitHub incident
01 · Overview
Repos claimed
~4,000TeamPCP forum listing, May 19. GitHub called a ~3,800 figure directionally consistent with its investigation.
Initial vector
IDE pluginPoisoned VS Code extension on a single GitHub employee's device.
Same actor as Edition 01
YesUNC6780TeamPCP, tracked as UNC6780 by Google Threat Intelligence.
Coverbase alert time
6 minFrom GitHub's public confirmation on May 19 to first customer notification.
01 · The vendor
Who is GitHub?

It isn't a vendor. It is the platform the rest of your supply chain runs on.

GitHub is the dominant source code hosting and software collaboration platform globally. GitHub is owned by Microsoft and hosts more than 420 million repositories used by over 150 million developers. It functions as the source of truth for code in the majority of modern engineering organizations, a critical link in most modern CI/CD pipelines, and the upstream for most of the world's open source software.

In a typical TPRM program, GitHub shows up in the vendor inventory as a foundational, low-friction entry. The security questionnaire goes light. The SOC 2 is on file. Nobody questions whether the company should be using it. That posture is reasonable in most months. It is not reasonable in months like this one.

Source of truth
420Mrepositories hosted
Identity
150Mdeveloper accounts
Build and ship
Mostmodern CI/CD pipelines
Fig. 01 · GitHub's role in the stack
Coverbase platform data

89.3%

of Coverbase customers have GitHub in their vendor inventory. More than any other vendor on the platform.

The gap

GitHub also shows the largest measured gap between assessment depth and integration footprint across our customer base.

The typical posture is a SOC 2 report on file and nothing else, while GitHub holds the customer's source code, authenticates their CI/CD, mediates their SSO, and ships the open source dependencies they ultimately deploy.

The vendor your program is least prepared for is in nearly 9 out of 10 Coverbase customer inventories.

02 · What happened

A poisoned editor extension on a single GitHub employee's laptop became a path into the platform's internal repositories.

On May 19, 2026, the threat group TeamPCP, tracked by Google Threat Intelligence as UNC6780, posted on an underground forum claiming to have stolen approximately 4,000 internal GitHub repositories.

The group framed the listing as a direct data sale rather than a ransomware extortion, with a starting price around $50,000 to a single buyer and contact details for verification samples. They explicitly warned that if no buyer materialized, the data would be leaked publicly.

Later the same day, GitHub publicly confirmed an investigation was underway. The company stated it had no evidence that customer enterprises, organizations, or repositories were affected, but said it was actively monitoring for follow-on activity. On May 20, GitHub published a technical update describing its incident response: the infected employee device had been isolated, the malicious VS Code extension version had been removed, and the company had spent the night rotating high-impact credentials and cryptographic keys.

Listing price
$50,000starting
Repos claimed
~4,000internal
Listed on
BreachForumsMay 19, 2026 · 14:22 UTC

The initial vector is the part of the story that matters most for TPRM. The attacker did not exploit a zero-day in GitHub's infrastructure or brute force a credential. They poisoned a VS Code extension that an employee installed, and rode that legitimate developer tool into the corporate environment. This is the same pattern TeamPCP has used throughout 2026, where the initial access is not a sophisticated platform exploit but a low-visibility, high-trust developer tool that no security questionnaire has ever asked about.

Mobile developer endpoint diagram showing poisoned extension behavior
Fig. 02 · The developer endpoint as perimeterReconstructed from public IR notes and Wiz Research disclosures.

It helps to understand why this vector is so effective. VS Code extensions are not sandboxed browser plugins. They run as Node.js processes with full access to the host machine: the local filesystem, environment variables, the ability to spawn child processes, and the ability to make outbound network requests.

An extension can read anything the user who installed it can read. The likely mechanism in this attack was a background activation event that fired on IDE startup, scanned common credential locations (Git credential stores, the user's gitconfig, environment variables loaded into the shell, SSH agent sockets, in-memory OAuth tokens cached by GitHub CLI or browser sessions), and exfiltrated whatever it found over HTTPS to an attacker-controlled endpoint. To most DLP tooling, that outbound traffic is indistinguishable from routine extension telemetry.

This is also why the Wiz Research finding from October 2025 matters operationally. When publishing tokens are leaked inside extensions, an attacker who recovers a token can push a malicious update to the entire installed base of that extension silently. The update arrives as a routine VS Code Marketplace sync. No user prompt. No review. The developer never installed anything suspicious. The extension they had trusted for months simply updated itself.

The outcome

At the time, Wiz found the exposure spread across more than 500 extensions from hundreds of publishers. TeamPCP appears to have weaponized it. The result, in GitHub's case, was a single employee's IDE session becoming an authenticated path into internal systems, almost certainly via a credential or token scoped to internal infrastructure.

Anatomy of the vector

From IDE startup to internal infrastructure.

  1. 01

    Background activation on IDE startup

    Fires silently when VS Code launches, with no prompt and no review.

  2. 02

    Scans high-value credential locations

    Git credential stores, gitconfig, env vars, SSH sockets, OAuth tokens.

  3. 03

    Exfiltrates over HTTPS

    Indistinguishable from routine extension telemetry to most DLP tooling.

  4. 04

    Pivots into internal infrastructure

    Authenticates as the employee with a token scoped to internal systems.

Wiz Research · Oct 2025

The marketplace has been a viable attack surface for months.

100+
leaked VS Code Marketplace PATs
30+
Open VSX publishing tokens
500+
extensions, hundreds of publishers
03 · Key dates

Six months of escalation, compressed into one chart.

  • Prior campaign
  • Worm escalation
  • The disclosure

  1. Early 2026

    Edition 01 campaign

    TeamPCP begins a sustained supply chain campaign, hitting Trivy, LiteLLM, and Checkmarx in succession.

  2. April 2026

    Bitwarden CLI

    TeamPCP compromises the Bitwarden CLI publishing workflow through a poisoned GitHub OIDC pull request, leaking a short-lived npm Trusted Publishing token in a build log.

  3. May 11

    Mini Shai-Hulud

    Worm campaign hits 170+ npm and PyPI packages including TanStack, Mistral AI, UiPath, and SAP CAP. Two OpenAI employee devices confirmed compromised.

  4. May 13

    Worm source released

    TeamPCP releases the Mini Shai-Hulud worm source on GitHub and launches a $1,000 Monero supply chain attack contest on BreachForums.

  5. May 19

    The Disclosure

    TeamPCP posts claiming access to ~4,000 internal GitHub repositories. GitHub publicly confirms unauthorized access to internal repositories.

  6. May 20

    Technical update

    GitHub publishes a technical incident response update confirming the poisoned VS Code extension vector, device isolation, and rotation of high-impact credentials.

04 · The pattern

The same actor from Edition 01, now targeting the platform every vendor is built on.

If you read Edition 01, you already know TeamPCP. The actor who compromised Trivy, LiteLLM, and Checkmarx earlier this year is the same actor in headlines today. The escalation across 2026 is the part most coverage misses and the part that matters most for a vendor risk program.

  1. Trivy

    Aqua Security

    Early 2026

    GitHub Actions

    Cascaded to Aqua Docker images and Checkmarx KICS.

  2. LiteLLM

    Early 2026

    PyPI package

    Tens of thousands of devices infected with TeamPCP Cloud Stealer.

  3. Checkmarx (1st)

    Q1 2026

    GitHub Actions · Open VSX

    Harvested CI/CD secrets across customer base.

  4. Checkmarx (2nd)

    April 2026

    Jenkins AST plugin

    Backdoored plugin v2026.5.09; repo defaced.

  5. Bitwarden

    April 2026

    GitHub OIDC workflow

    npm Trusted Publishing token leaked in build log.

  6. Mini Shai-Hulud campaign

    May 11, 2026

    npm + PyPI worms

    170+ packages compromised, including TanStack and Mistral AI. Two OpenAI employee devices affected.

  7. GitHub

    The Platform

    May 19, 2026

    VS Code extension

    ~3,800 internal repositories claimed stolen, listed for sale.

Each compromise produced reconnaissance, credentials, or tooling that fed into the next. The progression from security scanner, to AI infrastructure, to dependency manager, to the platform hosting all of them is not coincidence. It is a portfolio.

05 · Scope of impact

The headline numbers are still in flux. The downstream questions aren't.

GitHub has called the attacker's figure of roughly 3,800 repositories directionally consistent with its investigation. The company also states that customer enterprises, organizations, and repositories were not directly accessed. Both can be true. For TPRM purposes, the interesting question is what "not directly accessed" means for your downstream exposure.

Nth-party ripple effects

  • The Compromised Vendor

    GitHub itself

    Faces a window of unknown length during which internal source code, infrastructure diagrams, deployment logic, and historical secrets sit in the hands of a financially motivated actor. Even with secrets rotated, the structural intelligence value of internal repositories does not expire.

  • 3rd Party

    Every organization using GitHub

    Every enterprise running GitHub Actions, every team using GitHub Apps for SSO and code review, every CI/CD pipeline authenticated to GitHub now needs to consider whether the next round of TeamPCP campaigns is being prepared with intelligence from this breach.

  • 4th Party

    Downstream consumers of open source

    The largest exposed population is the global population of organizations that consume open source software hosted on GitHub, which includes most modern enterprises. Internal GitHub knowledge makes the next Shai-Hulud iteration faster, quieter, and harder to detect.

  • The Layer No One Tracks

    The VS Code extension publisher

    Not GitHub Enterprise. Not Microsoft. Not any vendor on a typical TPRM inventory. The publisher would have been a name on the Marketplace, possibly a single individual, almost certainly never assessed. This is the vendor layer on every engineering endpoint at every company in the world.

06 · Remediation

GitHub's public response so far has been notably fast.

The device was isolated, the extension removed, high-impact credentials and cryptographic keys rotated, and a public commitment made to publish a fuller incident report. Compared to past editions, the speed and transparency here are above industry baseline.

For customers, the operational guidance is more nuanced than a typical breach response because no specific customer data has been confirmed compromised. The right posture is precautionary rather than reactive.

Review GitHub Actions workflows for any third-party actions referenced by version tag rather than commit SHA. Re-examine any GitHub Apps or OAuth integrations with elevated scopes. Treat the next 90 to 180 days of GitHub-adjacent activity, including unexpected commits, branch creation, or workflow modifications, as elevated risk.

08 · The root-cause lesson

The breach was not caused by a failure of GitHub's security program. It was caused by a feature of the modern developer ecosystem: every engineering organization in the world runs trusted third-party code on workstations that hold the keys to production.

The developer endpoint has become the perimeter, and the editor's plugin ecosystem is part of that perimeter.

07 · How could you have prepared?

Three program-level shifts that would have raised your posture before May 19.

Each play below maps to one structural blind spot in the way most TPRM programs are wired today. Read them as a 90-day reset, not a checklist.

01

Threat-Actor Lens

Track threat actors as a portfolio-level signal, not just vendors.

Most TPRM programs treat each vendor breach as a discrete event. They are not. TeamPCP has been escalating through the supply chain ecosystem for the entirety of 2026, and every prior compromise in this campaign should have raised the risk posture on every vendor in the same neighborhood. If your program flagged Trivy, LiteLLM, and Checkmarx as known TeamPCP targets in Q1, your team would have been monitoring for follow-on activity well before May 19.

A useful internal rule: when a financially motivated actor with a proven supply chain methodology compromises three or more vendors in a 12-month window, every vendor sitting in the same ecosystem layer (developer tooling, CI/CD, package registries, identity infrastructure) should carry an elevated flag and a more aggressive monitoring cadence. The actor is the relationship, not the vendor.

Diagram showing TeamPCP connected to multiple vendors in the same portfolio.

02

Endpoint Inventory

Inventory the developer tooling layer your program doesn't currently cover.

Ask a hard question: how many third-party VS Code extensions, JetBrains plugins, GitHub Apps, browser extensions, and CLI tools are installed on your engineering team's endpoints today, and who assessed them? In most organizations, the answer is hundreds of tools, assessed by no one. This is not a gap your team caused. It is a gap that did not exist as a category five years ago.

Closing it does not require assessing every extension to SOC 2 depth. It requires building an inventory, establishing a baseline for what is allowed, monitoring for unusual extension installs or updates, and treating extensions with publishing access to package registries (npm, PyPI, marketplace publishers) as the highest-priority tier. The TeamPCP campaigns are running through this layer because no one is watching it.

Sample endpoint inventory highlighting discovered developer extensions and risk tiers.

03

Concentration

Treat GitHub (and platforms like it) as concentrated infrastructure, not a routine vendor.

GitHub is in every modern enterprise vendor inventory, but the assessment depth almost never reflects the platform's actual role. The vendor questionnaire was designed for a world where GitHub was where you stored code. It is now where your build runs, where your SSO authenticates, where your packages publish, and where your customers consume the open source dependencies you ship.

Concentration risk is a useful frame here, but the more direct lesson is to put platforms that sit at this depth of the stack on a different operational track than typical SaaS vendors. That includes documented continuity plans for short-term GitHub disruption, audited inventories of GitHub Actions and Apps in use, periodic credential rotation on a schedule independent of incidents, and elevated monitoring for any TeamPCP-style indicators in your environment. If GitHub is the substrate, treat it like infrastructure, not like a tool.

Diagram showing GitHub's role across application, identity, build, and supply chain layers.
08 · What a monitoring program would have seen

A poisoned extension on a GitHub laptop was never going to be prevented by a vendor risk platform.

What a well-instrumented program can do is shorten the distance between the first detectable signal and a confident answer to the question every executive will ask in the next 24 hours: "what is our exposure?" The signals were available before May 19. Here is the sequence.

  1. Stage 01

    Q1 2026·Before the breach

    Portfolio-level actor tracking elevates the entire neighborhood.

    A program tracking TeamPCP as a portfolio-level threat actor, not just as a tag on individual vendor records, would have elevated every vendor in the developer tooling and CI/CD ecosystem after the Trivy, LiteLLM, and Checkmarx compromises. GitHub, as the platform underlying all of them, should have moved from routine monitoring cadence to elevated review during this window.

    The signal that mattered was the actor's methodology, not the specific vendor in the headline. By the end of Q1, the case for treating GitHub as a heightened-risk relationship was already complete on the evidence.

  2. Stage 02

    May 11 to 13, 2026·Mini Shai-Hulud campaign

    The clearest possible escalation signal before disclosure.

    The Mini Shai-Hulud worm hitting 170 plus npm and PyPI packages on May 11, followed by TeamPCP publishing the worm source code on May 13 and running a $1,000 supply chain attack contest on BreachForums, was the clearest possible escalation signal.

    A program ingesting threat intelligence at the actor level, not just the CVE level, would have flagged this as a high-probability precursor to a platform-level attack. GitHub, npm, and PyPI are structurally linked. An actor demonstrating capability against two of them in the same week is telegraphing the third. The right response in that window was not to wait for GitHub's disclosure post. It was to pre-stage incident response and customer communication artifacts for a GitHub event that had not yet happened.

  3. Stage 03

    May 19, 2026·Within 6 minutes

    From disclosure to customer alert within 6 minutes.

    GitHub's confirmation post appeared on the afternoon of May 19. Within 6 minutes, Coverbase customers with GitHub in their vendor inventory received an alert mapped to their specific exposure profile: which GitHub products they used (Enterprise Cloud, Actions, Apps, OAuth integrations, mirrored repositories), which data categories flowed through those integrations, and which immediate actions were recommended given that usage pattern.

    The industry average for a TPRM team to manually triage a major vendor breach and produce a usable exposure summary typically takes days. The 6-minute window is the difference between a coordinated response and a scramble. The mechanism is straightforward: the disclosure feed is ingested, the vendor record is matched against the customer's integration inventory, and the alert payload is generated from the intersection. The customer sees only what is relevant to their stack.

  4. Stage 04

    May 20, 2026·Technical update

    Exposure pictures update automatically as facts change.

    GitHub's follow-up post confirming the VS Code extension vector, device isolation, and credential rotation arrived the morning of May 20. This narrowed the confirmed attack vector from “unknown” to “VS Code extension on employee device.” Customer exposure profiles updated automatically against the structured incident feed. The scope tightened (no customer repositories directly accessed), the vector was confirmed (developer endpoint, not infrastructure exploit), and recommended actions adjusted accordingly (extension inventory, token rotation scoped to CI/CD Actions).

    Customers with no GitHub Actions usage and only basic OAuth integrations received a scope-narrowing update. Customers with broad GitHub Apps and Actions footprints received an escalated action list. The point of an automated update is not the automation. It is that the customer-facing exposure picture stays accurate as the underlying facts change, without a human in the loop having to re-read every status post.

  5. Stage 05

    90 to 180 days·Ongoing

    The threat-actor relationship does not expire when the credentials rotate.

    The breach did not end on May 20. TeamPCP now holds structural intelligence about GitHub's internal infrastructure: deployment logic, internal naming conventions, historical secrets, integration patterns. For the next 90 to 180 days, the right posture is to treat any anomalous GitHub Actions workflow behavior, unexpected commits, new OAuth application authorizations, or unusual branch creation patterns as elevated-risk signals, and to route them to the same response queue as the initial breach notification. The threat actor relationship with GitHub's environment does not expire when the credentials rotate. The monitoring posture should not expire either.

Ready for agentic third-party risk and security?

Book a demo