GitHub Lost 3,800 Internal Repos to a VS Code Extension. The DDQ Row Your Code-Hosting Vendor Has Not Answered Is About Their Developer Endpoints, Not Yours.
Two compromises in the same week followed the same channel. On May 18, the Nx Console VS Code extension shipped a malicious version that harvested developer secrets and exfiltrated them over multiple covert paths. Two days later, on May 20, GitHub confirmed that ~3,800 of its own internal repositories had been exfiltrated after one of its engineers installed a poisoned VS Code extension on a work device. The shared channel is the IDE marketplace, and the shared assumption that just broke is that vendor-side developer endpoints can stay out of customer procurement scope.
Nx Console, May 18
The compromised package was nrwl.angular-console version 18.95.0, a VS Code extension with roughly 2.2 million installs at the time of compromise. The malicious build lived in the marketplace for roughly eleven minutes before being pulled, but eleven minutes was the entire window required for harm. The payload enumerated credentials from GitHub, npm, AWS, HashiCorp Vault, Kubernetes, and 1Password, then exfiltrated them through three separate channels: HTTPS callbacks, GitHub API writes, and DNS tunneling. The secondary writeup from The Hacker News confirms the package targeted secret stores rather than source code; the source code is the next hop, reached with the stolen tokens.
GitHub, May 20
GitHub publicly confirmed on May 20 that approximately 3,800 of its internal repositories were exfiltrated after an attacker tracked as TeamPCP compromised an employee endpoint. According to Infosecurity Magazine, GitHub detected the intrusion on May 19, isolated the endpoint, and rotated affected secrets overnight. The root cause, per The Hacker News reporting, was a poisoned VS Code extension installed on the employee's work device; TeamPCP is demanding a $50,000 minimum payment and threatening to leak the repositories for free if GitHub refuses.
Mackenzie Jackson of Aikido Security framed the scope plainly in the SecurityWeek piece: "A single VS Code extension on one employee's machine was enough to get access to 3,800 internal GitHub repositories." Although The Record reports that TeamPCP has been active in supply-chain attacks since March 2026, no outlet has yet confirmed that the GitHub intrusion and the Nx Console compromise share the same operator; the timing, channel, and actor cluster are suggestive, not attributed.
GitHub did not disclose the name of the poisoned extension. That is a withheld indicator of compromise with significant operational value, because other organizations running VS Code at scale cannot check their own fleets against the same package. The absence of an IOC means defenders have to assume any extension installed by any developer between, roughly, late April and May 19 is potentially in scope.
The Pattern
The two events share more than a tool. They share an attack surface that procurement currently treats as out of scope, which is the developer endpoint inside the vendor. A VS Code extension is a code-signed binary running with the user's full local privileges, with read access to OS keychains, SSH agents, environment variables, and any cloud-credential helpers the developer has authenticated. The marketplace's review process is meaningful but it is not adversarial review at the depth needed to catch a poisoned 18.95.0 that lives for eleven minutes. The same governance gap exists whether the developer in question works for a startup using Nx or for GitHub.
This is also not a new attack channel. The 2022 GitHub OAuth incident, in which stolen Heroku and Travis-CI tokens were used to access dozens of customer organizations including npm, established that an attacker who reaches a development-toolchain endpoint can pivot through stored secrets into private repositories at scale. The 2026 pattern is the same pivot path with the IDE marketplace as the new injection point. I covered the original framing in the malicious AI extensions thesis: the IDE is now the perimeter, because the IDE is where the secrets, the source, and the production credentials all sit on the same machine. The TeamPCP cluster's broader campaign against the developer supply chain is also visible in the Trivy scanner-became-the-vulnerability incident, which carried the same compromise-the-tool-not-the-target shape.
What the GitHub incident adds is the fourth-party dimension, which is the same governance gap I worked through in the Vercel Context AI breach: a vendor-of-a-vendor or a developer-self-provisioned tool sitting outside the procurement scope, until an incident proves it should have been inside. When a downstream enterprise procures GitHub for source hosting, the standard DDQ asks about customer data isolation, encryption at rest, SOC 2 scope, and customer audit logs. It does not ask about the security posture of the vendor's own engineering laptops, which is precisely the surface that was compromised here. The "no customer data affected" framing is true on a literal reading and inadequate as a procurement standard, because the internal repositories of a code-hosting platform are themselves a high-value pivot target for attacks against that platform's customers. This is the same omission pattern that the Trellix source-code breach disclosure analysis walked through: a vendor source-code compromise is treated as an internal matter when it is also a customer-side risk signal.
The Procurement Row
The DDQ for any code-hosting, CI/CD, or developer-tooling vendor needs a new section scoped to the vendor's own engineering fleet. Three questions, written so they can be answered yes/no with attached evidence:
1. IDE marketplace governance. Which IDE extension marketplaces are allowlisted on engineering endpoints with production access to customer-facing services, and what is the review process for adding a new extension to the allowlist? Acceptable answers name a specific allowlist mechanism (managed extension policy, internal proxy registry, signed-extension enforcement) and describe a review gate that includes at minimum supply-chain provenance verification. Unacceptable answers describe developer self-service from the public Visual Studio Marketplace or the Open VSX Registry without an intermediate review.
2. Internal-repository compromise SLA. What is the time-bound SLA for rotating customer-impacting secrets, tokens, signing keys, and OAuth credentials when an internal-repository compromise is detected at the vendor? Acceptable answers commit to specific clocks: time-to-rotate for API signing keys, time-to-revoke for OAuth and personal-access tokens, and time-to-notify for customers whose private repositories were referenced in internal tooling. GitHub's response timeline in this incident (detect, isolate, and rotate within roughly twenty-four hours) sets a reference point.
3. Audit-log survivability. Do customer audit logs persist independently of the vendor's own logging surface, such that a compromise of vendor-internal infrastructure does not erase or modify customer-visible audit history? Acceptable answers describe customer-side log export, cryptographic anchoring, or third-party SIEM forwarding active by default. Unacceptable answers describe audit logs stored only in the vendor's own tenant.
The procurement-row template applied here mirrors the structure used in the Mistral Shai-Hulud advisory analysis and the Azure SRE Agent CVE-32173 row: for each new failure mode disclosed publicly, write one DDQ row specific enough that "we will follow up" is not a passable answer.
What Changed Today
Before this week, a procurement team could reasonably treat a code-hosting vendor's internal engineering posture as out of scope, because the only known disclosure path was customer-data exposure and the audit framework reflected that. After May 20, that scoping decision is no longer defensible: a confirmed exfiltration of 3,800 internal repositories from the largest source-hosting platform, achieved through a single poisoned IDE extension on one employee endpoint, sets the precedent that vendor-side developer endpoints are within the chain of custody for customer-side risk. The next DDQ refresh should add the three rows above, request the underlying evidence, and treat a non-answer as a finding.
