Tech

GitHub-Hack im Mai 2026: 18 Minuten reichten — was das für dich heißt (und 7 Reflexe fürs Wochenende)

Am 18. Mai 2026 wurde eine manipulierte VS-Code-Extension keine 20 Minuten lang ausgespielt — und konnte rund 3 800 interne GitHub-Repos abziehen. Was wirklich passiert ist, warum es dich betrifft, auch wenn du nicht bei GitHub arbeitest, und 7 Reflexe, die du an einem Samstag umsetzt.

Disclaimer. Dieser Artikel ist eine Einordnung, keine individuelle Sicherheitsberatung. Für kritische Entscheidungen (großflächige Secret-Rotation, Post-Mortem, Meldung an BSI/Datenschutzbehörde) hol dir bitte eine:n Profi an Bord. Alle Quellen stehen unten — offizielles GitHub-Statement, Advisory nrwl/nx-console GHSA-c9j4-9m59-847w, Fachpresse Mai 2026.

18 Minuten.

Mehr brauchte es nicht.

Am 18. Mai 2026 um 12:30 UTC wurde ein manipuliertes Update einer VS-Code-Extension veröffentlicht, die von 2,2 Millionen Entwicklern genutzt wird. Um 12:48 wurde es zurückgezogen.

Zwischen diesen beiden Zeitpunkten haben Tausende Entwicklerrechner den Payload automatisch eingespielt — darunter der Rechner eines GitHub-Mitarbeiters.

Das Ergebnis 48 Stunden später: rund 3 800 interne GitHub-Repos geklont und exfiltriert.

Kein Kunden-Repo. Kein Enterprise. Nicht deine Daten. Aber die Botschaft an alle Solo-Devs, die ihr Business mit dem Stack 2026 bauen (VS Code oder Cursor + GitHub + npm + ein bisschen AWS), lautet: deine IDE ist zum schwächsten Glied geworden.

Und niemand wird sie für dich absichern.

Was wirklich passiert ist

Der Akteur heißt TeamPCP (von Google Threat Intelligence unter UNC6780 getrackt). Der Vektor: eine manipulierte Version von Nx Console v18.95.0 — eine im Angular/Nx-Ökosystem beliebte Visual-Studio-Code-Extension.

Spannend an der Geschichte ist nicht der finale Hack. Spannend ist die Kette davor.

TanStack-Kompromittierung (npm-Paket, April–Mai 2026)
        ↓ GitHub-Credentials eines Nx-Entwicklers werden gestohlen
Bösartiger Push ins offizielle nrwl/nx-console-Repo
        ↓
Veröffentlichung von Nx Console 18.95.0 im Visual Studio Marketplace
(korrekt signiert vom legitimen Publisher Nrwl)
        ↓
Stilles Auto-Update auf Tausenden Rechnern
        ↓
Diebstahl von Tokens: GitHub, npm, AWS, HashiCorp Vault, Kubernetes, 1Password
        ↓
Auf 1 Rechner = einem GitHub-Mitarbeiter: Klonen von ~3 800 internen Repos

Drei Dinge, die hängen bleiben sollten:

1. Der Publisher war legitim. Die Nrwl-Signatur hat nichts verhindert. Nicht der Marketplace wurde gehackt, sondern der Quellcode davor wurde mit gestohlenen Credentials manipuliert. Wer bisher dachte, „verifizierter Publisher = sicher", muss umlernen.

2. Der Payload zielte explizit auf KI-Tools. Unter den anvisierten Dateien: ~/.claude/settings.json. Soweit ich es überblicke, ist das einer der ersten dokumentierten Payloads, der gezielt die Konfigurationsdateien von KI-Assistenten abgreift. Das gilt analog für Cursor (~/.cursor/), Continue und alles, was sich mit Tokens in deinem Home-Verzeichnis einnistet.

3. In derselben Woche, parallel. Eine zweite Kampagne namens „Megalodon" schleuste bösartige GitHub-Actions-Workflows in 5 561 öffentliche Repos ein, alle am 18. Mai, innerhalb von sechs Stunden. Offiziell nicht dieselbe Gruppe. Aber dieselbe Woche, dasselbe Ökosystem, derselbe Druck.

Das ist kein Einzelfall mehr. Das ist ein Klima.

Warum dich das betrifft (auch ohne Nx Console)

Du denkst: „Ich nutze kein Nx, nicht mein Problem." Genau das ist der blinde Fleck.

Jede beliebige VS-Code- oder Cursor-Extension, die du installiert hast, kann morgen ein manipuliertes Update bekommen. Auto-Update ist standardmäßig still. Du kannst aufwachen und einen Payload in deiner IDE haben, ohne irgendwo geklickt zu haben.

Falls du noch zwischen den IDEs schwankst und verstehen willst, was bei Cursor wirklich auf dem Spiel steht: Ich habe die Abwägungen in Cursor 3 vs. Windsurf — IDE-Vergleich 2026 zusammengefasst.

Dann gibt es noch das indirekte, perfidere Szenario: deine transitiven npm-Dependencies. Wenn dein Stack TanStack Query, React Query, Router, Form oder Table verwendet, haben deine Builds der letzten Wochen womöglich die kompromittierte Version gezogen. Auf deinem Vercel-Runner sind dein GitHub-Token und dein Vercel-Token möglicherweise im Klartext über einen Angreiferserver gelaufen — während du seelenruhig weiter git push gemacht hast.

So sieht das Bedrohungsmodell 2026 aus: Du musst auf keinen verdächtigen Link mehr klicken. Es reicht, im Ökosystem zu existieren.

Die echte Lektion: deine IDE ist kein Werkzeug mehr, sie ist ein Perimeter

15 Jahre lang haben wir mental getrennt zwischen „ernstem Code" (Repo, GitHub, Server) und „persönlichem Komfort" (IDE, Plugins). Die IDE war gemütlich.

Diese Zeit ist vorbei.

Deine IDE:

  • liest dein ~/.ssh/,
  • liest dein gh auth-Token und deine npm-Tokens,
  • führt bei jedem Extension-Update beliebigen Code aus,
  • triggert git push und terraform apply mit Secrets, die du längst vergessen hast,
  • hängt oft an einem KI-Agenten, der seinerseits deine Dateien lesen kann.

Microsoft hat am 22. Mai 2026 reagiert und in VS Code Device Protection aktiviert: Standardmäßig wird jede Extension und jedes Paket, das in den letzten 48 Stunden veröffentlicht wurde, bei der Installation blockiert, mit automatischem Fallback auf die letzte sichere Version. GitHub hat am selben Tag Staged Publishing für npm gestartet (npm stage publish ab CLI 11.15.0): Ein gestohlenes CI-Token kann nicht mehr alleine veröffentlichen — es braucht zusätzlich eine 2FA-Freigabe durch einen Menschen.

Zwei nützliche Patches. Aber sie schützen dich nicht, wenn du nicht aktuell bist, wenn du Cursor oder Windsurf nutzt (dort gibt es Device Protection noch nicht), oder wenn der Angriff aus einer anderen Richtung kommt.

Fazit: Behandle deine Dev-Maschine wie eine Risikozone. Nicht wie einen privaten Laptop.

7 Reflexe, die du dieses Wochenende umsetzen kannst

Das sind keine Enterprise-Projekte. Das sind Schritte für Solos, machbar an einem Samstag. Sortiert von einfach zu strukturierend.

1. Liste deine Extensions auf — und schmeiß die Hälfte raus

Schau ehrlich auf die Liste. Was du nicht jede Woche nutzt? Deinstallieren, nicht deaktivieren. Eine deaktivierte Extension lässt ihren Code auf deiner Maschine; eine deinstallierte verschwindet.

Beim Rest: einen kurzen Blick auf den Publisher werfen. Sagt dir der Name nichts? Auf GitHub gegenchecken. Eine Extension mit 200 Installs und einem anonymen Publisher, der Zugriff auf deinen Workspace hat — das ist ein riesiges Risiko für kosmetischen Komfort.

2. Schalte Auto-Update ab und führe ein Quarantäne-Fenster ein

Meine persönliche Regel: kein Extension-Update in den ersten 48 Stunden nach Veröffentlichung. Automatisieren willst du das? Eine Zeile "extensions.autoUpdate": false in den Settings, und du entscheidest fallweise.

Genau das hat Microsoft jetzt zum Default gemacht. Wende es einfach selbst an, ohne auf irgendwen zu warten. 18 Minuten haben für Nx Console gereicht. 48 Stunden Quarantäne schützen dich in 99 % der Fälle.

3. Räum deine GitHub-Tokens auf

Wenn du noch klassische Personal Access Tokens (ghp_...) hast: lösch sie dieses Wochenende. Erstelle stattdessen Fine-grained PATs:

  • Scope auf ein bis zwei konkrete Repos beschränkt,
  • maximale Gültigkeit 90 Tage,
  • minimal nötige Permissions.

Für dein CI/CD (Vercel, GitHub Actions, AWS) wechselst du auf OIDC: Dein Runner tauscht bei jedem Build ein kurzlebiges JWT gegen AWS-Credentials. Kein langlebiges Token, das irgendwo herumliegt.

Wenn du auf npm veröffentlichst, aktivier Staged Publishing noch diese Woche. Kostenlos, offiziell, exakt die Antwort, die GitHub auf diesen Hack ausgerollt hat.

Falls bei dir die Basis — MFA, saubere SSH-Schlüssel, aufgeräumte Tokens — noch nicht steht, fang dort an: Dev-Accounts absichern ist das Fundament, auf dem der Rest aufbaut.

4. Trenne deinen Workspace von deiner Maschine

Auf deiner privaten Maschine liegen dein SSH, deine Passwörter, deine Fotos, dein Leben. Warum läuft deine experimentelle IDE am selben Ort?

Drei Optionen, je nach Level:

  • Am einfachsten — VS Code Dev Containers. Du codest in einem Docker-Container, der dein ~/.ssh und deine globalen Credentials nicht sieht. Schlägt eine manipulierte Extension zu, bleibt sie im Container. Setup: 30 Minuten.
  • Mittel — eine dedizierte VM. Multipass, UTM (Mac), WSL2 oder Hyper-V (Windows), VirtualBox (alle OS). Jeden Freitag einen Snapshot ziehen, bei Verdacht zurückrollen.
  • Maximal sauber — eine zweite physische Maschine ausschließlich für geschäftskritischen Code (Deployment, Signing Keys, Admin-Accounts). Ein gebrauchter Refurbished-Rechner für 200 € reicht völlig.

5. Verhindere, dass deine eigenen Secrets nach außen wandern

Mehrere kostenlose Tools scannen deinen Code lokal vor jedem Commit und blockieren vergessene Secrets (API-Keys, Tokens, Passwörter).

Die drei zuverlässigsten 2026: gitleaks (am leichtgewichtigsten, zu 100 % Open Source), ggshield von GitGuardian (deckt 550+ Secret-Typen ab, kostenloser Account nötig, Hooks für Cursor und Claude Code), TruffleHog (prüft zusätzlich, ob ein gefundenes Secret noch aktiv ist).

Alle laufen auf Windows, Mac und Linux. Wenn du neu einsteigst, starte mit ggshield oder gitleaks — Installation in 5 Minuten.

6. Hol deine Kronjuwelen aus GitHub raus

Das ist der radikalste Schritt — und derjenige, der das Bedrohungsmodell wirklich verändert.

Nicht alle deine Daten sind gleich wertvoll. Das Repo deines Blogs darf auf GitHub bleiben. Aber dein proprietärer Code (das SaaS, das du baust, deine Terraform-Configs, Playbooks mit Credentials, die Templates, die du verkaufst) — warum liegt das auf der Infrastruktur eines Drittanbieters, von dem gerade bewiesen wurde, dass er über eine IDE-Extension kompromittierbar ist?

Die seriösen Optionen: Forgejo (freier Fork von Gitea) oder Gitea, selbst gehostet auf einem VPS für 5–10 €/Monat, oder Codeberg (kostenlose Instanz, betrieben von einem deutschen Verein, ideal für Open Source).

Achtung: schlecht konfiguriertes Self-Hosting verlagert das Risiko nur. Lies die Hardening-Doku, aktivier von Anfang an 2FA + SSH-only.

7. Stell dir kostenlose Wächter auf

Du hast kein SOC. Aber GitHub gibt dir kostenlos genug, um Probleme früh zu sehen:

  • Secret Scanning Alerts auf allen privaten Repos (kostenlos seit 2023). Aktivieren in Settings → Code security.
  • Dependabot Security Updates auf allen aktiven Repos.
  • E-Mail-Alert bei jedem neuen Login von einem unbekannten Gerät.
  • Ein Extension-Journal: eine einfache Datei extensions-audit-YYYY-MM-DD.txt, datiert und am 1. jedes Monats archiviert. Beim nächsten Extension-Vorfall kannst du dein Exposure auf die Minute genau datieren.

Das Minimum, wenn du nur eine Sache tust

Du hast 30 Minuten. Die Reihenfolge:

  1. Extensions auflisten (code --list-extensions --show-versions) → Ergebnis archivieren.
  2. "extensions.autoUpdate": false in settings.json.
  3. Klassische PATs durch Fine-grained ersetzen, max. 90 Tage Laufzeit.
  4. Secret Scanning + Dependabot auf deinen Repos aktivieren.
  5. Kritische Secrets außerhalb von GitHub sichern (eine age-verschlüsselte Datei auf einer externen Festplatte reicht).

Warum ich das hier schreibe

Weil die CodingQueen40-Methode — „bau dein Tech-Business nach 40 mit den Werkzeugen von 2026" — keinen Sinn mehr ergibt, wenn man Cybersicherheit als Expertenthema behandelt. Sie ist eine Business-Kompetenz geworden.

Eine Solopreneurin, der das GitHub-Konto leergeräumt wird, verliert ihren Code, manchmal ihre Domain (wenn die E-Mail verknüpft ist), ihre Reichweite (wenn der Blog defaced wird), ihre Einnahmen für Wochen.

Der Hack der Kalenderwochen 20–21 ist kein Einzelfall. Er ist die neue Baseline. TeamPCP hat 2026 bereits 20 dokumentierte Angriffswellen gefahren. Es werden weitere folgen.

Der einzige Hebel, den wir haben, liegt im Perimeter, der uns gehört: unser Arbeitsplatz, unsere Tokens, unsere Backups.

Schönes Sicherheits-Wochenende. Los geht's.

Hauptquellen

  • GitHub Blog — Strengthening supply chain security: Preparing for the next malware campaign (Mai 2026)
  • GitHub Advisory GHSA-c9j4-9m59-847w — Compromised Nx Console version 18.95.0
  • Nx Devtools (offizieller X/Twitter-Account) — SECURITY ADVISORY: A malicious version of Nx Console v18.95.0 was published today at 2:36 PM CEST (18. Mai 2026)
  • The Hacker News — GitHub Internal Repositories Breached via Malicious Nx Console VS Code Extension (20. Mai 2026)
  • The Hacker News — npm Adds 2FA-Gated Publishing and Package Install Controls Against Supply Chain Attacks (Mai 2026)
  • Help Net Security — TeamPCP breached GitHub's internal codebase via poisoned VS Code extension (20. Mai 2026)
  • Help Net Security — GitHub, Grafana Labs breaches traced back to TanStack supply chain compromise (21. Mai 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 (20. Mai 2026)
  • StepSecurity — Nx Console VS Code Extension Compromised
  • Palo Alto Unit 42 — The npm Threat Landscape: Attack Surface and Mitigations (aktualisiert 21. Mai 2026)
  • VS Code Docs — Extension runtime security
  • Forgejo Documentation — forgejo.org/docs/
  • gitleaks — github.com/gitleaks/gitleaks

Artikel verfasst am 28. Mai 2026. Die Lage ändert sich wöchentlich — prüfe vor jeder kritischen Entscheidung die offiziellen GitHub-Quellen und das Nx-Advisory.

Denkst du über einen Einstieg in die Tech-Branche nach? Lade die kostenlose Checkliste „Tech-Neustart nach 40" herunter — 10 konkrete Schritte, um solide Grundlagen zu legen, ohne dich in den falschen Entscheidungen zu verlieren. → Checkliste kostenlos herunterladen

Weitere praktische Anleitungen findest du im Bereich Tech.