GitHub hacked via a VS Code extension: the TeamPCP case

18 minutes. That's how long version 18.95.0 of Nx Console was available on the Visual Studio Code Marketplace before being pulled — more than enough time for the TeamPCP group to compromise a GitHub employee and exfiltrate around 3,800 internal repositories belonging to the company. The incident, confirmed by GitHub on 20 May 2026, is one of the most emblematic software supply chain attacks of the year.

What Nx Console is and why it matters to you

Nx Console is a legitimate and very popular VS Code extension, used by developers working with the Nx framework for monorepos. It has hundreds of thousands of active installs. In other words: we're not talking about an obscure extension someone installed carelessly — it's a mainstream, trusted tool with a clean track record.

That's exactly the point. Attacking a popular extension means compromising, in one go, an enormous number of qualified targets: developers with access to repository tokens, CI/CD pipelines and corporate infrastructure. Whoever installs Nx Console isn't a casual user — it's someone with valuable credentials.

How the attack worked, step by step

The compromise chain, according to analysis by Bleeping Computer and Help Net Security, followed this path:

1. Publishing the malicious extension: on 18 May, the attackers published version 18.95.0 on the Marketplace, replacing (or masquerading as) the official package. It was live for between 11 and 18 minutes.
2. Automatic execution on VS Code startup: every time the extension loaded, it silently ran an npx command pointing at a specific commit in the official nrwl/nx repository on GitHub.
3. Download and execution of the hidden payload: that planted commit installed and executed a package called nx-next, disguised as part of an MCP configuration (a routine task in the Nx ecosystem). The real purpose of nx-next: stealing GitHub access tokens and other credentials from the environment.
4. Exfiltration: with the token captured from a GitHub employee's device, the attackers accessed and cloned the company's internal repositories.

The vector is especially sophisticated because the malicious code wasn't in the extension itself: it merely called code from somewhere else (the planted commit in the legitimate Nx repository). That makes detection harder for scanners that only analyse the package in isolation.

Who TeamPCP are

TeamPCP — tracked by the Google Threat Intelligence Group as UNC6780 — is a criminal group specialising in supply chain attacks against development tools and open source infrastructure. Before GitHub, the group had already compromised:

• The security scanner Trivy, from Aqua Security
• KICS, from Checkmarx
• The LiteLLM library
• The Telnyx SDK
• Packages from TanStack and MistralAI

The pattern is consistent: the targets are developers and security teams — people with privileged access. The 3,800 repositories stolen from GitHub were put up for sale for $95,000, in a joint operation with the LAPSUS$ group. GitHub confirmed the number is "consistent with the internal investigation".

What GitHub lost — and what was preserved

GitHub was clear: customer data, user repositories and enterprise accounts were not affected. The compromise was restricted to the company's internal corporate environment — source code for internal systems, tooling and its own infrastructure.

That's no small thing. Internal code can reveal architecture, authentication flows, critical dependencies and potential weak points that a persistent adversary can exploit months later. It isn't a breach of user data, but it is a vector for more targeted future attacks.

This kind of incident has a direct parallel with what happened to Trellix, when the RansomHouse group stole source code from a security company — demonstrating that not even those who protect others are immune.

Not the first attack like this — and it won't be the last

This pattern of compromising the developer's tool to reach the final target has been growing. In April this year I covered here on the blog the supply chain attack on JDownloader via a poisoned Python package — the same logic: compromise a trusted tool to escalate access.

The difference here is the sophistication: the malicious code wasn't inside the published package, but was downloaded dynamically from an apparently legitimate source (Nx's own repository on GitHub). That makes detection much harder for traditional static analysis solutions.

What you should do now

If you use Nx Console in VS Code, the first step is immediate:

• Update to version 18.100.0 or later, confirmed to be free of the malicious payload.
• Check the history of GitHub tokens associated with your device under Settings → Developer Settings → Personal Access Tokens and revoke any suspicious token.
• If you installed the extension between 17 and 19 May 2026, treat your credentials as compromised: rotate tokens, review GitHub access logs and audit which repositories were accessed in that period.
• Consider restricting which VS Code extensions are allowed to run network scripts at startup — corporate extension policies exist for exactly this.

For teams managing multiple developer workstations, it's worth reviewing VS Code and terminal execution logs. Log auditing with PowerShell can help identify suspicious npx executions outside the normal workflow.

The bigger lesson

Trusting an extension because it's popular and has a clean history is a reasonable heuristic — but TeamPCP demonstrated that an 18-minute window is all it takes to turn that trust into an attack vector. The modern developer's risk surface includes every plugin, every dependency, every package manager invoked in the terminal.

GitHub survived the incident without exposing user data. Others won't be so lucky. If you run a development team, this is the moment to review your approved extension policy — before someone at your company becomes the next employee with a captured token.

If you were affected or want to discuss how to implement extension controls in your environment, tell us in the comments.