← Blog

18 minutes was all it took: how a VS Code extension walked off with 3,800 private GitHub repos

The theft of GitHub's internal repositories didn't start by breaking a firewall: it started on a developer's laptop that installed a poisoned extension update. Here's what actually happened, why the weak link is still the human, and how to harden your software supply chain.

No broken firewall, no zero-day: just one click

We're used to picturing big hacks as assaults on a fortress: walls torn down, impossible exploits, weeks of siege. The reality of May 2026 was far humbler and far more unsettling. GitHub —owned by Microsoft, home to half the planet's code— had its internal repositories stolen, and it all started on the laptop of one of its developers, who installed an update to an extension they used every day.

The exposure window was 18 minutes. That's all the trojanized version was available for. Enough.

Let's tell it properly, because the underlying lesson isn't about GitHub: it's about you, your team and the laptop you deploy from.

What exactly happened

On May 18, 2026, a malicious update to the Nx Console extension for Visual Studio Code appeared on the Marketplace. It stayed live for 18 minutes —from 12:30 to 12:48 UTC— before being pulled. In that window, anyone with auto-update enabled swallowed it.

What did that update do? It was a credential stealer. The moment it landed on a developer's machine, it rummaged through and made off with everything juicy it could find:

  • 1Password vaults,
  • Claude Code configurations (yes, even the tokens of AI tooling),
  • npm, GitHub and AWS credentials.

One of those developers worked at GitHub. With their credentials, the attackers reached the internal infrastructure and exfiltrated roughly 3,800 private repositories (the group itself brags about 4,000). On May 20, GitHub confirmed it. And in case there was any doubt about intent, the attackers put "GitHub's source code and internal orgs" up for sale on a criminal forum, with a floor price of $50,000.

It wasn't luck: it was a campaign

Here's where this stops being an anecdote and becomes a pattern. Behind it is a group known as TeamPCP (Google tracks it as UNC6780), and the GitHub hit was just one piece of a much larger supply chain campaign nicknamed Shai-Hulud.

Between late 2025 and May 2026, that same group:

  • poisoned more than 170 packages across npm and PyPI,
  • compromised the GitHub Actions of security vendors as serious as Aqua Security and Checkmarx (Trivy),
  • and hijacked a VS Code extension with 2.2 million installs.

And many of those intrusions started from something as silly as a single improperly rotated access token (PAT) or a compromised developer. One key left in a pocket opens the door to the whole house.

Notice what there wasn't in any of this: no dazzling exploit against GitHub's server, no zero-day in its infrastructure. The attacker didn't break the wall. They tricked whoever had the key.

That's the discomfort worth accepting: in most recent major incidents, the human barely "does" anything. They're passive. They are, simply, a credential with legs. They install an extension, run an npm install, save a token in a config file… and unknowingly become the way in. If in your head security ends at the server's firewall, you're leaving out the device from which that server is governed.

How not to be the next headline

Let's land this, which is what we're here for. You don't have to be GitHub for this to hit you: anyone who installs dependencies and uses extensions is in the same crosshairs. The good news is that the defense is common sense and cheap.

1. Treat extensions as what they are: third-party code with permissions

  • Disable auto-update for extensions. It's the detail that turned 18 minutes into a global disaster. In VS Code:
// settings.json
"extensions.autoUpdate": false
  • Install only what you need. Every extension is someone else's code running with your permissions. Audit your editor and delete what you don't use.
  • Before installing or updating, check who publishes it and be wary of brand-new versions.

2. Treat dependencies with the same distrust

  • Pin exact versions and always use the lockfile. In deployments, npm ci (not npm install): it installs exactly what's in package-lock.json, no surprises.
  • Disable install scripts, the classic vector for running code when a package is installed:
npm config set ignore-scripts true        # global
npm ci --ignore-scripts                    # per project
  • Apply a cooldown: don't jump to the latest version the same day it ships. Most poisoned packages are spotted and pulled within hours.

3. Treat credentials as if they were already leaked

  • Short-lived tokens, minimal permissions. A GitHub PAT with a long expiry and permissions to spare is exactly what these attacks hunt for. Use fine-grained tokens, with an expiry and only the permissions strictly needed.
  • Rotate them for real and completely. Half-rotating a token (leaving the old one valid "just in case") was the origin of several of these intrusions.
  • No plaintext secrets on the laptop. AWS credentials in ~/.aws, tokens in config files… that's precisely what the stealer came for. MFA on everything that allows it.

4. The developer's laptop is production

If you deploy from that machine, access private repos or sign releases, it's a production asset, not "the work computer." It deserves the same care: updated, with the minimum installed, and with credentials that, if leaked, don't unlock the whole kingdom.

The recommendation, no hedging

The GitHub attack didn't prove its walls were weak. It proved that it doesn't matter how high the wall is if you leave the key on a laptop that runs third-party code without a second thought. The software supply chain —extensions, dependencies, tokens— is today the most profitable attack surface there is, precisely because almost nobody watches it.

If your team installs dependencies and extensions daily, and nobody has ever looked at what permissions they drag in or how well-rotated the tokens are, that's exactly the hole we should talk about. Reviewing it costs an afternoon; discovering it on a code-for-sale forum costs a great deal more.

References

Want to talk about your case?

Tell us what you need and we will get back to you within 24 hours with a clear proposal.

Get a quote