I’ve been saying for years that the biggest security risk in most organisations isn’t the firewall or the servers. It’s the developer’s laptop. This week, GitHub proved me right in the most spectacular way possible.
On May 20, Microsoft-owned GitHub confirmed that a hacking group called TeamPCP had stolen data from roughly 3,800 of its internal repositories. The attack vector? A single employee installed a poisoned VS Code extension. That’s it. One bad plugin on one machine, and suddenly a hacking crew is rifling through thousands of GitHub’s own code repositories and offering the stolen data for sale on a cybercrime forum with a starting price of $50,000.
GitHub says there’s no evidence of customer data being impacted, and I’m inclined to believe them on that narrow point. But let’s not lose sight of what actually happened here. The company that hosts the world’s software got hacked through the exact same supply chain weakness that’s been exploited repeatedly in 2026, and they had zero visibility into what extensions their developers were running.
TeamPCP Have Been Busy
Here’s what makes this more alarming than a one-off incident. TeamPCP isn’t some new crew stumbling onto a technique. In 2026 alone they’ve compromised Trivy, Checkmarx, Bitwarden CLI, TanStack, and now GitHub. All through developer tooling. All using the same basic playbook: get malware onto a developer’s machine via a trusted tool, then use that foothold to reach further into the network.
Mackenzie Jackson from Aikido Security put it plainly: “Developer workstations are the number one target in supply chain attacks right now. Most security teams still have zero visibility into what extensions or packages are on their developers’ machines, or how recently they were published. That’s the blind spot these attacks keep walking through.”
That’s the real story here. Not just GitHub. The blind spot is everywhere, in every company with developers using VS Code, which is basically all of them.
Why VS Code Extensions Are a Genuine Crisis
VS Code extensions aren’t sandboxed. They have full access to everything on the machine they run on: credentials, SSH keys, cloud API keys, environment files, tokens sitting in memory. A developer’s laptop is essentially a master key to your entire infrastructure, and VS Code extensions get handed a copy of that key the moment they’re installed.
The VS Code marketplace has hundreds of thousands of extensions. Microsoft does review them, but the review process has never been designed to catch sophisticated supply chain attacks where a legitimate extension is later poisoned via a compromised publisher account or a dependency update. The attacker doesn’t need to create a new malicious extension from scratch. They just need to get access to one that developers already trust.
GitHub hasn’t named the specific extension involved. That omission matters. Without that information, every developer using VS Code right now has no idea whether they’ve been exposed to the same poisoned tool.
What You Actually Need to Do
If you’re responsible for a team of developers, or you are a developer, here’s what this week’s GitHub breach tells you to action:
- Audit every VS Code extension across your developer machines. You need to know what’s installed, who published it, when it was last updated, and whether the publisher account shows any signs of compromise.
- Treat developer machines as high-value targets in your threat model, not just endpoints. The credentials and tokens sitting on a developer’s laptop can give an attacker more access than a successful phishing attack on an executive.
- Rotate credentials and secrets regularly, and treat any secret that has lived on a developer machine as potentially compromised if that machine is breached. GitHub rotated critical secrets immediately after detection, which is good practice, but reactive rotation is always worse than proactive rotation.
- Consider restricting VS Code extension installs via policy to an approved list. Yes, developers will complain. That’s fine. The alternative is what happened to GitHub.
GitHub is investigating and has promised a full incident report. When that comes out, the specific extension name should be disclosed. Until then, treat your VS Code extension inventory as an open security question.
The Supply Chain Is the Attack Surface Now
What TeamPCP is doing in 2026 is the logical evolution of supply chain attacks. Rather than targeting one organisation directly, they’re targeting the tools that developers at hundreds of organisations use every day. Compromise Trivy (used for container vulnerability scanning) and you potentially have access to every CI/CD pipeline that runs it. Compromise a VS Code extension with millions of installs and you have a foothold on millions of developer machines simultaneously.
We wrote recently about a worm that hit 160+ npm packages including OpenAI. That was the same group, the same technique. The GitHub breach isn’t a surprise. It’s a continuation.
The security perimeter isn’t your network edge anymore. It’s your software supply chain, and most companies have no idea what’s in it.
“A single VS Code extension on one employee’s machine was enough to get access to 3,800 internal GitHub repositories. Most security teams still have zero visibility into what extensions or packages are on their developers’ machines. That’s the blind spot these attacks keep walking through.” — Mackenzie Jackson, Aikido Security