GitHub hacked in May 2026: 18 minutes was all it took — what it means for you (and 7 habits to adopt this weekend)

Disclaimer. This is an explainer, not personalized security advice. For critical decisions (mass secret rotation, post-mortem, regulatory disclosure), ask a pro. All sources are at the bottom — official GitHub statement, advisory nrwl/nx-console GHSA-c9j4-9m59-847w, specialized press from May 2026.

---

18 minutes.

That's all it took.

On May 18, 2026 at 12:30 UTC, a booby-trapped update to a VS Code extension used by 2.2 million devs is published. At 12:48, it's pulled.

In between, thousands of developer machines automatically receive the payload — including that of a GitHub employee.

The result 48 hours later: ~3,800 internal GitHub repositories cloned and exfiltrated.

Not a customer repo. Not Enterprise. Not your data. But the message sent to every solo dev building their business with a 2026 stack (VS Code or Cursor + GitHub + npm + a bit of AWS) is: your IDE has become your weak link.

And no one is going to secure it for you.

---

What actually happened

The culprit is called TeamPCP (tracked by Google Threat Intelligence under the code UNC6780). The vector is a booby-trapped version of Nx Console v18.95.0 — a Visual Studio Code extension popular in the Angular/Nx ecosystem.

What makes the story interesting isn't the final hack. It's the chain upstream.

TanStack compromise (npm package, April–May 2026)
        ↓ theft of an Nx dev's GitHub credentials
Malicious push to the official nrwl/nx-console repo
        ↓
Nx Console 18.95.0 published on the Visual Studio Marketplace
(signed by the legitimate publisher — Nrwl)
        ↓
Silent auto-update on thousands of machines
        ↓
Theft of GitHub, npm, AWS, HashiCorp Vault, Kubernetes, 1Password tokens
        ↓
On 1 machine = a GitHub employee: cloning of ~3,800 internal repos

Three things to remember:

1. The publisher was legitimate. The Nrwl signature prevented nothing. It wasn't the marketplace that got hacked, it was the upstream source code that was tampered with via stolen credentials. If you thought "verified publisher = safe," that page turns.

2. The payload also targeted AI tools. Among the targeted files: ~/.claude/settings.json. To my knowledge, it's one of the first documented payloads to explicitly target AI assistant configs. The same goes for Cursor (~/.cursor/), Continue, and anything that installs in your home directory with tokens.

3. The same week, in parallel. Another attack dubbed "Megalodon" was injecting malicious GitHub Actions workflows into 5,561 public repositories, all on May 18, over 6 hours. Not officially the same group. But the same week, the same ecosystem, the same pressure.

This is no longer an incident. It's a climate.

---

Why it concerns you (even if you don't have Nx Console)

You tell yourself: "I don't use Nx, not my problem." That's the blind spot.

Any VS Code or Cursor extension you've installed can, tomorrow, receive a booby-trapped update. Auto-update is silent by default. You can wake up with a payload in your IDE without having clicked anything anywhere.

If you're still hesitating between IDEs and want to understand what's at stake on the Cursor side, I detailed the trade-offs in Cursor 3 vs Windsurf in 2026.

And there's also the indirect, more insidious scenario: your transitive npm dependencies. If your stack uses TanStack Query, React Query, Router, Form or Table, your builds from the past few weeks potentially pulled the compromised version. On your Vercel runner, your GitHub token and your Vercel token may have passed in plaintext to an attacker's server — while you kept calmly running git push.

That's the 2026 threat model: you no longer need to click a suspicious link. You just need to exist in the ecosystem.

---

The real lesson: your IDE is no longer a tool, it's a perimeter

For 15 years, we mentally separated "serious code" (the repo, GitHub, the server) from "personal comfort" (the IDE, its plugins). The IDE was cozy.

That era is over.

Your IDE:

• reads your ~/.ssh/,
• reads your gh auth token and your npm tokens,
• runs arbitrary code on every extension update,
• pushes git push and terraform apply with secrets you've forgotten,
• often has an AI agent plugged in that can also read your files.

Microsoft reacted on May 22, 2026 by enabling Device Protection in VS Code: by default, any package or extension published in the last 48 hours is blocked from installation, with automatic fallback to the previous safe version. GitHub shipped staged publishing on npm the same day (npm stage publish in CLI 11.15.0): a stolen CI token can no longer publish on its own — a human 2FA approval is required on top.

Two useful patches. But they don't protect you if you're not up to date, if you use Cursor/Windsurf (which don't have Device Protection yet), or if the attack comes from elsewhere.

Conclusion: you have to treat your dev machine as a risk zone. Not as a personal PC.

---

7 habits you can adopt this very weekend

These aren't enterprise projects. They're solo moves, doable this Saturday. Sorted from simplest to most structural.

1. List your extensions and cut half

Look at the list honestly. The ones you don't use every week? Uninstall, don't disable. A disabled extension keeps its code on your machine; an uninstalled one disappears.

For the others, take a quick look at the publisher. If the name means nothing to you, go check on GitHub. An extension with 200 installs and an anonymous publisher that has access to your workspace is a huge risk for cosmetic comfort.

2. Turn off auto-update and impose your quarantine window

The personal rule: no extension update within 48 hours of its publication. Want to automate it? One line — "extensions.autoUpdate": false in the settings — and you decide case by case.

This is exactly what Microsoft just made default. Apply it yourself, without waiting. 18 minutes was enough for Nx Console. 48 hours of quarantine protect you in 99% of cases.

3. Tidy up your GitHub tokens

If you still have classic Personal Access Tokens (ghp_...), delete them this weekend. Recreate fine-grained PATs instead:

• scope limited to one or two specific repos,
• max 90-day expiration,
• minimal permissions.

For your CI/CD (Vercel, GitHub Actions, AWS), switch to OIDC: your runner exchanges a short JWT for AWS credentials on each build. No more long-lived token lying around.

And if you publish to npm, enable staged publishing this week. It's free, it's official, it's exactly what GitHub just rolled out in response to this hack.

If the MFA + SSH keys + clean tokens baseline isn't in place yet, start by securing your dev accounts — it's the foundation everything else rests on.

4. Separate your workspace from your machine

Your personal machine contains your SSH, your passwords, your photos, your life. Why is your experimental IDE running in the same place?

Three options depending on your level:

• Simplest — VS Code Dev Containers. You code in a Docker container that does not see your ~/.ssh or your global credentials. A booby-trapped extension, if it strikes, stays in the container. Setup: 30 minutes.
• Intermediate — a dedicated VM. Multipass, UTM (Mac), WSL2 or Hyper-V (Windows), VirtualBox (all OSes). Snapshot every Friday, roll back if things get weird.
• Most rigorous — a 2nd physical machine for business-critical code only (deployment, signing keys, admin accounts). An old refurbished machine for €200 is enough.

5. Stop your own secrets from leaking

Several free tools scan your code locally before each commit and block forgotten secrets (API keys, tokens, passwords).

The three most solid in 2026: gitleaks (the lightest, 100% open source), ggshield from GitGuardian (covers 550+ secret types, free account required, Cursor + Claude Code hooks), TruffleHog (checks whether the detected secret is still active).

All work on Windows, Mac and Linux. If you're starting out, begin with ggshield or gitleaks — 5-minute install.

6. Get your crown jewels off GitHub

This is the most radical move, and the one that really changes the threat model.

Not all your data has the same value. Your blog's repo can stay on GitHub. But your proprietary code (the SaaS you're building, your Terraform configs, the playbooks with creds, the templates you sell) — why is it on a third party's infrastructure that just proved it can be compromised via an IDE extension?

The serious options: Forgejo (a free fork of Gitea) or Gitea self-hosted on a €5–10/month VPS, or Codeberg (a free instance hosted by a German non-profit, ideal for open source).

Warning: a badly configured self-host = just a relocated risk. Read the hardening docs, enable 2FA + SSH-only keys from the start.

7. Set up free sentries

You don't have a SOC. But GitHub gives you, for free, enough to see it coming:

• Secret Scanning Alerts on all your private repos (free since 2023). Enable it in Settings → Code security.
• Dependabot Security Updates on all your active repos.
• Email alert on any new login from an unrecognized device.
• An extension log: a simple dated extensions-audit-YYYY-MM-DD.txt file that you archive on the 1st of every month. Next time an extension is compromised, you can date your exposure to the minute.

---

The minimum if you do only one thing

You have 30 minutes. Here's the order:

1. List your extensions (code --list-extensions --show-versions) → archive the result.
2. "extensions.autoUpdate": false in settings.json.
3. Replace your classic PATs with fine-grained ones, 90-day max expiration.
4. Enable Secret Scanning + Dependabot on your repos.
5. Back up your critical secrets off GitHub (an age-encrypted file on an external drive is enough).

---

Why I'm telling you this here

Because the CodingQueen40 method — "build your tech business after 40 with the tools of 2026" — no longer makes sense if we treat cybersecurity as an expert topic. It has become a business skill.

A solopreneur who gets her GitHub account drained loses her code, sometimes her domain if the email is linked, her audience if the blog is defaced, her revenue for weeks.

The hack of weeks 20–21 isn't an isolated event. It's the new baseline. TeamPCP has already run 20 documented waves of attacks in 2026. There will be more.

The only lever we have is to act on the perimeter that belongs to us: our workstation, our tokens, our backups.

Have a good securing weekend. Let's go.

---

Main sources

• GitHub Blog — Strengthening supply chain security: Preparing for the next malware campaign (May 2026)
• GitHub Advisory GHSA-c9j4-9m59-847w — Compromised Nx Console version 18.95.0
• Nx Devtools (official X/Twitter) — SECURITY ADVISORY: A malicious version of Nx Console v18.95.0 was published today at 2:36 PM CEST (May 18, 2026)
• The Hacker News — GitHub Internal Repositories Breached via Malicious Nx Console VS Code Extension (May 20, 2026)
• The Hacker News — npm Adds 2FA-Gated Publishing and Package Install Controls Against Supply Chain Attacks (May 2026)
• Help Net Security — TeamPCP breached GitHub's internal codebase via poisoned VS Code extension (May 20, 2026)
• Help Net Security — GitHub, Grafana Labs breaches traced back to TanStack supply chain compromise (May 21, 2026)
• BleepingComputer — GitHub confirms breach of 3,800 repos via malicious VSCode extension
• SecurityWeek — Over 5,500 GitHub Repositories Infected in 'Megalodon' Supply Chain Attack
• TechCrunch — GitHub says hackers stole data from thousands of internal repositories (May 20, 2026)
• StepSecurity — Nx Console VS Code Extension Compromised
• Palo Alto Unit 42 — The npm Threat Landscape: Attack Surface and Mitigations (updated May 21, 2026)
• VS Code Docs — Extension runtime security
• Forgejo Documentation — forgejo.org/docs/
• gitleaks — github.com/gitleaks/gitleaks

Written on May 28, 2026. The landscape shifts every week — check GitHub's official sources and the Nx advisory before any critical action.

---

You'll find more practical guides in the Tech section.