GitHub gehackt. Nicht wegen einer Zero-Day. Sondern wegen Vertrauen.

Die Cybersecurity-Branche liebt ihre Narrative. Wenn etwas schiefgeht, dann bitte wegen einer spektakulären Zero-Day, einer hochkomplexen Nation-State-Operation, einer bislang unbekannten Schwachstelle in irgendeinem exotischen Protokoll. Die Realität ist meistens deutlich banaler.

GitHub verlor im Mai 2026 Zugriff auf rund 3.800 interne Repositories, weil ein Entwickler eine manipulierte VS-Code-Erweiterung installiert hat. Kein Kernel-Exploit. Kein Hypervisor-Breakout. Kein geheimnisvoller NSA-Magie-Zauber. Ein Plugin. Ein Stück Software, das genau das getan hat, was Entwickler jeden Tag tausendfach tun: installiert, aktualisiert und vertraut.

Genau deshalb finde ich diesen Vorfall interessant. Nicht weil GitHub gehackt wurde, sondern weil GitHub auf dieselbe Art gehackt wurde wie inzwischen hunderte andere Unternehmen. Der sogenannte TeamPCP-Vorfall markiert einen weiteren Wendepunkt in der Entwicklung moderner Supply-Chain-Angriffe. Im Zentrum stand keine klassische Sicherheitslücke, sondern die Kompromittierung der Entwickler-Lieferkette selbst: Erweiterungen, Tokens, lokale Credentials, Build-Prozesse und Entwicklerarbeitsplätze. Die Bedeutung reicht weit über GitHub hinaus. Praktisch jedes Unternehmen mit modernen Entwicklungsprozessen nutzt heute vergleichbare Werkzeuge, identische Vertrauensmodelle und ähnliche CI/CD-Architekturen.

Der Angriff auf GitHub

Nach bisherigen Erkenntnissen installierte ein GitHub-Mitarbeiter eine kompromittierte Version einer VS-Code-Erweiterung. Mehrere Berichte nennen später die Erweiterung „Nx Console" als Ursprung. Die manipulierte Version war nur wenige Minuten im Marketplace verfügbar, wurde aber trotzdem installiert und ausgeführt.

Das reichte.

VS-Code-Erweiterungen laufen nicht in einer isolierten Sandbox. Sie besitzen Zugriff auf Dateien, Prozesse, Terminals, Umgebungsvariablen und häufig auch auf sämtliche Entwickler-Credentials, die lokal gespeichert sind. Genau dort setzte TeamPCP an. Nach der Installation wurden Zugangsdaten, Tokens und weitere Entwickler-Artefakte abgegriffen. Mit diesen Informationen verschafften sich die Angreifer Zugriff auf GitHub-interne Systeme und begannen anschließend damit, interne Repositories zu klonen und zu exfiltrieren. GitHub bestätigte später, dass die von den Angreifern genannten rund 3.800 Repositories „richtungsmäßig konsistent" mit den eigenen Untersuchungsergebnissen seien.

Die gestohlenen Daten wurden anschließend in einschlägigen Cybercrime-Foren zum Verkauf angeboten. Angebotspreis: 50.000 US-Dollar.

Timeline der Ereignisse

Anfang Mai 2026. Erste Hinweise auf kompromittierte VS-Code-Erweiterungen tauchen in Sicherheitsforen und Incident-Response-Communities auf.

Mitte Mai 2026. Mehrere Entwickler berichten über verdächtige Aktivitäten im Zusammenhang mit VS-Code-Extensions und ungewöhnlichen Zugriffen auf GitHub-Repositories.

18.–20. Mai 2026. Die Gruppe TeamPCP veröffentlicht Hinweise auf den erfolgreichen Zugriff auf interne GitHub-Repositories.

Kurz darauf. Die gestohlenen Daten werden in Untergrundforen zum Verkauf angeboten. Sicherheitsforscher beginnen mit der Analyse der Angriffskette.

Wenige Tage später. Weitere Kampagnen mit ähnlichen Mechanismen tauchen auf. Sicherheitsunternehmen warnen vor Copycat-Angriffen auf Entwicklerumgebungen.

GitHub war nicht das Ziel

Wer diesen Vorfall als isolierte GitHub-Panne betrachtet, hat das größere Bild nicht verstanden. GitHub war lediglich der nächste Dominostein.

TeamPCP fällt seit Monaten durch groß angelegte Supply-Chain-Angriffe auf. Betroffen waren npm-Pakete, PyPI-Repositories, GitHub Actions, Docker-Images, VS-Code-Erweiterungen und CI/CD-Umgebungen. Sicherheitsforscher sprechen inzwischen von einer der aggressivsten Software-Lieferkettenkampagnen der letzten Jahre.

Die Gruppe verfolgt dabei eine bemerkenswert einfache Strategie:

1. Entwickler kompromittieren.
2. Credentials stehlen.
3. Vertrauenswürdige Software manipulieren.
4. Neue Opfer infizieren.
5. Wiederholen.

Das Besondere daran ist nicht die technische Raffinesse, sondern die Skalierung.

Technische Analyse

Der Angriff folgte einem klassischen modernen Supply-Chain-Muster.

Die entscheidende Schwachstelle lag nicht in GitHub selbst, sondern in der hohen Vertrauensstellung von Entwicklerarbeitsplätzen. Sobald ein kompromittiertes Plugin lokal ausgeführt wird, besitzt es häufig Zugriff auf:

• GitHub Personal Access Tokens
• SSH-Keys
• Cloud-Credentials
• CI/CD-Secrets
• lokale Build-Artefakte
• Browser-Sessions
• Terminal-Historien
• Kubernetes-Konfigurationen
• Docker-Credentials

Damit wird die Entwicklerumgebung selbst zum zentralen Angriffsziel.

Der Tod des Vertrauensmodells

Die Softwarebranche basiert auf einem unausgesprochenen Vertrag. Wenn etwas im offiziellen Marketplace liegt, wird es schon sicher sein. Wenn ein Publisher verifiziert ist, wird er schon vertrauenswürdig sein. Wenn ein Paket Millionen Downloads hat, wird es schon geprüft worden sein.

2026 zerlegt diese Annahmen beinahe wöchentlich.

Die kompromittierte Erweiterung verfügte Berichten zufolge über einen legitimen Publisher-Kontext. Andere TeamPCP-Kampagnen kompromittierten bestehende Maintainer-Accounts, offizielle Build-Pipelines und etablierte Open-Source-Projekte. Teilweise wurden sogar Microsoft-nahe Softwarepakete mit Schadcode versehen.

Das bedeutet: Der Angreifer muss keine Sicherheitskontrollen umgehen. Er übernimmt schlicht die Systeme, denen die Sicherheitskontrollen bereits vertrauen.

Strukturelle Ursachen

Die Ursache des Vorfalls lässt sich nicht auf eine einzelne Fehlentscheidung reduzieren. Der Angriff wurde möglich durch eine Kombination struktureller Probleme:

• überprivilegierte Entwicklerarbeitsplätze
• langfristig gültige Tokens und Credentials
• fehlende Isolation von VS-Code-Erweiterungen
• blindes Vertrauen in Marketplace-Inhalte
• fehlende Kontrolle externer Dependencies
• zu weitreichende Rechte in CI/CD-Systemen
• lokale Speicherung sensibler Secrets
• fehlende Hardwarebindung kritischer Credentials

Die eigentliche Schwachstelle war nicht die kompromittierte Extension. Die eigentliche Schwachstelle war das Sicherheitsmodell.

Klassische Security versagt hier

Viele Unternehmen investieren Millionen in Endpoint Security, SIEM-Systeme und Vulnerability Scanner. TeamPCP interessiert das kaum. Denn die meisten dieser Werkzeuge suchen nach bekannten Schwachstellen.

Dieser Angriff hatte keine relevante CVE. Keine bekannte Sicherheitslücke. Keinen Exploit. Die Malware kam als reguläres Update über einen offiziellen Kanal.

Genau deshalb wird die aktuelle Welle von Supply-Chain-Angriffen für viele Unternehmen so gefährlich. Man kann nicht patchen, was nie verwundbar war. Man kann keine Signatur erkennen, wenn die Software mit legitimen Zertifikaten veröffentlicht wurde. Und man kann keine CVE schließen, wenn das eigentliche Problem menschliches Vertrauen ist.

Risikoanalyse

Die Auswirkungen solcher Angriffe sind erheblich. Betroffen sind nicht nur einzelne Entwickler oder Unternehmen, sondern potenziell komplette Software-Lieferketten.

Ein kompromittiertes Entwicklerkonto kann Zugriff ermöglichen auf:

• proprietären Source Code
• Kundendaten
• Signatur-Infrastrukturen
• Cloud-Umgebungen
• Produktionssysteme
• Build-Server
• Container-Registries
• interne Sicherheitswerkzeuge

Besonders kritisch ist die Möglichkeit, kompromittierte Artefakte über reguläre CI/CD-Prozesse weiterzuverbreiten. Dadurch entstehen Kaskadeneffekte, die weit über das ursprüngliche Opfer hinausreichen.

Detection Guidance

Unternehmen sollten aktuell gezielt nach folgenden Indikatoren suchen:

• ungewöhnliche VS-Code-Extension-Installationen
• unerwartete Token-Verwendungen
• neue oder unbekannte GitHub Personal Access Tokens
• verdächtige Repository-Clones
• auffällige Zugriffe auf CI/CD-Secrets
• Änderungen an Build-Pipelines
• unbekannte Prozesse innerhalb von VS Code
• auffällige Netzwerkverbindungen von Entwicklergeräten
• Änderungen an GitHub Actions
• neue SSH-Keys oder OAuth-Authorisierungen

Besondere Aufmerksamkeit verdienen Systeme mit Zugriff auf Produktions-Clouds oder zentrale Build-Infrastrukturen.

Incident-Response-Checkliste

Im Falle eines Verdachts sollten Unternehmen mindestens folgende Maßnahmen umsetzen:

1. alle Entwickler-Tokens sofort rotieren
2. GitHub PATs widerrufen
3. CI/CD-Secrets erneuern
4. OAuth-Authorisierungen prüfen
5. VS-Code-Erweiterungen inventarisieren
6. Build-Systeme auf Manipulation untersuchen
7. SSH-Keys austauschen
8. Audit-Logs sichern
9. Entwicklergeräte forensisch analysieren
10. Repository-Integrität überprüfen
11. Cloud-Credentials rotieren
12. Netzwerk-Telemetrie auswerten

Geschwindigkeit ist dabei entscheidend. Supply-Chain-Angriffe eskalieren häufig innerhalb weniger Stunden.

Die unbequemen Inventur-Fragen

Jedes Unternehmen mit Entwicklerarbeitsplätzen sollte sich aktuell einige unangenehme Fragen stellen.

Welche VS-Code-Erweiterungen wurden in den letzten Wochen installiert? Welche Erweiterungen wurden automatisch aktualisiert? Welche GitHub-Tokens existieren noch? Welche Personal Access Tokens besitzen unnötige Rechte? Welche CI/CD-Secrets wurden jemals auf Entwicklergeräten verwendet? Welche Cloud-Credentials liegen lokal auf Notebooks? Welche SSH-Keys sind älter als zwölf Monate? Welche Build-Systeme vertrauen blind auf externe Abhängigkeiten?

Diese Fragen sind deutlich wichtiger als die Frage, ob man direkt von TeamPCP betroffen war. Denn dieselbe Angriffstechnik wird inzwischen von Nachahmern übernommen.

Die neue Realität für Entwickler

Lange Zeit galt die Entwicklerumgebung als vertrauenswürdiger Bereich. Das war ein Fehler.

Entwickler besitzen heute Zugriff auf Cloud-Infrastrukturen, Produktionssysteme, Kubernetes-Cluster, CI/CD-Pipelines, Source-Code-Repositories, Signing-Keys und Geheimnisse aller Art. Für Angreifer ist ein Entwicklergerät inzwischen oft wertvoller als ein Domain Controller. Genau deshalb verlagern sich moderne Angriffe immer stärker in diese Richtung.

Der Browser wird ersetzt durch die IDE. Der Office-Anhang wird ersetzt durch die VS-Code-Erweiterung. Der Makro-Trojaner wird ersetzt durch das npm-Paket.

Die Technik ändert sich. Das Grundprinzip bleibt identisch.

Das Vertrauensmodell muss sterben

Die unbequeme Wahrheit lautet: Die Branche wird dieses Problem nicht mit „mehr Awareness" lösen.

Entwickler wissen längst, dass Supply-Chain-Angriffe existieren — genauso wie Anwender seit zwanzig Jahren wissen, dass Phishing existiert. Trotzdem funktionieren diese Angriffe weiterhin, weil moderne Entwicklungsumgebungen strukturell auf blindem Vertrauen basieren.

Genau dieses Modell muss sich ändern.

Entwickler-Workstations dürfen nicht länger als vollständig vertrauenswürdige Systeme betrachtet werden. Wer Zugriff auf Produktions-Clouds, CI/CD-Systeme, Signing-Keys und interne Repositories besitzt, arbeitet faktisch auf einem privilegierten Administrationssystem. Trotzdem laufen auf denselben Geräten Slack, Browser-Plugins, AI-Tools, VS-Code-Erweiterungen und unkontrollierte npm-Abhängigkeiten. Sicherheitstechnisch ist das Wahnsinn.

Unternehmen werden akzeptieren müssen, dass Entwicklerumgebungen künftig deutlich stärker kontrolliert werden müssen. Nicht aus Misstrauen gegenüber Entwicklern, sondern weil Entwickler heute eines der wertvollsten Ziele überhaupt darstellen.

Dazu gehört:

• keine lokalen Adminrechte ohne technische Notwendigkeit
• keine dauerhaften Cloud-Credentials auf Endgeräten
• keine unkontrollierten VS-Code-Extensions aus öffentlichen Marketplaces
• keine langfristigen GitHub-Tokens
• keine Build-Pipelines, die blind beliebige externe Dependencies ausführen
• keine impliziten Vertrauensketten

Jede Erweiterung, jedes Paket, jede GitHub Action und jedes Build-Artefakt muss künftig als potenziell kompromittiert betrachtet werden. Das bedeutet nicht, dass Open Source das Problem ist. Das Problem ist die naive Automatisierung von Vertrauen.

Die Branche hat sich daran gewöhnt, täglich fremden Code direkt in privilegierten Entwicklungsumgebungen auszuführen — oft völlig ungeprüft. Genau diese Kultur rächt sich jetzt.

Die Konsequenz daraus wird unbequem: mehr Isolation, mehr Sandboxing, mehr signierte Artefakte, mehr reproduzierbare Builds, mehr kurzlebige Credentials, mehr Hardware-gebundene Authentifizierung, mehr Zero-Trust-Prinzipien innerhalb der Entwicklerumgebung selbst.

Viele Entwickler werden das als Einschränkung empfinden. Die Alternative sieht man gerade live: Wenn ein einzelnes manipuliertes Plugin ausreicht, um Zugriff auf tausende interne Repositories eines der größten Softwareunternehmen der Welt zu erhalten, dann ist nicht das Plugin das eigentliche Problem. Dann ist das gesamte Sicherheitsmodell kaputt.

Präventionsstrategien

Unternehmen sollten moderne Entwicklerumgebungen künftig wie hochkritische Produktionssysteme behandeln. Dazu gehören:

• Härtung von Entwicklerarbeitsplätzen
• Device-Binding von Credentials
• verpflichtende Hardware-Authentifizierung
• isolierte Build-Umgebungen
• reproduzierbare Builds
• minimale Rechte für CI/CD-Systeme
• vollständige Dependency-Transparenz
• zentral kontrollierte Extension-Repositories
• verpflichtende Code-Signing-Prozesse
• aggressive Secret-Rotation
• kontinuierliches Monitoring von Entwicklerumgebungen

Besonders wichtig wird künftig die Reduktion impliziten Vertrauens. Zero Trust darf nicht an der Entwicklerumgebung enden.

Fazit

Der GitHub-Vorfall ist keine Geschichte über GitHub. Er ist eine Geschichte über Vertrauen. Über ein Ökosystem, das sich daran gewöhnt hat, Millionen Zeilen fremden Codes automatisch zu installieren. Über Entwickler, die Erweiterungen installieren wie früher Browser-Plugins. Über Unternehmen, die Signaturen und Publisher-Badges mit Sicherheit verwechseln.

TeamPCP hat keine neue Schwachstelle entdeckt. Sie haben lediglich gezeigt, wie fragil die moderne Software-Lieferkette geworden ist. Und genau das macht diesen Vorfall gefährlicher als viele klassische Sicherheitslücken.

Eine Zero-Day kann gepatcht werden. Ein kaputtes Vertrauensmodell nicht.