Home / Critical Brief / No. 015

The GitHub Internal Repository Breach

A Poisoned VS Code Extension, Live for 18 Minutes, Exploited the Developer Trust Surface

Pillar 01 · Verifiable Origin Code Provenance Identity & Auth
Incident date
2026-05-18
Published
2026-05-31
Authors
Lemma Critical Team
Related Pack
Pack AIncident Response

TL;DR

In May 2026, the attack group TeamPCP listed a trojanized Nx Console VS Code extension on the official marketplace for just 18 minutes, exfiltrated credentials from GitHub employee endpoints that installed it, and cloned about 3,800 internal repositories. It sat there as a legitimate extension and passed the trust signals of signing and listing, so there was no way to tell it apart before install — a trusted distribution path does not guarantee an untampered build output. Detection and pre-execution attestation are complements, not substitutes.

Incident Overview

  • Affected: GitHub (its own internal repositories)
  • Attacker: TeamPCP (also tracked as UNC6780), a supply-chain attack group targeting open-source security utilities and AI middleware
  • Entry point: a trojanized version (v18.95.0) of the legitimate Nx Console extension (nrwl.angular-console). The malicious version was live on the VS Code Marketplace for approximately 18 minutes between 12:30 and 12:48 UTC on 2026-05-18
  • Exfiltration targets: 1Password vaults, Anthropic Claude Code settings, and npm / GitHub / AWS credentials / access tokens, all extracted from local IDE environments
  • Impact: approximately 3,800 GitHub internal repositories cloned and exfiltrated. The data was posted for sale on criminal forums for over $50,000
  • Scope (per GitHub): customer repositories, Enterprise accounts, and user data unaffected. Exfiltration limited to GitHub internal repositories, with the ~3,800-count claim consistent with the investigation
  • Detection and response: GitHub detected the intrusion on 2026-05-19, immediately initiated IR and rotated critical secrets. On 2026-05-26, released GHES 3.20.3 with a precautionary signing-key rotation
  • Adjacent activity: TeamPCP also compromised Aqua Trivy, Checkmarx KICS, LiteLLM, Telnyx SDK, TanStack (Brief 014), and Mistral AI. Same actor as Brief 014, part of one developer-trust-surface campaign
  • Core: the trust signals of legitimate-marketplace listing and signing did not guarantee artifact integrity, so a poisoned extension reached straight into the local secrets of the developer environment

Timeline

  • 2026-05-18 12:30–12:48 UTC: trojanized Nx Console v18.95.0 listed on the VS Code Marketplace (~18 minutes). Employee endpoints are compromised during this window and credentials exfiltrated
  • 2026-05-18 onward: exfiltrated credentials are used to clone approximately 3,800 GitHub internal repositories
  • 2026-05-19: GitHub detects the unauthorized access, opens IR, and rotates critical secrets the same day
  • 2026-05-20 around: GitHub publicly states it “detected and contained an employee-endpoint compromise via a malicious VS Code extension.” TeamPCP posts the internal repository data for sale on the dark web / criminal forums (over $50,000)
  • 2026-05-26: GHES 3.20.3 released, precautionary signing-key rotation

Note: proper nouns and CVE identifiers are based on primary sources (research labs, the GitHub Advisory Database, NVD, and the like); each implementation’s remediation status varies over time, so consult the latest information.

Attack Vector

  1. Poison the trust surface: publish a trojanized version of the legitimate Nx Console extension to the VS Code Marketplace, exploiting the everyday trust developers place in the marketplace and the extension itself
  2. Short listing window: keep the malicious version live for only ~18 minutes, creating a window that review / takedown is unlikely to catch
  3. Local-environment credential exfiltration: from the IDE local environment, collect 1Password vaults, Claude Code settings, and npm / GitHub / AWS credentials / tokens. Extensions have broad access to local secrets inside the IDE by design
  4. Lateral movement: use the exfiltrated GitHub credentials to access internal repositories
  5. Mass cloning: clone and exfiltrate approximately 3,800 GitHub internal repositories
  6. Monetization: post the exfiltrated data for sale on criminal forums for over $50,000

Structural Argument

The incident belongs to the code-provenance category of Pillar 01 (Verifiable Origin). The central failure primitive is “the legitimate-marketplace listing and distribution path for a developer tool (an IDE extension) functioned as a trust premise without guaranteeing that this extension version is a safe, intended artifact.” That extensions have broad access to local secrets inside the IDE turned the breach directly into credential exfiltration. identity-auth (lateral movement using exfiltrated GitHub credentials) is noted as a secondary category.

This sits alongside Brief 014 (the TanStack OIDC trusted-publisher compromise) as the same actor’s (TeamPCP) developer-trust-surface campaign — the two should be read together. Brief 014 is a hijack of the package-publishing path (the OIDC identity); this incident is abuse of an IDE extension as a distribution path. Both share the structure that “the distribution and publishing paths developers trust are decoupled from any layer that independently verifies artifact integrity.” It is also adjacent to Brief 004 (Megalodon, falsifying commit author origins) and Brief 010 (Claude Code impersonation, abusing a brand trust signal).

The detection–proof gap

GitHub detected on the following day and moved that same day to IR and secret rotation, identifying the scope (internal repositories only; no customer impact) and publishing it. The detection / containment layer is indispensable for scoping and bounding impact, and this Brief does not deny that role.

But detection does not change “which extension version the receiver accepts and installs” or “how broadly an installed extension can reach local secrets.” The malicious version was listed in the legitimate marketplace as a legitimate extension and passed through trust signals — listing and signing. The 18-minute listing window let installations complete before review and takedown caught up. Worse, many of the exfiltrated credentials were reusable static tokens — once pulled from the endpoint, they could be replayed from a different environment. For regulatory reporting and audit, a marketplace listing or a signature alone is not an independent evidentiary trail that “this extension was a legitimate, untampered artifact.”

Pre-execution attestation changes the structure in two directions: (1) attach an independently verifiable build-provenance proof — “produced from a legitimate origin and build path” — to the extension or tool artifact, and verify it on the receiving side before installation; (2) replace developer-environment authentication with key-less proofs that leave no reusable static tokens on the endpoint. The first rejects the trojanized version on proof inconsistency at install time rather than after the fact; the second makes “credentials” exfiltrated from an endpoint non-replayable from another environment. Detection (post-hoc extension takedown, IR) and pre-execution attestation (artifact provenance + key-less authentication) are complementary rather than substitutes.

For the detection-vs-attestation thesis, see “The last layer left for cyber defense in the age of AI” (Lemma, 2026-05); for verifying before the action, see “Proof-as-Auth: sign in without ever sending your key” (Lemma, 2026-05).

Response and Industry Response

  • GitHub: detection and IR on 2026-05-19, critical secrets rotated same day. Stated that exfiltration was limited to internal repositories with no customer impact. On 2026-05-26, GHES 3.20.3 released with a precautionary signing-key rotation
  • VS Code / extensions ecosystem: marketplace listing review / takedown processes, and the access scope extensions have to local IDE secrets, surfaced as topics. Organizational extension-installation policies emerge as an urgent gap
  • Cross-industry framing: part of TeamPCP’s wider developer-trust-surface campaign (Aqua Trivy, Checkmarx KICS, LiteLLM, Telnyx SDK, TanStack, Mistral AI, and others). With attacks on developer infrastructure itself concentrated in 2026, “compromise-assumed” management of developer-environment secrets (minimizing static tokens) and artifact-provenance verification surface as shared agenda items

How distribution and publishing paths that developers trust (extensions, packages, brands) guarantee artifact integrity is the open question moving forward.

Lemma’s Analysis

Against the detection–proof gap exposed here (the legitimate distribution path for developer tools does not guarantee artifact integrity, and reusable tokens on the endpoint are exfiltrated and replayed), Lemma proposes a two-direction design.

  • Artifact-provenance proof: fix “produced from a legitimate origin and build path” to extensions and tool artifacts as an independently verifiable build-provenance cryptographic proof.
  • Rejection before execution: the receiver verifies the proof before execution and can reject a trojanized version listed in the legitimate marketplace regardless of signature.
  • Key-less authentication: replace developer-environment authentication with key-less proofs that leave no reusable static tokens on the endpoint.
  • Non-replayability: credentials exfiltrated from an endpoint cannot be replayed from another environment.

Lemma does not substitute for marketplace review or detection; it provides a complementary layer of artifact-provenance proof and key-less authentication alongside the distribution-path trust signals.

For the design and its scope, see Pillar 01 — Verifiable Origin and Trust402.

Sources

About distribution

This material is a structured analysis of public information; it is not an audit, diagnosis, or recommendation for any specific organization.

(c) 2026 FRAME00, INC. — Built for decisions that matter.

Related Briefs
See all 13 in Code Provenance
No. 048 · 2026-06-12

TrapDoor Plants Hidden Directives in AI Assistant Instruction Files Across npm, PyPI, and Crates.io

TrapDoor, disclosed by Socket, is a credential-stealing campaign whose distinctive technique plants invisible directives…

Code Provenance Agent InfrastructureAI Decision Integrity
Brief →
No. 038 · 2026-06-09

IronWorm

When Stolen Credentials Become Publishing Authority (npm Self-Propagating Implant)

Code Provenance Identity & Auth
Brief →
No. 030 · 2026-06-06

Stripe's Trusted API Infrastructure Repurposed to Deliver Card-Skimming Code and Store Stolen Data

Allowlists Trust the Domain's Identity, Not the Provenance of What It Carries

Code Provenance Identity & AuthData Provenance
Brief →
Citation

Cite this Brief

Lemma Critical Team. (2026).
"The GitHub Internal Repository Breach — A Poisoned VS Code Extension, Live for 18 Minutes, Exploited the Developer Trust Surface".
Lemma Critical Brief No.015. Lemma / FRAME00, Inc.
https://lemma.frame00.com/critical/briefs/015-github-vscode-extension-breach/