Cybersecurity

GitHub Hacked Through a Poisoned VS Code Extension — 3,800 Internal Repositories Compromised

A single GitHub employee installed a trojanized VS Code extension — and attackers walked away with roughly 3,800 internal repositories. Here's what happened, who's behind it, and how to vet your own extensions before the same thing happens to you.

GitHub Hacked Through a Poisoned VS Code Extension — 3,800 Internal Repositories Compromised

There's something almost painfully ironic about GitHub — the platform that stores the code for most of the world's software — getting breached through a plugin for a code editor. But that's exactly what happened, and the fallout is a stark reminder that one bad extension install can unravel even the most security-conscious organizations.

What Happened

On May 20, 2026, GitHub confirmed that a GitHub employee installed a poisoned Visual Studio Code extension from the official VS Code marketplace. That single action compromised the employee's device and gave attackers access to roughly 3,800 internal repositories.

As Security Affairs reports, GitHub responded quickly — removing the malicious extension from the marketplace, isolating the compromised endpoint, and beginning incident response immediately. Critical secrets and credentials were rotated, with the highest-impact ones prioritized first. But the data was already gone.

GitHub's own statement acknowledged the scope: "Our current assessment is that the activity involved exfiltration of GitHub-internal repositories only. The attacker's current claims of ~3,800 repositories are directionally consistent with our investigation so far."

The good news, for now, is that GitHub says there is currently no evidence that customer data stored outside the affected internal repositories — meaning your enterprise accounts, your organization's repos, or your own code — was compromised. That said, the investigation is still ongoing.

Who's Behind It: Meet TeamPCP

The group claiming credit is TeamPCP (also tracked as UNC6780), a cybercrime outfit that specializes in supply chain attacks targeting open-source security utilities and AI middleware. They've previously compromised Aqua's Trivy security scanner, CheckMarx's KICS, the LiteLLM library, the Telnyx SDK, TanStack, MistralAI, and a growing list of other widely-used packages.

Their method of choice is a self-replicating worm called Mini Shai-Hulud, which largely automates supply chain attacks by stealing CI/CD credentials and using them to publish infected versions of further packages. Once inside one environment, it propagates — and because the worm spreads using tokens stolen from infected systems, the number of affected packages is expected to keep growing.

TeamPCP listed GitHub's source code for sale on a cybercrime forum with an asking price of no less than $50,000, claiming access to about 4,000 repositories. Their post included the now-familiar framing: this isn't a ransom, they want one buyer, and if no buyer materializes, they'll leak the data for free. The Hacker News reports that the LAPSUS$ cybercrime group later joined TeamPCP for a joint sale listing the repositories for $95,000.

According to security researcher Rakesh Krishnan, the leaked repositories reportedly include GitHub Actions code, Copilot internal projects, CodeQL tools, internal infrastructure, security tools, and components related to Codespaces and Dependabot.

The Real Lesson: VS Code Extensions Are a Serious Attack Surface

This breach didn't happen because GitHub had weak perimeter security or unpatched servers. It happened because a developer — at one of the most security-aware companies on the planet — installed something that looked legitimate enough to pass their judgment.

As Aikido Security researcher Charlie Eriksen put it: "VS Code extensions have full access to everything on the developer's machine, including credentials, cloud keys, and SSH keys." He also noted that the day before the GitHub breach was disclosed, a completely separate extension called Nx Console — with 2.2 million installs — was also briefly backdoored. The community caught that one in 11 minutes. Fast, yes — but as Eriksen pointed out, a lot of machines auto-update in that window.

The VS Code marketplace has a well-documented history of malicious extensions slipping through. And this pattern isn't unique to VS Code. Browser extensions, IDE plugins, and developer tools of all kinds operate with deep system access that most users never think about.

How to Vet Extensions Before You Install Them

Whether you're a developer in Yuba City or running a small business IT setup, the same principles apply. Here's how to protect yourself:

1. Check the publisher, not just the name. Malicious extensions often impersonate popular tools with slight name variations. Always verify that the publisher name matches the official organization behind the tool. If you're installing a Microsoft product, the publisher should say "Microsoft," not a close lookalike.

2. Look at install counts and reviews critically. A high install count is a positive signal, but not a guarantee — the Nx Console extension had 2.2 million installs and still got backdoored briefly. Read recent reviews and watch for sudden drops in rating, which can indicate a compromised update.

3. Review requested permissions. Extensions that ask for broad file system access, network access, or the ability to run shell commands should raise an eyebrow. Ask yourself: does a color theme extension really need to run terminal commands?

4. Check the extension's source code and repository. Reputable extensions link to a public GitHub repository. If there's no source code available or the repository looks sparse and new, that's a red flag.

5. Enable auto-update with caution. As the Nx Console incident illustrates, auto-updates mean a compromised extension version can reach your machine within minutes of being published. Consider reviewing changelogs before applying updates to tools that have deep system access.

6. Audit your installed extensions regularly. Extensions you installed once and forgot about are still running. Do a quarterly review and remove anything you no longer actively use.

7. Use extension allow-lists in team environments. If you manage a development team or a small business IT environment, consider enforcing a policy that only approved extensions can be installed. VS Code supports this through workspace settings and enterprise policies.

The Bigger Picture

Security Affairs makes a point worth sitting with: "Each incident produces the same response: the extension gets removed, a post-mortem gets written, and developers are reminded to be careful about what they install. Then it happens again."

The GitHub breach makes the stakes clearer than any previous incident of this type. This wasn't a careless end user clicking a phishing link. This was a developer at a major tech company, on internal systems, installing something from an official marketplace — and that one decision cascaded into the exfiltration of thousands of internal repositories.

For Yuba City small businesses and local developers who rely on tools like VS Code every day, the takeaway is straightforward: treat every extension install like you'd treat installing any software on a machine that has access to your business data. Because that's exactly what it is.

If you're unsure whether your current development environment or business workstations have been exposed to suspicious extensions or software, we're happy to take a look — that's exactly the kind of thing our diagnostics service is designed to catch before it becomes a bigger problem.

---CONTENT_MARKDOWN---

Related local service
Worried this could be malware?
If your computer has pop-ups, redirects, suspicious downloads, or ransomware warnings, start with our local virus removal page.
Tags
cybersecurity vulnerability web-security small-business-it patch-management