Third-Party Incident Briefing, Monthly Series
The Platform Beneath Your Vendors
June 2026
TeamPCP returns to our briefing, this time targeting GitHub itself. What the poisoned VS Code extension that breached the platform hosting the global software supply chain reveals about developer tooling, threat actor continuity, and the vendor sitting one layer beneath every other vendor in your stack.
Edition 03 | 10 min read | Supply Chain / Developer Tooling / TPRM
Repos Allegedly Taken
~3,800
Forum listing by TeamPCP, May 19. GitHub calls the figure directionally consistent.
Initial Vector
IDE Plugin
Poisoned VS Code extension on a single GitHub employee's device.
Same Actor as Edition 01
Yes
UNC6780
TeamPCP, tracked as UNC6780 by Google Threat Intelligence.
Coverbase Alert Time
6 min
From GitHub's public confirmation on May 19 to first customer notification.
Alert time measured from GitHub's public confirmation on May 19 to first customer notification.
A Developing Story
A Developing Story
GitHub publicly confirmed unauthorized access to internal repositories on May 19, 2026, with an updated incident response post the following morning. Details continue to emerge. This briefing reflects information available as of publication and the operational implications for vendor risk programs today, recognizing that the full scope of impact will not be known for weeks or months.
As ofMay 27, 2026
01 · The Vendor
Who is GitHub?
It isn't a vendor. It is the substrate the rest of your supply chain runs on top of.
GitHub is the dominant source code hosting and software collaboration platform globally. The service is operated 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 nearly every CI/CD pipeline, 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
420M
repositories hosted
Identity
150M
developers authenticated
Build & Ship
Every modern CI/CD pipeline
Every
Fig. 02 — GitHub's role in the stack
Why This Matters for TPRM
When the platform itself is breached, the question is no longer whether your direct vendors are safe. It is whether the substrate your direct vendors are built on can be trusted to deliver clean code tomorrow morning.
Concentration Risk
Coverbase Platform Data
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 the one inside 9 out of 10 of your peers' stacks.
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,000
starting
Repos Claimed
~4,000
internal
Listed On
BreachForums
May 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.
Fig. 03 — The developer endpoint as perimeter
Reconstructed 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, which is exactly why the vector is so effective.
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
Wiz quantified the underlying exposure at the time, sitting 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.
The vendor your program is least prepared for is the one inside 9 out of 10 of your peers' stacks.
Anatomy of the Vector
From IDE startup to internal infrastructure.
Background activation on IDE startup
Fires silently when VS Code launches — no prompt, no review.
Scans high-value credential locations
Git credential stores, gitconfig, env vars, SSH sockets, OAuth tokens.
Exfiltrates over HTTPS
Indistinguishable from routine extension telemetry to most DLP tooling.
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
Early 2026
Edition 01 Campaign
TeamPCP begins a sustained supply chain campaign, hitting Trivy, LiteLLM, and Checkmarx in succession.
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.
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.
May 13
Worm Source Released
TeamPCP releases the Shai-Hulud worm source on GitHub and launches a $1,000 Monero supply chain attack contest on BreachForums.
May 19
The Disclosure
TeamPCP posts claiming access to ~4,000 internal GitHub repositories. GitHub publicly confirms unauthorized access to internal repositories.
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.
03 · Key Dates
Six months of escalation,
compressed into one chart.
Prior campaign
Worm escalation
Update
Early 2026
Edition 01 Campaign
TeamPCP begins a sustained supply chain campaign, hitting Trivy, LiteLLM, and Checkmarx in succession. Covered in Edition 01 of this series.
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.
May 11
Mini Shai-Hulud
Mini Shai-Hulud worm campaign hits 170 plus npm and PyPI packages including TanStack, Mistral AI, UiPath, OpenSearch, and SAP CAP projects. Two OpenAI employee devices confirmed compromised.
May 13
Worm Source Released
TeamPCP releases the Shai-Hulud worm source code on GitHub and launches a $1,000 Monero supply chain attack contest on BreachForums.
May 19
The Disclosure
TeamPCP posts on an underground forum claiming access to approximately 4,000 internal GitHub repositories. GitHub publicly confirms unauthorized access to internal repositories.
May 20
Technical Update
GitHub publishes a technical incident response update on X 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.
Date
Target
Vector
Downstream Impact
Early 2026
Trivy
Aqua Security
Cascaded to Aqua Docker images and Checkmarx KICS.
Early 2026
LiteLLM
Tens of thousands of devices infected with TeamPCP Cloud Stealer.
Q1 2026
Checkmarx (1st)
Harvested CI/CD secrets across customer base.
April 2026
Checkmarx (2nd)
Backdoored plugin v2026.5.09; repo defaced.
April 2026
Bitwarden
npm Trusted Publishing token leaked in build log.
May 11, 2026
Mini Shai-Hulud campaign
170+ packages compromised across TanStack, Mistral, OpenAI.
May 19, 2026
GitHub
The Platform
~3,800 internal repositories exfiltrated, listed for sale.
Trivy
Aqua Security
Early 2026
Cascaded to Aqua Docker images and Checkmarx KICS.
LiteLLM
Early 2026
Tens of thousands of devices infected with TeamPCP Cloud Stealer.
Checkmarx (1st)
Q1 2026
Harvested CI/CD secrets across customer base.
Checkmarx (2nd)
April 2026
Backdoored plugin v2026.5.09; repo defaced.
Bitwarden
April 2026
npm Trusted Publishing token leaked in build log.
Mini Shai-Hulud campaign
May 11, 2026
170+ packages compromised across TanStack, Mistral, OpenAI.
GitHub
The Platform
May 19, 2026
~3,800 internal repositories exfiltrated, 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 that figure 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 it, internal source code, infrastructure diagrams, deployment logic, and historical secrets sit in the hands of a financially motivated actor with a proven track record of using stolen artifacts for follow-on attacks. 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 that came from this breach. The risk is not that customer repositories were stolen on May 19. The risk is what attacks become possible in July, August, or November because attackers now understand GitHub’s infrastructure better than they did last week.
4th Party
Downstream consumers of open source code
The largest exposed population is not GitHub’s direct customer base. It is the global population of organizations that consume open source software hosted on GitHub, which is effectively every modern enterprise. The Mini Shai-Hulud campaign in early May demonstrated that TeamPCP can weaponize trust chains in npm and PyPI to compromise downstream users at scale. Internal GitHub knowledge makes the next iteration of that pattern faster, quieter, and harder to detect.
The Layer No One Tracks
The VS Code extension publisher
Not GitHub Enterprise. Not Microsoft. Not any vendor that appears on a typical TPRM inventory. The publisher would have been a name on the Marketplace, possibly a single individual, and almost certainly never assessed. This is the vendor layer that sits on every engineering endpoint at every company in the world, and it is currently outside the scope of nearly every vendor risk program.
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 — effectively every modern enterprise. 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.
Operational Checklist
Audit third-party VS Code & IDE extensions across engineering.
Rotate broad-scope GitHub PATs, prioritizing CI/CD.
Pin GitHub Actions to commit SHA, not version tag.
Re-examine GitHub Apps & OAuth integrations with elevated scopes.
Treat next 90-180 days of GitHub-adjacent activity as elevated risk.
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.
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.
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.
The Bottom Line
This is the second briefing in a row to feature TeamPCP. That continuity is the story. A financially motivated threat actor with a documented supply chain methodology has spent the last six months walking up the stack, from security scanners to AI infrastructure to dependency managers to the platform hosting all of them, and the public reporting on each step has consistently treated the previous step as an isolated incident. It was not isolated then, and the GitHub breach is not isolated now.
The question every TPRM program should be asking is not whether GitHub was breached. It is whether the program has a category for the relationship between threat actor and portfolio. Without that category, every campaign in this series will continue to look like surprise. With it, the next one starts to look like a forecast.
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.
Stage 01
Q1 2026·Before the breachBefore 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.
Stage 02
May 11-13, 2026·Shai-Hulud campaignShai-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.
Stage 03
May 19, 2026·Within 6 minutesWithin 6 minutes
Disclosurecustomer alert in under 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 is measured in 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.
Stage 04
May 20, 2026·Technical updateTechnical 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.
Stage 05
90-day window·OngoingOngoing
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.
Third-Party Incident Briefing, A Monthly Analysis Series
Each edition examines a real-world incident through the lens of third-party risk: what happened, who was affected, and what it means for how we monitor vendor relationships.