Hackers Hijack GitHub Tokens via Poisoned VS Code Extension

In a major security incident, malicious actors slipped a trojanized version of the popular Nx Console extension onto the official Visual Studio Code Marketplace. The fraudulent version remained accessible for a mere 18 minutes—but that window proved long enough to compromise thousands of secrets. The culprit, a group identified as TeamPCP, allegedly got their hands on approximately 3,800 internal repositories from a single GitHub employee’s device. Investigators with GitHub confirmed this number is “directionally consistent” with their own findings, though they found no evidence of compromised customer repositories.

How TeamPCP Operates

TeamPCP first came to light in late 2025, establishing a presence with a Telegram channel that swelled to around 700 members by early 2026. Their modus operandi: injecting credential-stealing code into popular developer tools and build systems. For example, in March 2026, they compromised the Trivy vulnerability scanner, which allowed them to gather credentials for further intrusions into software like Checkmarx KICS and LiteLLM. Two releases of LiteLLM were later found to contain backdoors as part of this campaign.

Then in mid-May, the group shifted tactics. They released a poisoned update to Nx Console, which runs on individual developers’ machines rather than in build pipelines. Once installed, the malicious code could access source code, GitHub tokens, cloud credentials—virtually anything the affected developer’s system had access to.

Impact and Aftermath

While 18 minutes may seem trivial, the breach’s effects extended far beyond that window. Many stolen tokens were used weeks after the initial theft. TeamPCP reportedly listed the stolen GitHub repositories for sale, with some offers starting at $50,000. Their criminal portfolio expands beyond data theft: their infrastructure has been used for cryptomining, for proxy services supporting other types of cybercrime, and in some cases collaborating with ransomware operators.

Legal authorities have started acting: in August 2026, Australian law enforcement charged two key suspected members, and the U.S. Department of Justice filed an indictment against another individual. Officials also issued alerts emphasizing the rising threats posed by attacks targeting developer tooling.

Defense Tips for Dev Teams

Security experts recommend several practices to reduce risk. Vet third-party tools and extensions before installing them. Pin specific commit SHAs in workflows to prevent automatic execution of newer, potentially compromised versions. Use minimal privilege principles in CI/CD and favor temporary credentials, possibly via OIDC federation.

Teams should also delay non-essential extension and package updates, monitor for suspicious outbound traffic, and regularly rotate credentials when indicators of compromise—like repository creation, archive files (e.g. tpcp.tar.gz), or lookalike domains—are detected.

Among the warning signs to watch: artifacts such as encrypted archive files in outgoing traffic, usage of domains impersonating trusted providers (for example, scan[.]aquasecurtiy[.]org), or repositories unexpectedly created in GitHub accounts like “tpcp-docs” or “docs-tpcp”. Versions of LiteLLM marked 1.82.7 and 1.82.8 are known to be compromised, especially with Python startup files that run automatically.

This incident underscores how small timeframes can result in large-scale damage for developer infrastructure. Poisoning an extension for less than 20 minutes still gave attackers long-lived access. What matters now are robust tooling, assumption of breach, and constant vigilance. Teams that tighten access controls, enforce least privilege, and monitor aggressively will be better equipped to contain the fallout when the next build or extension is compromised.

What this means: Trust in developer tools is becoming one of the most critical frontiers in cybersecurity. This breach shifts the conversation—now it’s not just developer hygiene, but the supply chain, extension review, and runtime secrets exposure. The key question going forward: how can marketplaces like VS Code enforce tighter review, and can dev teams ever assume safety from these fleeting windows of vulnerability?