Behind the Breach: Github/TeamPCP Hack

GitHub confirmed the breach on May 19 and 20, 2026. The investigation was ongoing as of June 2026. This analysis reflects confirmed reporting from The Record from Recorded Future News, Help Net Security, Sophos, SOCRadar, ArmorCode, Phoenix Security, and Hunt.io’s technical attribution research.

The malicious extension was live on the Visual Studio Marketplace for 18 minutes.

In those 18 minutes, VS Code’s auto-update mechanism did what it always does: it silently pushed the new version to every developer machine running Nx Console without asking, without warning, and without a review gate of any kind between the malicious build and the devices it was about to touch.

On at least one of those devices, there was a GitHub employee.

The extension ran a shell command. It found what it was looking for: SSH keys, GitHub tokens, credentials stored in a 1Password vault, AWS access keys, and Anthropic Claude Code configuration files. It double-encrypted the harvest and pushed it to a public GitHub repository named after a Russian folklore character before anyone had noticed what had happened.

By May 18, 2026, the group that built that extension had used the stolen credentials to clone approximately 3,800 of GitHub’s internal repositories. They listed the source code for sale at $50,000 on an underground forum and posted a message that read, in part: “It looks like our retirement is soon.”

GitHub confirmed the breach. The repositories were internal. No customer data was confirmed compromised. What was taken was the code that GitHub’s own engineers write to build and operate the platform that more than 100 million developers around the world use to store their work.

The attacker had been building toward this for months.

Who TeamPCP Is

TeamPCP, also tracked by Mandiant as UNC6780, is not a group that arrived at GitHub through opportunistic scanning. They are a supply chain specialist, and GitHub was the endpoint of a campaign that had been escalating in complexity since late 2025.

The group’s defining tool is a self-replicating worm they call Mini Shai-Hulud, an adapted version of a worm first documented in 2025. Mini Shai-Hulud automates the core of their playbook: it steals CI/CD credentials from a compromised environment and uses those credentials to publish infected versions of downstream packages, turning each compromised project into a launchpad for the next one. The attack does not spread through a network in the traditional sense. It spreads through trust. Every package that depends on a TeamPCP-compromised package becomes a potential next host.

The list of confirmed TeamPCP targets before GitHub is a directory of the open-source security and AI infrastructure stack. Aqua Security’s Trivy vulnerability scanner was compromised through GitHub Actions, triggering a cascade into Aqua Security Docker images and the Checkmarx KICS project. The Trivy breach led to a poisoned LiteLLM PyPI package that infected tens of thousands of devices with TeamPCP’s credential stealer. Checkmarx was hit twice: once through GitHub Actions workflows and OpenVSX extensions, and a second time through the Jenkins AST Scanner plugin, which was backdoored at version 2026.5.09. TanStack, Telnyx, and MistralAI packages were compromised in the same campaign window. The European Commission was among the downstream victims.

Each compromise fed the next. The credentials stolen from one project funded access to a publisher account on the next platform. The worm moved through the dependency graph of the open-source ecosystem, automated and largely invisible, until it reached an environment that contained something worth stopping for.

That environment belonged to a GitHub employee running Nx Console.

The TanStack Bridge

The specific path into GitHub began before the GitHub breach.

TeamPCP had already compromised TanStack, the popular JavaScript framework ecosystem, in an earlier wave of the campaign. Inside the TanStack compromise, they obtained access to the development environment of an Nx developer. Nx Console is a Visual Studio Code extension for the Nx build system, a widely used tool in enterprise JavaScript development. The Nx developer’s compromised environment gave TeamPCP the ability to push updates to Nx Console through the VS Code Marketplace under that developer’s publisher credentials.

They built a trojanized version of the extension. They pushed it to the Marketplace. The VS Code auto-update pipeline distributed it automatically to every machine with Nx Console installed.

The malicious build ran a payload the security community has since named rope.pyz. When executed, rope.pyz performed a credential harvest against the most common developer secret stores: 1Password vaults, SSH key directories, environment variables containing cloud provider credentials, GitHub authentication tokens, and in a detail that speaks to the specificity of the targeting, Anthropic Claude Code configuration files. The harvested material was double-encrypted and exfiltrated to a public GitHub repository, with a fallback path that used stolen GitHub tokens to create new repositories named after Russian folklore, including BABA-YAGA, KOSCHEI, FIREBIRD, and LESHY, uploading the encrypted bundle as a file called results.json before the primary exfiltration channels closed.

The malicious build was live for 18 minutes before it was pulled.

Hunt.io’s infrastructure analysis later tied the GitHub breach to the same TeamPCP command-and-control subnet used in every prior wave: three IP addresses in the 83.142.209.0/24 range, with SSH activity traced back to November 2025, four months before the TanStack campaign went public. TeamPCP provisions its infrastructure months in advance to build clean reputation histories. Standard IP reputation and domain age signals gave security teams false confidence on this group across every wave of the campaign.

The Credential Chain Into GitHub

The GitHub employee’s device received the malicious Nx Console update during the 18-minute window. rope.pyz executed. The harvest ran. The credentials left the machine.

Among the stolen material were SSH keys with access to GitHub’s internal repository infrastructure. TeamPCP used those keys to authenticate to GitHub’s systems and clone internal repositories.

By GitHub’s own accounting, approximately 3,800 internal repositories were exfiltrated. The company described TeamPCP’s claim of that number as “directionally consistent” with its investigation, a phrasing that confirms the scale while reserving room for the investigation to refine the exact count. Critical credentials were rotated on the same day the breach was detected, with the most sensitive secrets prioritized first.

GitHub confirmed no evidence that customer repositories, enterprise accounts, or user data stored outside its internal systems were compromised. What was taken was GitHub’s own source code: the internal repositories its engineers use to build and maintain the platform. The company said it would publish a fuller report once the investigation completed.

TeamPCP posted their offer on the underground forum with a direct message to the security community alongside it: “Github knew for hours, they delayed telling you and they won’t be honest in the future.” They set no ransom deadline for GitHub directly. Their stated intent was a single-buyer sale, not extortion. If no buyer emerged, the data would be leaked publicly. The post closed with contact details for interested parties.

As of the investigation’s confirmed public timeline, GitHub had not paid. The listing remained active.

What 3,800 Internal Repositories Actually Contains

The public framing of this breach has centered on the absence of customer data exposure. That framing is accurate and incomplete at the same time.

Internal source code repositories at a company the size and criticality of GitHub contain things that are not customer records but are not inconsequential either. They contain the logic that governs how authentication tokens are validated, how access controls are enforced, how the API processes requests, and how deployment pipelines interact with customer repositories. They contain documentation of internal security controls, architecture decisions, and known technical debt. They may contain hardcoded secrets, internal API keys, and configuration details that were never intended to be public but were also never systematically audited out of the codebase.

A sophisticated buyer of 3,800 GitHub internal repositories is not buying a data set to sell on a fraud forum. They are buying a research library for finding exploitable weaknesses in the platform that 100 million developers trust with their code. The value is not in the repositories themselves. It is in what the repositories reveal about how the platform works, and where it might be made to work differently than intended.

SOCRadar’s analysis of the forum posting noted that TeamPCP included a public list of repository names as proof of access. Security researchers reviewing that list identified repositories connected to internal security tooling, infrastructure automation, and deployment systems. The specific contents of those repositories have not been publicly confirmed.

GitHub’s assurance that customer data was not affected is the right answer to the question it answers. It does not address the question of what a buyer of the internal codebase might learn about the platform’s architecture that could inform a future attack against the 100 million developers and organizations that depend on it.

The Pipeline That Made This Possible

The VS Code Marketplace auto-update behavior is the structural condition that made 18 minutes sufficient.

VS Code is the dominant development environment for a significant portion of the professional software development community. Its extension ecosystem, hosted on the Visual Studio Marketplace, allows developers to install tools that extend the editor’s capabilities: language support, build system integration, code linting, testing frameworks, and hundreds of specialized utilities. The Marketplace distributes updates to installed extensions automatically and silently. When a publisher pushes a new version, VS Code pulls it and installs it on the next launch cycle, with no user confirmation, no changelog review requirement, and no security gate between the publisher’s push and the developer’s machine.

This model optimizes for frictionless updates. It treats the extension publisher as trusted by default, because the publisher’s identity was verified at the point of initial publication. It does not re-verify that the same human being who originally published the extension is still the one pushing updates. A threat actor who obtains a publisher’s credentials, through a supply chain compromise of the kind TeamPCP executed at TanStack, inherits that trust completely.

The Nx developer’s account was the compromised publisher. TeamPCP had the credentials. They pushed a build. Auto-update distributed it. The entire trust chain collapsed at the moment the developer’s account was compromised, and the Marketplace had no mechanism to detect that the entity pushing the update was not the entity that built the extension.

This is not a vulnerability in VS Code’s extension execution model. It is a gap in the supply chain trust model that governs who can push what to which developer machines, under what verification conditions, and with what notification to the people receiving the update.

The Forensic Lesson

There are three distinct forensic lessons in this incident, and they belong to three different audiences.

The first belongs to GitHub. The specific credential that enabled the repository exfiltration was an SSH key harvested from a developer’s local machine through a poisoned VS Code extension. The question the post-incident review must answer is whether developer machines with access to internal repository infrastructure were subject to endpoint detection rules that would have identified the rope.pyz payload executing and exfiltrating credentials. The payload ran a shell command, harvested from predictable credential storage locations, and made outbound connections to a command-and-control IP and a public GitHub repository. Each of those steps is detectable. Whether detection was in place and failed, or whether detection was not in place at all, determines what changes are required.

The second belongs to every organization whose developers use VS Code with auto-updating extensions. An extension installed on a developer machine that has access to production credentials, internal APIs, or privileged infrastructure is a supply chain risk that most organizations have not formally assessed. The control that addresses this is a combination of extension allowlisting, which permits only reviewed and approved extensions to install on developer machines, and secrets hygiene, which ensures that production credentials are not stored in locations that a compromised extension can reach through standard shell commands. SSH keys in ~/.ssh, GitHub tokens in ~/.gitconfig, AWS credentials in ~/.aws/credentials, and secrets in local .env files are all predictable harvest targets. Developer machines should not hold long-lived credentials with direct access to production systems.

The third belongs to the Visual Studio Marketplace and every extension distribution platform that uses the same auto-update trust model. Eighteen minutes of malicious availability produced a credential harvest sufficient to breach the world’s largest code hosting platform. The verification model that permits a publisher’s compromised account to push a malicious update to every installed instance of their extension, silently and automatically, is a systemic supply chain risk that the industry has documented repeatedly and not structurally addressed. Extension update verification that detects behavioral changes in new builds, that requires secondary confirmation for updates to extensions with access to sensitive credential stores, or that introduces a brief hold period for anomalous publisher activity would have changed the outcome here. None of those controls exist in the current Marketplace model.

TeamPCP built their infrastructure in November 2025. They pushed their extension in May 2026. The campaign ran for six months through a dependency graph that included security scanners, AI middleware, and build system tooling before it reached GitHub. The trail was documented, the infrastructure was attributed, and the cascading compromise pattern was visible to threat intelligence researchers who were tracking it in real time.

The breach still happened. The 18 minutes were enough. And the auto-update pipeline that delivered the payload will deliver the next one too, unless the trust model it operates on is changed.

MITRE ATT&CK Appendix

T1195.001 — Supply Chain Compromise: Compromise Software Supply Chain. TeamPCP’s entire campaign model is built on supply chain compromise. The GitHub breach was reached through a chain: TanStack compromise provided access to an Nx developer’s environment, which provided publisher credentials for Nx Console, which gave access to developer machines including the GitHub employee’s device.

T1554 — Compromise Client Software Binary. The trojanized Nx Console extension was a compromised legitimate software binary. Its malicious functionality was embedded in an otherwise functional extension update, making behavioral detection dependent on identifying the shell command execution rather than flagging the extension itself.

T1059.004 — Command and Scripting Interpreter: Unix Shell. rope.pyz executed shell commands on compromised developer machines to enumerate and harvest credentials from standard storage locations including SSH key directories, 1Password vaults, environment variable files, and cloud provider credential stores.

T1552.001 — Unsecured Credentials: Credentials in Files. The harvested material included SSH keys, GitHub authentication tokens, AWS credentials, and Anthropic Claude Code configuration files stored on the developer’s local machine in predictable filesystem locations accessible through standard shell commands.

T1567.001 — Exfiltration Over Web Service: Exfiltration to Code Repository. rope.pyz exfiltrated the double-encrypted credential bundle to a public GitHub repository created by the attacker, using GitHub’s own infrastructure as the exfiltration destination. A fallback path created repositories named after Russian folklore characters and uploaded results.json as the encrypted payload.

T1078.004 — Valid Accounts: Cloud Accounts. The stolen SSH keys authenticated to GitHub’s systems as a legitimate developer, allowing repository cloning without triggering credential-based access controls.

T1587.001 — Develop Capabilities: Malware. TeamPCP developed Mini Shai-Hulud, a self-replicating worm that automates supply chain propagation by stealing CI/CD credentials and using them to publish infected versions of downstream packages, enabling cascading compromise across the open-source dependency graph.

T1583.003 — Acquire Infrastructure: Virtual Private Server. Hunt.io’s attribution confirmed that TeamPCP pre-staged command-and-control infrastructure in the 83.142.209.0/24 subnet from November 2025, four months before the TanStack campaign became public, building clean IP reputation histories to defeat age-based and reputation-based detection controls.