GitHub's 3,800-Repo Breach: How a Poisoned VS Code Extension Burned the World's Biggest Code Host

TL;DR

On May 19, 2026, GitHub detected and contained the compromise of an employee device involving a poisoned VS Code extension, leading to the exfiltration of roughly 3,800 internal repositories covering GitHub Actions, Copilot internals, CodeQL, Codespaces, Dependabot, and infrastructure code. The attacker, a financially motivated supply chain crew called TeamPCP (tracked by Google Threat Intelligence Group as UNC6780), now lists the stolen archive for sale jointly with LAPSUS$ at $95,000. GitHub has rotated critical secrets and reports no evidence of impact to customer data outside its internal repos.

What Happened in the GitHub Breach

GitHub disclosed the incident on May 20, 2026, one day after detection. In a statement posted to X and echoed across press coverage, the company said it had "detected and contained a compromise of an employee device involving a poisoned VS Code extension," removed the malicious extension, isolated the endpoint, rotated high-impact credentials, and begun forensic analysis.

The threat actor, posting under the handle TeamPCP, claimed roughly 4,000 repositories. GitHub described that figure as "directionally consistent" with its own count of approximately 3,800 internal repositories. The company assessed that "the activity involved exfiltration of GitHub-internal repositories only," with "no evidence of impact to customer information stored outside of GitHub's internal repositories."

A separate forum post seen by Help Net Security lists the dataset starting at $50,000 from TeamPCP alone, with a joint TeamPCP + LAPSUS$ listing at $95,000. TeamPCP appended its usual line: "As always, this is not a ransom...if no buyer is found, we leak it for free."

The content categories reportedly included GitHub Actions, agentic workflows, internal Copilot projects, CodeQL tooling, infrastructure code, security tools, Codespaces components, and parts of the Dependabot pipeline. Even on the conservative read, that is a serious blast radius. Internal CI/CD code, SAST tooling, and Copilot pipeline source are exactly the surfaces an attacker would mine for new zero-days, secret-scanner bypasses, and weak points in the supply chain that protects half the open source ecosystem.

The Attacker: TeamPCP (UNC6780)

Google Threat Intelligence Group tracks the actor as UNC6780. On forums and in their own messaging they go by TeamPCP. Their specialty is software supply chain attacks on developer tooling and AI middleware.

Their 2026 hit list, as documented by Google, Wiz Research, and independent investigators, includes:

• Aqua Security's Trivy vulnerability scanner
• Checkmarx's KICS infrastructure-as-code scanner
• LiteLLM library
• Telnyx SDK
• TanStack packages (May 11, 2026)
• MistralAI packages
• Bitwarden CLI (April 23, 2026, downstream hijack via stolen KICS npm tokens)
• @antv npm namespace (~558 malicious versions across ~279 packages, broader wave totals ~639 versions across ~323 packages, May 19, 2026)
• nrwl.angular-console (Nx Console) v18.95.0 on the VS Code Marketplace (May 18, 2026)

That is not a list of random victims. The group consistently targets the tools that auditors, security engineers, and platform teams trust by default. The trust-the-tool axis is the entire thesis of the crew.

The joint listing with LAPSUS$ on the GitHub data is itself notable. LAPSUS$ has historically been a separate cluster known for social engineering of help desks and identity providers. A joint sale suggests either operational overlap or simple market efficiency: one group has the access, the other has the audience.

The Weapon: Mini Shai-Hulud

TeamPCP's main delivery mechanism in 2026 has been a self-propagating supply chain worm the group calls Mini Shai-Hulud — the same worm we broke down end-to-end in the TanStack npm compromise, derived in concept from the older Shai-Hulud npm worm. TeamPCP released the worm's source code publicly on GitHub under an MIT license, which is doing exactly what you would expect: accelerating copycat campaigns.

Mini Shai-Hulud's recipe across recent incidents:

1. Acquire a publishing identity. Either steal an npm token, a VSCE_PAT for the VS Code Marketplace, or abuse an OIDC trusted-publishing flow.
2. Inject a small loader. In the Nx Console case, 2,777 bytes of JavaScript appended to the minified main.js of a published package version.
3. Fetch the real payload from a dangling commit. The loader runs something like npx -y github:nrwl/nx#558b09d7ad0d1660e2a0fb8a06da81a6f42e06d2, pulling a ~498 KB obfuscated Bun/JavaScript dropper from an orphan commit so it never appears in the public git tree.
4. Harvest everything in reach. Vault tokens, K8s service account paths, npm tokens, AWS IMDS/ECS metadata, GitHub Actions runner memory (scraping isSecret:true values from Runner.Worker), SSH keys, Docker config, 1Password via the op CLI, and Claude Code config files.
5. Exfiltrate over multiple channels. AES-256-GCM + RSA-OAEP (SHA-256, 4096-bit) encrypted blobs sent over HTTPS to a C2 with a PBKDF2-SHA256 (200,000 iteration) derived domain, with a GitHub API dead-drop as fallback and DNS tunneling as a last resort.
6. Persist. Drop a Python backdoor at ~/.local/share/kitty/cat.py, register a macOS LaunchAgent (or systemd user service on Linux) to fire hourly, and poll GitHub's Search API for commits containing the trigger string firedalazer to receive new RSA-PSS-signed commands.
7. Propagate. Once new npm or marketplace credentials are stolen, publish the next round of poisoned packages and start the cycle again.

The Nx Console version of step 2 went live on May 18, 2026 and was caught in roughly 11 minutes (some sources widen the public window to ~18 minutes). The auto-update population for an extension with ~2.2 million installs inside that window is the worst-case end of the bell curve.

GitHub has not publicly confirmed which extension was running on the compromised employee's device. Several researchers, including Phoenix Security, assess that the Nx Console poisoning was the likely vector given timing and TeamPCP's claim of both incidents, though that attribution is inferential and has not been validated by GitHub.

Why Are VS Code Extensions Such a Soft Target?

Security researcher Charlie Eriksen put it bluntly in Help Net Security's reporting:

"VS Code extensions have full access to everything on the developer's machine, including credentials, cloud keys, and SSH keys."

That is the design, not a bug. The VS Code extension API exposes the file system, child processes, environment variables, and network. Most developers install dozens of extensions and never read a single one's source. Auto-update is on by default. There is no per-extension sandbox in stock VS Code. Marketplace verification confirms identity, not behavior. Once a publisher account is compromised, every existing install becomes a latent payload.

This is the same trust shape that has been chewing on the npm and PyPI ecosystems for years. It took longer to hit the IDE layer because the marketplaces were smaller targets.

The defensive surface developers do control:

• Disable auto-update for extensions that touch credentials or run code on workspace open (extensions.autoUpdate: false).
• Set task.allowAutomaticTasks: "off" so extensions cannot silently fire shell tasks on workspace activation.
• Set npm.scriptExplorerExclude and ignore-scripts=true in CI npm configurations.
• Run editors inside dev containers or remote workspaces so blast radius is bounded.
• Use a centralized extension allowlist in enterprise environments instead of letting individual developers install at will.

None of these are exotic. The reason they are not the default is that they make the day-one experience slightly worse for the 99% of developers who will never be targeted. The targeted 1% have to wear the cost.

What Was Actually in Those 3,800 Repos?

GitHub has not published a complete inventory. Based on what TeamPCP described and what reporters from TechCrunch and others have summarized, the affected surface includes:

Source code on its own is not a credential. But source code with embedded constants, comments referencing internal hostnames, secret-scanner regex patterns, and any leftover test fixtures with real tokens is a research goldmine. GitHub's statement that "critical secrets were rotated yesterday and overnight with the highest-impact credentials prioritized first" suggests they found enough live secrets in the exfiltrated repos to make rotation a same-day priority.

This is the unspoken half of every internal source code leak. The official line is always "no customer data was accessed." The operational reality is "we are now rotating every secret that touched any of those repos and praying we get to all of them before the buyer does."

Why Is This Especially Bad for Crypto and Web3 Developers?

Within hours of disclosure, Binance founder Changpeng Zhao (CZ) warned developers on X:

"If you have API keys in your code, even private repos, now is the time to double check and change them."

CZ was speaking to a specific audience for a specific reason. Crypto and web3 developers store far more dangerous things in private repos than most:

• Exchange API keys with trading and sometimes withdrawal permissions
• Hot wallet mnemonics for trading bots and market makers
• Validator signing keys and beacon chain credentials
• Node operator keys for Solana RPCs, Ethereum execution clients, Cosmos validators
• Multisig signer private keys for deployer or upgrader accounts
• Hardhat/Foundry deployment keys with permission to upgrade live protocol contracts
• Bridge relayer keys that move funds across chains
• Oracle reporter keys that push prices to billion-dollar lending markets

A leaked Solidity test file containing a real deployer mnemonic on a live network can drain a treasury or upgrade a proxy to a malicious implementation in one transaction. A leaked validator key triggers slashing. A leaked oracle key can be used to print arbitrary prices into a money market. None of these threats require a smart contract bug. They require a developer who at some point committed something they should not have, on the assumption that "it is a private repo, nobody will see it." This is the same blast-radius problem we covered in Copy Fail (CVE-2026-31431) — different bug class, identical outcome once root or repo access lands on the wrong machine.

GitHub's secret scanner catches many of these patterns on push. It does not catch everything. It cannot catch obfuscated keys, base64-wrapped seeds, or test fixtures named in ways the scanner does not recognize. And the scanner runs against your repos, not against the attacker's offline copy.

Was Source Code Ever the Real Security Boundary?

The recurring industry mistake is treating the privacy of source code as part of the security architecture. It is not. Source code routinely leaks. It leaks through:

• Compromised developer devices, as in this case — and as in every major Web3 social-engineering incident of the last two years
• Stolen access tokens, as in the Okta source code theft via stolen GitHub credentials in December 2022
• Misconfigured cloud buckets holding code archives or backups
• Acquired companies with weaker hygiene than the parent
• Disgruntled employees
• Subpoena, discovery, or government compulsion
• Third-party platform breaches, as in the October 2025 Crimson Collective intrusion into a self-managed GitLab instance used by Red Hat Consulting, which exposed an estimated ~28,000 development repos and ~800 Customer Engagement Reports
• AI training pipelines that ingested supposedly private code by accident
• The next TeamPCP-class supply chain attack

If your code contains a long-lived credential, then your code is the credential. Every copy of it is a copy of the credential. The threat model has to assume the source code will eventually be read by someone you did not invite. The actual security boundary is whatever the code talks to: the IAM policy, the OIDC trust relationship, the on-chain access control, the network boundary.

What that looks like in practice for application developers:

1. No long-lived secrets in source. Ever. This includes .env files, config files, test fixtures, CI scripts, scratch branches, deleted-but-still-in-git-history blobs, Dockerfiles, and Terraform.

2. Use short-lived credentials with workload identity. For cloud: IAM Roles Anywhere, AWS STS, GCP Workload Identity, Azure Managed Identity. For CI/CD: GitHub Actions OIDC tokens with hardened trust policies, not stored secrets.

3. Centralize secret storage. Vault, AWS Secrets Manager, GCP Secret Manager, 1Password Connect. Fetch at runtime, never embed at build time. Audit every read.

4. Rotate aggressively and assume rotation will be needed. Build systems that survive a quarterly key rotation without human intervention. If rotation requires a deploy, the rotation will not happen.

5. Enable secret scanning and push protection. GitHub Advanced Security's push protection blocks pushes that contain detectable secrets. Treat alerts as incidents, not warnings.

6. Git-history scrub or rotate when a secret slips in. The standard mistake: someone commits a key, notices, deletes it in the next commit, and assumes the problem is solved. The secret is still in history. Rotate the secret. Do not rely on a git push --force.

For web3 developers specifically:

7. Hardware wallets for any key that controls value. Trezor, Ledger, Keystone, or a proper HSM. No private key for a live deployer or treasury account should ever exist in plaintext on a developer machine, let alone in a repo.

8. Multisig with a non-trivial threshold and a non-zero timelock. A single signer should not be able to upgrade a protocol or move a treasury. A timelock buys you the minutes it takes to notice and freeze.

9. Separate testnet and mainnet keys at the wallet level. A surprising number of incidents start with a developer who reused a testnet mnemonic on mainnet "just for one quick thing."

10. Continuous monitoring for privilege changes on deployed contracts. Audits validate the code on the day they finish. They do not catch a compromised deployer pushing a malicious upgrade six months later. Tooling that watches Upgraded, OwnershipTransferred, RoleGranted, and parameter-change events in real time closes that gap.

What Has GitHub Confirmed and What Has It Withheld?

What GitHub has confirmed:

• An employee device was compromised via a poisoned VS Code extension on May 19, 2026
• Roughly 3,800 internal repositories were exfiltrated
• The endpoint was isolated, the extension was removed, and critical secrets were rotated, prioritizing highest impact first
• "No evidence of impact to customer information stored outside of GitHub's internal repositories" as of May 20, 2026

What GitHub has not disclosed:

• The specific name of the malicious VS Code extension
• Which internal team or product area the affected employee worked on
• The complete list of affected repositories
• How long the attacker had access before detection (TeamPCP claimed "past few months" in the same forum post cited above)
• Whether any signing keys, Sigstore identities, or production deploy credentials were among the rotated secrets

Both lists will likely grow. Same-day disclosures are rarely complete. Watch for the post-mortem.

Closing

This breach is going to be quoted for years, not because it was technically novel (it was not), but because it hit the operator most developers trust the most, through a vector most developers do not think about, and ended with a familiar lesson nobody wants to internalize: if your secrets live in your source code, your security model is one bad day away from collapsing.

GitHub will recover. They have the resources, the talent, and the institutional incentive to rotate, harden, and publish a credible post-mortem. Most organizations do not. The right thing to do today is assume you are a smaller, slower version of GitHub. Pull your secrets out of source. Rotate the ones already there. Block the IoCs above. Lock down your extension surface. Then write the post-mortem you would want to read if it had been you.

If you operate on-chain and want continuous monitoring for compromised deployer keys, anomalous privilege changes, suspicious upgrade activity, or unexpected parameter writes, Tripwire tracks those patterns 24/7 and can fire circuit breakers before a single bad transaction lands. Audits prove the code was safe on the day they signed off. Tripwire proves the code is still safe right now, in production.

Sources

1. SecurityWeek, GitHub Confirms Hack Impacting 3,800 Internal Repositories
2. TechCrunch, GitHub Says Hackers Stole Data From Thousands of Internal Repositories
3. The Hacker News, GitHub Breached, Employee Device Hack Led to Exfiltration of 3,800+ Internal Repos
4. Help Net Security, TeamPCP Breached GitHub's Internal Codebase via Poisoned VS Code Extension
5. Wiz Research, The Worm That Keeps on Digging: TeamPCP Hits @antv in Latest Wave
6. Phoenix Security, GitHub Internal Repository Breach via Poisoned VS Code Extension (May 2026)
7. Aikido, GitHub Breached via VS Code Extension, Developer Supply Chain Attack 2026
8. MoneyCheck, GitHub Security Breach Exposes 3,800 Internal Repositories as CZ Warns Crypto Devs
9. Coinfomania, GitHub Confirms Breach of 3,800 Repos via Poisoned VS Code Extension
10. Hackread, GitHub Breach: TeamPCP Steals 3,800 Repositories via VS Code Extension
11. BleepingComputer, Okta's Source Code Stolen After GitHub Repositories Hacked
12. BleepingComputer, Red Hat Confirms Security Incident After Hackers Breach GitLab Instance
13. GitHub Docs, About Security Hardening With OpenID Connect
14. GitHub Docs, Push Protection for Repositories and Organizations