GitHub — internal repositories breached via poisoned Nx Console VS Code extension

What happened

On 18 May 2026 a poisoned release of Nx Console, the Visual Studio Code extension developers use to drive Nx monorepo workflows, was published to the Visual Studio Marketplace as nrwl.angular-console version 18.95.0. The release looked like a routine update of an extension with millions of installs. It was not. On 19 May, a GitHub employee installed the new version on their corporate development workstation. The extension immediately began harvesting credentials and access tokens from the local environment, and within hours the attacker had used those credentials to clone roughly 3,800 of GitHub’s internal repositories.

GitHub detected the activity the same day, isolated the affected endpoint, removed the malicious extension version from the marketplace, and began rotating critical secrets through the evening. The company published a statement on 20 May confirming the scope. Its current assessment is that the compromise is confined to its own corporate estate: customer repositories, GitHub Enterprise tenants and consumer user data are not affected on the evidence so far. Internal repositories at GitHub do not host customer source code, but they do host infrastructure-as-code, deployment scripts, internal service definitions, configuration management material and the day-to-day engineering documentation of one of the most heavily relied-upon platforms in software.

The actor self-identifies as TeamPCP, also tracked by some vendors as UNC6780. Within hours of the breach landing, a listing offering “GitHub source code and ~4000 repos of private code” appeared on the Breached cybercrime forum at a starting price of US$50,000. The same actor cluster sits behind the Bitwarden CLI compromise of 22 April, the Checkmarx GitHub Actions backdoors that enabled it, and the broader Shai-Hulud worm lineage that has been chewing through the npm and Action ecosystems since late 2025.

How it worked

Visual Studio Code extensions are trusted by default with the full privileges of the user running the editor. They can read any file the user can read, including dotfiles in the home directory, browser-session databases, cached cloud SDK credentials, SSH private keys, the .npmrc and .config/gh/hosts.yml files developers use to talk to npm and GitHub from the command line, and any environment variables that happen to be exported into the shell that launched VS Code. On a corporate developer’s machine that is a very large credential surface, and it is one that runs without the audit trail or approval workflow most organisations apply to SaaS or laptop applications.

The malicious 18.95.0 build of Nx Console exploited that trust. On install and activation it ran a discovery routine across the obvious credential locations, packaged the result, and exfiltrated it to attacker-controlled infrastructure. The full payload analysis is still being published, but the obfuscation patterns observed by multiple researchers match those reused throughout the Shai-Hulud / TeamPCP campaign cluster, including the credential-stealer module shipped inside the trojanised Bitwarden CLI a month earlier. The reuse is the strongest single piece of evidence for attribution.

The publication path itself is the part the public statement does not yet explain in full. Either the legitimate Nx publisher account was compromised and used to push a malicious build of the real extension, or the actor managed to upload a build under a publisher identity that the marketplace’s verification controls treated as legitimate. Both routes have precedent. Neither speaks well of the marketplace’s role as a trust anchor for a class of software that runs unsandboxed on every developer laptop in the world.

From the credentials, the rest is mechanical. The GitHub employee’s local tokens almost certainly included a personal access token or device-bound credential with read access to the corporate organisation. Internal repositories at GitHub are by default visible across the engineering organisation, the same arrangement most large engineering teams choose so that engineers can reason about adjacent services without raising a ticket. Cloning 3,800 repositories at full bandwidth is not a stealthy operation, but it is also not the kind of activity most organisations are alerting on. GitHub’s own detection appears to have come from the egress and behavioural side rather than from the developer endpoint.

Timeline

The visible timeline is short. The malicious nrwl.angular-console 18.95.0 build landed on the Visual Studio Marketplace on 18 May 2026. The GitHub employee installed it on 19 May. The attacker pulled approximately 3,800 internal repositories on 19 May. GitHub detected the compromise the same day, isolated the endpoint, pulled the extension version from the marketplace and began rotating credentials, prioritising the highest-blast-radius secrets first. On 20 May, GitHub published its statement and TeamPCP posted the data for sale at US$50,000. Sophos, Help Net Security, Phoenix Security, Aikido and Varonis published independent analyses across 20–22 May; the Register and CyberScoop carried GitHub’s direct quotes the same week.

The earlier wing of the same campaign sets the context: Trivy was compromised in late 2025, Checkmarx in late February and March 2026, the Checkmarx kics-github-action and ast-github-action repositories were tagged with malicious releases in late March, the Bitwarden CLI was published with a trojanised npm package on 22 April, and TeamPCP resurfaced with a fresh Checkmarx Jenkins plugin compromise on 11 May. The GitHub incident sits eight days after that last public re-fire.

What defenders should learn

The Bitwarden CLI case taught one lesson: a CI pipeline trusts every third-party Action it pulls. The GitHub case teaches the complementary one: a developer’s workstation trusts every IDE extension it loads, and the workstation’s credentials are the corporate organisation’s credentials. Both are supply-chain compromises against the same target class — developer infrastructure — but the threat surface in this case is the editor, which is rarely inventoried as a business application, almost never approval-gated at the marketplace level, and almost never monitored for the credential reads that constitute the entire payload behaviour.

The high-leverage defender actions are not novel. Allowlist IDE extensions through VS Code’s enterprise extension control settings or equivalent endpoint policy, and review the allowlist on the cadence applied to SaaS vendor risk. Move developer-facing credentials off long-lived personal access tokens and onto short-lived, OIDC-federated tokens minted at the point of use; the prize for the attacker shrinks dramatically when the secret on disk expires in twenty minutes. Treat outbound network from developer workstations as in-scope for egress monitoring, not just laptop fleet posture. And resist the convention that a single engineering organisation should be flat at the source-tree level: GitHub’s own observation that 3,800 internal repositories were within reach of one device is also the question every other engineering organisation should be asking itself.

The segmentation framing is for another post. The narrower observation is that two of the three biggest supply-chain compromises of the year so far have hinged on the silent privilege a developer’s tooling carries, and on the fact that very few defenders treat that tooling as a piece of the production threat surface. The actor cluster running these campaigns clearly has, and the cycle time between disclosures is shrinking.