GitHub gehackt: Wie eine vergiftete VS Code Extension 3.800 interne Repos kompromittiert hat

Dieser Beitrag fasst den Vorfall rund um den GitHub-internen Repository-Breach vom 18. Mai 2026 zusammen. Die technischen Details stammen primär aus dem offiziellen Postmortem von Nx sowie aus GitHubs öffentlicher Stellungnahme auf X.

Der Vorfall ist einer der gravierendsten Supply Chain Angriffe der letzten Jahre. Er betrifft direkt jeden Entwickler, der VS Code, Cursor oder einen anderen Editor mit Extensions und Auto-Updates nutzt. Die Lehren daraus sind unbequem, aber essenziell.

Was passiert ist

Am 18. Mai 2026 erschien eine manipulierte Version der Nx Console VS Code Extension (v18.95.0) im Visual Studio Marketplace. Sie war zwischen 11 und 18 Minuten live, bevor sie entfernt wurde. Auf OpenVSX waren es 36 Minuten. Das war mehr als genug.

Ein GitHub-Mitarbeiter hatte die Extension mit aktiviertem Auto-Update installiert. Die vergiftete Version lief auf seiner Maschine, sammelte Credentials ein und verschaffte den Angreifern Zugang zu rund 3.800 internen GitHub Repositories. Die Hackergruppe TeamPCP (auch als UNC6780 geführt) reklamierte den Angriff auf dem Breached Cybercrime Forum und bot den gestohlenen Code für mindestens 50.000 Dollar an.

GitHub bestätigte den Breach in einer öffentlichen Stellungnahme: Die Aktivität betraf ausschließlich interne GitHub Repositories. Die Behauptung der Angreifer von rund 3.800 Repositories sei mit den eigenen Untersuchungsergebnissen konsistent. Es gebe keine Hinweise darauf, dass Kundendaten betroffen seien. Die Untersuchung läuft noch.

Wie der Angriff technisch funktionierte

Die Kompromittierung der Nx Console begann nicht am 18. Mai. Die Kette reicht zurück bis zum 11. Mai. An diesem Tag führte TeamPCP eine Supply Chain Attack auf das TanStack npm-Ökosystem aus. Dabei wurden manipulierte Pakete veröffentlicht, darunter @tanstack/zod-adapter.

Ein Contributor der Nx Console installierte dieses Paket bei einem routinemäßigen pnpm install auf seiner Maschine. Eine Sicherheitsvorkehrung namens Minimum Release Age, die das hätte blockieren sollen, wurde von einer älteren pnpm-Version stillschweigend ignoriert. Die Konfigurationsoption war schlicht wirkungslos. Der GitHub CLI OAuth Token des Contributors wurde dabei gestohlen.

Sieben Tage später wurde dieser Token genutzt, um die manipulierte Nx Console Version zu veröffentlichen. Die Payload bestand aus 2.777 Bytes, injiziert in eine minifizierte JavaScript-Datei. Sie lud einen 498 KB großen, obfuskierten Dropper aus einem Orphan Commit nach. Das Ziel waren GitHub Tokens, npm Tokens, AWS- und GCP-Credentials, SSH Keys, Vault Tokens und Passwörter. Die Exfiltration erfolgte über HTTPS und DNS-Tunneling.

Am selben Tag veröffentlichte dieselbe Kampagne 637 manipulierte npm-Paketversionen unter dem AntV-Namespace.

Wer TeamPCP ist

Das ist kein Einzelfall. TeamPCP hat ein dokumentiertes Muster extrem schneller Supply Chain Angriffe gegen Entwicklerinfrastruktur. Bisherige Ziele umfassen den Aqua Security Trivy Vulnerability Scanner, die AWS-Infrastruktur der Europäischen Kommission über die Trivy-Kompromittierung, LiteLLM, OpenAI-Mitarbeitergeräte über die TanStack-Plattform, Mistral AI Quellcode sowie Angriffe auf PyPI, npm und Docker-Ökosysteme.

Das Muster ist konsistent. Vertrauenswürdige Update-Mechanismen ausnutzen, gestohlene Credentials verwenden, extrem schnell agieren und exfiltrieren, bevor Verteidiger reagieren können.

Das fundamentale VS Code Extension Problem

Der Nx Console Vorfall legt ein Problem offen, auf das die Security-Community seit Jahren hinweist. Der VS Code Marketplace hat keinen nennenswerten Security-Review-Prozess. Es gibt keinen Kill-Switch für bereits installierte Versionen. Es gibt keinen Mechanismus, der Nutzer benachrichtigt, wenn eine installierte Extension nachträglich als bösartig identifiziert wird.

Auto-Update ist standardmäßig aktiviert. Extensions laufen mit weitreichenden Systemberechtigungen. Und weil sie als Klartext-Artefakte vorliegen statt als kompilierte Binaries, erkennen klassische EDR-Tools bösartiges Verhalten häufig nicht.

Das Postmortem der Nx Console identifiziert mehrere beitragende Fehler. Die vorgelagerte TanStack-Kompromittierung. Eine stillschweigend wirkungslose pnpm-Konfiguration. Lokal gespeicherte GitHub CLI Credentials. Und eine Publish-Pipeline ohne Approval Gate mit nur einer einzigen Person.

Die Parallele zur Softwareentwicklung mit KI-Agenten ist offensichtlich. Genauso wie wir bei der Vibe-Coding-Falle gelernt haben, dass blinde Übernahme von generiertem Code zu unsichtbaren Problemen führt, zeigt dieser Vorfall, dass blindes Vertrauen in automatisierte Update-Mechanismen fatale Konsequenzen hat. In beiden Fällen ist die Geschwindigkeit das Problem. Sie fühlt sich gut an, aber sie unterläuft die Kontrolle.

Was Entwickler jetzt tun sollten

Wer die Nx Console am 18. Mai 2026 mit aktivierten Auto-Updates installiert hatte, muss sofort handeln.

Extension auf eine saubere Version aktualisieren. Verdächtige Prozesse beenden. Persistente Artefakte entfernen und auf unautorisierte systemd-Services prüfen.

Alle Credentials rotieren. GitHub Tokens, npm Tokens, AWS-, GCP- und Azure-Keys, SSH-Keys und alles, was in Umgebungsvariablen oder Konfigurationsdateien gespeichert ist. Ohne Ausnahme.

GitHub Repositories auf unautorisierte Aktivitäten prüfen. Unerwartete Workflow-Runs, neue Deploy Keys oder veränderte Secrets sind klare Warnsignale.

Lektionen für die Zukunft

Über den akuten Vorfall hinaus muss sich die Arbeitsweise verändern. Das sind die konkreten Empfehlungen aus dem Nx Console Postmortem und der Security-Community.

Auto-Updates für Extensions deaktivieren. Oder zumindest ein Tool einsetzen, das eine Verzögerung vor der Installation neuer Versionen erzwingt. StepSecurity Dev Machine Guard scannt Extensions in VS Code, Cursor, Windsurf, JetBrains IDEs, Android Studio, Eclipse und Xcode auf Supply Chain Signale. Aikido Security Device Protection hält neue Pakete und Extensions standardmäßig 48 Stunden zurück.

Publish-Pipelines mit Approval Gates absichern. Kein einzelner Contributor sollte in der Lage sein, eine neue Version allein zu veröffentlichen. Zwei-Personen-Freigabe ist das Minimum.

GitHub Action SHAs pinnen. Keine Tags oder Branch-Referenzen für Actions verwenden. Nur gepinnte Commit-Hashes sind manipulationssicher.

Credentials nicht lokal im Klartext speichern. GitHub CLI OAuth Tokens, npm-Tokens und Cloud-Credentials gehören in einen Credential Manager oder Hardware-Token. Nicht in Konfigurationsdateien auf der lokalen Festplatte.

Der Kern des Problems

11 Minuten haben gereicht. Die Angriffsfläche wird nicht kleiner. Die Marketplace-Infrastruktur hat sich nicht grundlegend verändert. Bis das passiert, ist die sicherste Annahme, dass jede Extension mit einem kürzlichen Update potenziell kompromittiert sein könnte.

Wir vertrauen unseren Entwicklertools implizit. Dieses Vertrauen ist nicht mehr gerechtfertigt. So wie wir im Kontext von Agentic Coding gelernt haben, dass KI-generierter Output immer menschlicher Kontrolle bedarf, muss das Gleiche für die Software gelten, die wir installieren. Vertrauen ist keine Strategie. Kontrolle ist eine.