GitHub durch VS-Code-Erweiterung kompromittiert (Mai 2026): Der 60-Minuten-Notfallplan für Entwickler

GitHub durch VS-Code-Erweiterung kompromittiert (Mai 2026): Der 60-Minuten-Notfallplan für Entwickler

Am 20. Mai 2026 bestätigte GitHub, dass rund 3.800 interne Quellcode-Repositories über eine schadhafte VS-Code-Erweiterung exfiltriert wurden, die auf dem Arbeitsrechner eines Mitarbeiters installiert war. Wer in den letzten 14 Tagen ein GitHub-PAT oder einen npm-Token in VS Code verwendet hat, für den zählen jetzt die nächsten 60 Minuten. Das ist der Plan: Was tatsächlich passiert ist, ob Sie betroffen sind, und was Sie zuerst rotieren müssen.

Die wichtigsten Punkte im Überblick

• Was geschah: GitHub.com-Produktionssysteme wurden nicht kompromittiert — ein Mitarbeiter installierte eine präparierte VS-Code-Erweiterung (höchstwahrscheinlich Nx Console v18.95.0), die PATs abgriff und ~3.800 interne Repositories exfiltrierte.
• Kundendaten: Nicht betroffen. Die kompromittierten Daten sind GitHubs interner Quellcode, kein Kundencode und keine Kundenkonten.
• Wer gefährdet ist: Jeder Entwickler, der zwischen ungefähr dem 18. Mai, 12:36 Uhr UTC, und dem 18. Mai, 12:47 Uhr UTC, eine VS-Code-Erweiterung installiert oder automatisch aktualisiert hat (11-Minuten-Fenster) — oder wer langlebige GitHub-PATs innerhalb von VS Code verwendet.
• Was jetzt zu tun ist: GitHub-PATs zuerst rotieren, npm-Token als zweites, AWS/Cloud-Schlüssel als drittes — vollständiger Plan im Abschnitt „Was Entwickler jetzt tun müssen".

TL;DR: Die 6 Maßnahmen der nächsten Stunde

Den schnellsten Weg, den Schaden durch den GitHub-VS-Code-Erweiterungs-Hack einzugrenzen, bieten sechs Maßnahmen: Zugangsdaten rotieren, die eine schadhafte Erweiterung erreichen kann, installierte Erweiterungen prüfen und das GitHub-Org-Log auf das Zeitfenster 18.–20. Mai UTC kontrollieren. Sechs Aktionen, nach Wirkung priorisiert, in dieser Reihenfolge.

1. Widerrufen Sie jeden GitHub Personal Access Token, der in den letzten 30 Tagen in VS Code erstellt oder verwendet wurde.
2. Rotieren Sie npm-Token via npm token revoke und stellen Sie sie mit 2FA und Trusted Publishing neu aus.
3. Scannen Sie Ihren Rechner auf IoCs aus GHSA-c9j4-9m59-847w (Dateipfade, Prozesse; Befehle unten).
4. Prüfen Sie code --list-extensions --show-versions und deinstallieren Sie alles, was Sie nicht begründen können.
5. Versionieren Sie Erweiterungen in devcontainer.json fest und erzwingen Sie eine Allowlist auf Org-Ebene.
6. Kontrollieren Sie das GitHub-Org-Audit-Log auf unbekannte Repository-Pushes zwischen dem 18. und 20. Mai UTC.

Wenn Sie nur Zeit für zwei Maßnahmen haben: #1 und #3. Der Rest kann eine Stunde warten.

Hat GitHub wirklich einen Hack erlitten? Was die Schlagzeilen falsch machen

Nein, die Produktionsinfrastruktur von GitHub.com wurde am 20. Mai 2026 nicht kompromittiert. Der Arbeitsrechner eines einzelnen GitHub-Mitarbeiters wurde kompromittiert, nachdem dieser eine schadhafte VS-Code-Erweiterung installiert hatte (höchstwahrscheinlich Nx Console v18.95.0). Die Angreifergruppe, die sich TeamPCP nennt (nachverfolgt als UNC6780), exfiltrierte rund 3.800 interne GitHub-Quellcode-Repositories. Kundencode, Kundenkonten und GitHubs Produktionsdienste sind nicht betroffen.

Was tatsächlich passiert ist — und was nicht.

Warum diese Unterscheidung wichtig ist: Die Lehre lautet nicht „github gehackt". Die Lehre lautet, dass Entwickler-Endpunkte die verwundbare Flanke jeder Engineering-Organisation sind. Sämtliche Geheimnisse des Teams (GitHub-PATs, npm-Token, AWS-Schlüssel, Vault-Sessions, KI-Provider-Schlüssel) liegen auf einem Laptop mit kaum nennenswerter EDR-Abdeckung. Eine einzige präparierte Erweiterung, die in Ihrer IDE läuft, erbt all das.

GitHubs eigene Sprecherin, zitiert in Bleeping Computer, bestätigte die Framing als Mitarbeiter-Endpunkt-Vorfall und die Aussage „keine Kundendaten". Help Net Security ergänzte die TeamPCP-Zuschreibung. Die technische Nachverfolgung der Erweiterung ist im Advisory GHSA-c9j4-9m59-847w dokumentiert.

GitHub.com wurde nicht kompromittiert. Ein GitHub-Mitarbeiter wurde es. Behalten Sie diesen Rahmen im Kopf, während Sie den Rest lesen.

Was tatsächlich geschah: Chronologie des Mai-2026-Vorfalls

Der GitHub-Breach-2026 entfaltete sich in vier Phasen über rund 48 Stunden. Eine präparierte Erweiterung wurde am 18. Mai um 12:36 Uhr UTC veröffentlicht, elf Minuten später entfernt, am nächsten Tag von GitHub erkannt und am 20. Mai öffentlich bekannt gegeben. Die kompakte Chronologie mit Quellen:

Das 11-Minuten-Fenster ist das merkwürdigste Detail. Es deutet darauf hin, dass der Angreifer Erweiterungen rotierte, um der Marketplace-Erkennung zu entgehen — dasselbe Muster, das Koi Security beim GlassWorm-OpenVSX-Wurm im Oktober 2025 dokumentierte. TeamPCP / UNC6780 hat zuvor 2026er Kompromittierungen gegen Trivy, KICS, LiteLLM, TanStack und MistralAI beansprucht. Gleiche Gruppe, gleiche Vorgehensweise, andere Ziele.

Letzten Monat waren es Vercels Umgebungsvariablen. Heute sind es GitHubs Repositories. Das Muster, das wir über 9 Monate beobachtet haben, verlagert den Explosionsradius weiter nach außen. Unsere Analyse der Vercel-Breach-Reaktion behandelt den parallelen Vorfall.

Die wahrscheinliche Ursache: Nx Console v18.95.0 (und warum GitHub es nicht offiziell bestätigt)

GitHub hat die in der Mitarbeiter-Endpunkt-Kompromittierung involvierte Erweiterung offiziell nicht benannt. Die forensischen Belege weisen stark auf Nx Console v18.95.0 hin, aber dies bleibt höchstwahrscheinlich, nicht bestätigt. Wir aktualisieren diesen Beitrag, wenn GitHub eine andere Erweiterung offiziell benennt. Behandeln Sie den Rest dieses Abschnitts als bestmögliche Attribution, nicht als Tatsachenfeststellung.

Vier Indizien verknüpfen Nx Console mit der GitHub-Offenlegung:

1. Zeitliche Übereinstimmung: Das Fenster des GHSA-c9j4-9m59-847w-Advisories (18. Mai, 12:36–12:47 Uhr UTC) liegt innerhalb des Kompromittierungsfensters des GitHub-Mitarbeiter-Endpunkts in GitHubs eigener Offenlegung.
2. Forensische IoC-Übereinstimmung: StepSecuritys veröffentlichte Nx-Console-Payload-Analyse (Dateipfade, Prozesse wie __DAEMONIZED, Netzwerk-Endpunkte) stimmt mit den Artefakten überein, die auf dem kompromittierten Endpunkt laut Wizs Bericht beobachtet wurden.
3. TeamPCP-Attributionsmuster: TeamPCP / UNC6780 ist im VS-Code-Supply-Chain-Bereich aktiv (Trivy, KICS, LiteLLM, TanStack, MistralAI in 2026) mit einer konsistenten Payload-Struktur.
4. Das 11-Minuten-Entfernungsfenster: Charakteristisch für Supply-Chain-Angriffe, bei denen der Angreifer den Veröffentlichungszeitpunkt kontrolliert, der Marketplace die Erweiterung aber schnell erkennt.

Wer Nx Console nicht installiert hat, ist trotzdem nicht automatisch sicher. Das breitere Angriffsmuster (__DAEMONIZED-Prozesse, IMDS-Missbrauch, ~/.claude/settings.json-Exfiltration) lässt sich auf jede präparierte Erweiterung übertragen. Die Triage im nächsten Abschnitt gilt unabhängig davon, welche Erweiterung Sie in Verdacht haben.

Sind Sie betroffen? Die 5-Minuten-Triage

Drei schnelle Tests: (1) Haben Sie zwischen dem 18. Mai, 12:36 Uhr UTC, und 12:47 Uhr UTC eine VS-Code-Erweiterung installiert oder automatisch aktualisiert? (2) Befinden sich IoC-Dateien aus GHSA-c9j4-9m59-847w aktuell auf Ihrem Rechner? (3) Haben Sie in den letzten 14 Tagen ein GitHub-PAT innerhalb von VS Code verwendet? Führen Sie alle drei in unter fünf Minuten aus.

Test 1 — Erweiterungs-Audit

# Alle installierten Erweiterungen mit Versionen auflisten
code --list-extensions --show-versions

# Gezielt auf Nx Console v18.95.0 prüfen
code --list-extensions --show-versions | grep -i "nrwl.angular-console\|nx-console"

Alles, was sich zwischen dem 17. und 18. Mai automatisch aktualisiert hat, verdient einen zweiten Blick. Wenn Sie Nx Console exakt in Version 18.95.0 sehen, sind Sie ein wahrscheinlicher Treffer. Die gepatchte Version ist 18.100.0. Entweder sofort deinstallieren oder direkt zum Notfallplan unten springen.

Test 2 — IoC-Scan

# Nach Artefakten des daemonisierten Credential-Harvest-Prozesses suchen (GHSA-c9j4-9m59-847w)
ps aux | grep -i "__DAEMONIZED" | grep -v grep
ls -la ~/.local/share/kitty/ 2>/dev/null
find ~ -name "*.daemonized*" 2>/dev/null

# IMDS-Missbrauch-Indikator (AWS-Credential-Harvest)
# Shell-History auf unerwartete curl-Aufrufe an 169.254.169.254 prüfen
grep -E "169\.254\.169\.254|metadata\.google\.internal" ~/.zsh_history ~/.bash_history 2>/dev/null

Ein sauberer Rechner sollte beim __DAEMONIZED-Grep nichts zurückgeben, keine .daemonized-Dateien und keine IMDS-Treffer in Ihrer Shell-History zeigen. Wenn eines davon anschlägt: Gehen Sie davon aus, dass der Laptop kompromittiert ist, und behandeln Sie jeden Zugangsdatensatz, den er in den letzten 30 Tagen berührt hat, als verbrannt.

Test 3 — PAT-Exposition

Wenn Sie in den letzten 14 Tagen ein GitHub-PAT (klassisch oder fein-granuliert) in einem VS-Code-Terminal, integrierten Git-Client oder einer Erweiterung, die die GitHub-API aufruft, verwendet haben: Gehen Sie von einer Kompromittierung aus und führen Sie den Rotationsplan unten aus. Das ist die konservative Standardannahme — Sie können nicht auditieren, ob der Token im Speicher war, während die Erweiterung aktiv war. Rotieren Sie ihn.

Wenn Sie Claude Code verwenden, nennt die IoC-Liste ausdrücklich ~/.claude/settings.json. Unser Claude-Code-Hooks-Leitfaden erklärt, was in dieser Datei gespeichert ist und welche Schlüssel zuerst zu rotieren sind.

Fazit. Wenn einer dieser drei Tests positiv ausfällt, hören Sie auf, den Bericht zu lesen. Gehen Sie direkt zum Notfallplan im nächsten Abschnitt. Die nächsten 55 Minuten zählen mehr als die Nachbesprechung.

Was Entwickler jetzt tun müssen: Der 60-Minuten-Notfallplan

Zugangsdaten in Prioritätsreihenfolge rotieren. Tier 0 (nächste 30 Minuten): GitHub-PATs und npm-Token. Tier 1 (heute): AWS/Cloud-Schlüssel, 1Password/Vault, GitHub-Actions-Secrets. Tier 2 (diese Woche): Drittanbieter-SaaS, OAuth-Grants, SSH-Schlüssel. Tier 3 (wenn es passt): Lese- und öffentliche Schlüssel. Jede Stufe entspricht einer konkreten Reduktion des Explosionsradius.

SOFORT: Wenn Sie betroffen sind

Wenn Ihre Triage positiv war, führen Sie diese drei Maßnahmen in dieser Reihenfolge aus, bevor Sie irgendetwas anderes tun.

1. Den Daemon beenden und die verdächtige Erweiterung deinstallieren:

# Schadhaften Payload beenden (GHSA-c9j4-9m59-847w)
pkill -f __DAEMONIZED
pkill -f "nx-console.*18.95.0"

# Verdächtige Erweiterung sofort deinstallieren
code --uninstall-extension nrwl.angular-console

1. Netzwerkkabel des Laptops ziehen, wenn Sie Hinweise auf aktive Exfiltration haben. Das klingt extrem. Es ist so gemeint. Sie können offline weiter untersuchen.
2. Sicherheitsteam kontaktieren oder in #security im Slack posten, bevor Sie irgendetwas anderes ausführen. Wenn Sie allein arbeiten, springen Sie direkt zu Tier 0.

Tier 0 (nächste 30 Minuten): GitHub + npm

GitHub-PAT-Widerruf über die gh-CLI und die Web-Einstellungs-UI:

# Authentifizierungsstatus prüfen
gh auth status

# App-Installationen auflisten, auf die der Token Zugriff hat (hilft, Explosionsradius zu inventarisieren)
gh api -H "Accept: application/vnd.github+json" /user/installations

# Die gh-CLI kann klassische PATs nicht direkt widerrufen — Web-UI verwenden:
#   https://github.com/settings/tokens
# "Revoke" bei JEDEM Token klicken. Keinen "wahrscheinlich sicheren" Token behalten.

# Mit fein-granulierten PATs + ≤90-Tage-Ablauf neu ausstellen:
#   https://github.com/settings/personal-access-tokens/new
# Ein Repository nach dem anderen scopten, niemals das gesamte Konto.

# Für org-eigene PATs und Installationen:
gh api /orgs/{ORG}/installations

npm-Token-Rotation:

# Alle npm-Token auflisten und widerrufen
npm token list
npm token revoke <token-id-1>
npm token revoke <token-id-2>

# 2FA für Auth und Schreibvorgänge erzwingen
npm profile enable-2fa auth-and-writes

# Für CI: auf OIDC Trusted Publishing migrieren — keine langlebigen Token mehr
# Docs: https://docs.npmjs.com/trusted-publishers

Wenn Sie veröffentlichte Pakete pflegen, ist Ihr npm-Token der gefährlichste Zugangsdatensatz, den Sie besitzen. Rotieren Sie ihn vor AWS.

Tier 1 (heute): Cloud + Vaults + CI-Secrets

AWS-Zugriffsschlüssel kommen als nächstes. Die IoCs zeigen IMDS-Missbrauch, daher gilt jeder IAM-Benutzer, der den kompromittierten Endpunkt berührt hat, als verdächtig:

# Zugriffsschlüssel für den aktuellen IAM-Benutzer auflisten
aws iam list-access-keys --user-name $(aws sts get-caller-identity --query 'Arn' --output text | cut -d/ -f2)

# Alten Schlüssel deaktivieren (noch nicht löschen — Workloads zuerst laut fehlschlagen lassen)
aws iam update-access-key --access-key-id AKIA... --status Inactive --user-name <user>

# Neuen Schlüssel erstellen
aws iam create-access-key --user-name <user>

# Nach Deployment und Verifikation alten Schlüssel löschen
aws iam delete-access-key --access-key-id AKIA... --user-name <user>

# Wenn eine EC2-Instanz IMDSv1 verwendete, sofort IMDSv2 erzwingen
aws ec2 modify-instance-metadata-options --instance-id i-... --http-tokens required

1Password CLI: Von jedem Gerät abmelden (op signout --all), Session-Token regenerieren und kürzliche Vault-Zugriffe über 1Passwords Web-Audit-Log auf Aktivitäten vom kompromittierten Endpunkt prüfen.

HashiCorp Vault: Eigenen User-Token widerrufen (vault token revoke -self) und von einem Admin einen neuen mit kürzerer TTL ausstellen lassen.

GitHub-Actions-Secrets: Wenn rotierte Zugangsdaten auch in Actions vorhanden sind, dort aktualisieren. gh secret set GITHUB_PAT --body <new-pat> pro Repository oder das Org-Level-UI für Org-Secrets verwenden.

Anthropic- und OpenAI-API-Schlüssel: Die IoC-Liste von GHSA-c9j4-9m59-847w nennt ausdrücklich ~/.claude/settings.json als Ernte-Ziel. Anthropic-Konsolen-API-Schlüssel widerrufen und neu ausstellen — ebenso jeden OpenAI-Schlüssel, der jemals in dieser Datei gespeichert war.

Tier 2 (diese Woche): SSH + OAuth + Passwort-Vaults

SSH-Schlüssel bewegen sich langsamer, sind aber trotzdem im Scope. Die Erweiterung hatte Dateisystem-Lesezugriff auf ~/.ssh/:

# Vorhandene SSH-Schlüssel prüfen (wann wurden sie generiert?)
for key in ~/.ssh/id_*; do
  if [ -f "$key" ]; then
    echo "Key: $key"
    stat -c '%y' "$key" 2>/dev/null || stat -f '%Sm' "$key"
  fi
done

# Neuen Ed25519-Schlüssel generieren
ssh-keygen -t ed25519 -C "rotated-$(date +%Y%m%d)" -f ~/.ssh/id_ed25519_new

# Öffentlichen Schlüssel zu GitHub hochladen
gh ssh-key add ~/.ssh/id_ed25519_new.pub --title "rotated-$(date +%Y%m%d)"

# Alten Schlüssel über Web-UI bei GitHub löschen, dann SSH-Verbindung prüfen
ssh -T [email protected]

Browser-Passwortmanager und OS-Schlüsselbund: Jedes Passwort rotieren, das die Erweiterung plausiblerweise über die Zwischenablage gesehen haben könnte. Die realistische Exposition betrifft Passwörter, die Sie in die Zwischenablage kopiert haben, während die Erweiterung aktiv war.

Tier 3 (bei Gelegenheit): Audit + Verifikation

GitHub-Org-Log für das Kompromittierungsfenster prüfen. Dafür sind Org-Admin-Rechte erforderlich:

# Push-Events für das Fenster 18.–20. Mai abrufen
gh api -X GET /orgs/{ORG}/audit-log \
  --paginate \
  -f phrase='action:repo.push created:2026-05-18..2026-05-20' | jq '.[] | {actor, created_at, repo}'

# Verdächtige Commits stichprobenartig prüfen (unbekannte Autoren, große Diffs)
gh api -X GET /repos/{ORG}/{REPO}/commits \
  -f since=2026-05-18T00:00:00Z \
  -f until=2026-05-20T23:59:59Z | jq '.[] | {sha, author: .commit.author, message: .commit.message}'

# OAuth-Grants auffrischen
gh auth refresh -s admin:org -s admin:public_key

Wenn das Audit-Log Pushes aus dem Kompromittierungsfenster zeigt, die Sie nicht vorgenommen haben: Eskalieren Sie an Ihr Sicherheitsteam und sichern Sie das Audit-Log-JSON. Versuchen Sie nicht, im Repository irgendetwas „rückgängig zu machen". Beweise zuerst sichern.

Dieselbe gestaffelte Rotationslogik haben wir für den Vercel-Env-Var-Breach im April beschrieben: gleiche Struktur, andere Ebene.

Das 5-Fragen-Framework für Erweiterungs-Audits (dauerhaft anwenden)

Bevor Sie eine VS-Code-Erweiterung installieren oder ihr vertrauen, prüfen Sie sie anhand von fünf Kriterien: Alter der Publisher-Domain, Versions-Velocity, package.json-Activation-Events, Berechtigungs-Scope versus erwartetes Verhalten und Open-Source-Repo-Audit. Nx Console v18.95.0 hätte Test #2 nicht bestanden: Ein plötzlicher Versionssprung nach einer stabilen Release-Kadenz ist das klassische Supply-Chain-Signal.

1. Alter der Publisher-Domain. Ist die Domain des Publishers älter als ein Jahr? Neue Publisher auf neu registrierten Domains tragen ein höheres Risiko. Über die Visual Studio Marketplace-Publisher-Seite oder whois auf der Domain der Publisher-E-Mail prüfen.
2. Versions-Velocity. Zeigt die Versionshistorie eine normale Kadenz (ein Release alle 1–4 Wochen) oder einen plötzlichen Anstieg (drei Releases in 24 Stunden)? Plötzliche Velocity ist ein Signal. Nx Console v18.95.0 war eine Velocity-Anomalie.
3. package.json-Activation-Events. Die .vsix-Datei öffnen (es ist ein ZIP-Archiv) und activationEvents lesen. Erweiterungen, die auf * aktivieren (immer aktiv), haben die größte Angriffsfläche. Erweiterungen bevorzugen, die auf eine spezifische Sprache oder einen Dateinamen aktivieren.
4. Erforderliche Berechtigungen versus erwartetes Verhalten. Fordert eine „Theme"-Erweiterung Netzwerkzugriff an? Benötigt eine „Snippet"-Erweiterung Dateisystem-Schreibzugriff? Diskrepanzen sind rote Flaggen. Mit Microsofts Dokumentation zur Erweiterungs-Laufzeitsicherheit abgleichen.
5. Open-Source-Repo-Audit. Liegt der Quellcode auf GitHub? Die letzten fünf Commits auf verdächtige Änderungen lesen: Post-Install-Hooks, Base64-kodierte Blobs, Netzwerkaufrufe an unbekannte Domains.

Eine Erweiterung, die auf * aktiviert und Netzwerkzugriff anfordert, ist funktional eine Remote-Shell mit VS Code obendrauf.

Dasselbe Audit-Framework gilt für MCP-Server — die nächste Erweiterungsklasse im Supply-Chain-Bereich. Unser Überblick über die besten MCP-Server 2026 erklärt, welchen wir vertrauen und warum.

Warum das immer wieder passiert: Die Supply-Chain-Welle 2025–2026

Der GitHub-Breach vom 20. Mai ist ein Knoten in einem 9-monatigen Bogen: Shai-Hulud-npm-Wurm (September 2025), GlassWorm-OpenVSX-Wurm (Oktober–November 2025), Shai-Hulud 2.0 (November 2025, über 25.000 betroffene Repositories), Mini Shai-Hulud (Anfang 2026), Nx Console (18. Mai 2026), GitHub-Endpunkt-Kompromittierung (20. Mai 2026). Entwickler-Endpunkte sind zur neuen verwundbaren Flanke geworden.

• September 2025, Shai-Hulud-npm-Wurm. Sich selbst verbreitende Malware in beliebten npm-Paketen. CISA gab eine Warnung heraus zur weitverbreiteten Kompromittierung.
• Oktober–November 2025, GlassWorm. Der erste sich selbst verbreitende Wurm, der auf VS-Code-Erweiterungen auf OpenVSX abzielte. Koi-Security-Offenlegung.
• November 2025, Shai-Hulud 2.0. Über 25.000 Repositories exfiltriert. Microsoft Security Blog veröffentlichte Eindämmungshinweise.
• Anfang 2026, Mini Shai-Hulud. TeamPCP-Variante. Kleinere Wiederholungsangriffe gegen Trivy, KICS, LiteLLM, TanStack und MistralAI.
• 18. Mai 2026, Nx Console v18.95.0. Höchstwahrscheinlicher Angriffsvektor für die GitHub-Endpunkt-Kompromittierung.
• 20. Mai 2026, GitHub gibt bekannt. ~3.800 interne Repositories exfiltriert. Laut Wizs Shai-Hulud-Forensik-Reihe ist das IMDS-Missbrauchsmuster eine direkte Weiterentwicklung.

Das Muster ist eindeutig: Entwickler-Laptops halten sämtliche Geheimnisse der Organisation (GitHub-PATs, AWS-Schlüssel, Vault-Token, KI-Provider-Schlüssel) und haben nahezu keine EDR-Abdeckung. Solange dieses Ungleichgewicht nicht behoben wird, setzt sich diese Welle fort.

Defensive KI ist ein Teil der Antwort. Wir haben diesen Aspekt in unserer Analyse von Wie KI Datenpannen verhindert beleuchtet.

GitHubs umfassendere Reaktion: Trusted Publishing, FIDO-2FA, 90-Tage-Token

GitHub rollte bereits vor dem 20. Mai vier Supply-Chain-Kontrollen aus: verpflichtende 2FA für npm-Publisher, eine 90-Tage-Obergrenze für granulare Schreib-Token, Abkehr von TOTP zugunsten von FIDO und Passkeys sowie OIDC Trusted Publishing für GitHub Actions und GitLab CI. Der Mai-Breach beschleunigt eine ohnehin laufende Migration — er führt keine neue Richtlinie ein.

GitHubs umfassender Plan für eine sicherere npm-Supply-Chain geht diesem Vorfall um Monate voraus. Je schneller Sie sich daran orientieren, desto kleiner ist Ihr Explosionsradius beim nächsten Mal.

Härtung: Wie man das Nächste übersteht

Sechs zukunftsorientierte Maßnahmen: Erweiterungsversionen in devcontainer.json fest verankern, eine Erweiterungs-Allowlist auf Org-Ebene erzwingen, EDR mit Erweiterungsprozess-Sichtbarkeit betreiben, jeden Push auf Secrets scannen, PATs auf ein Repository beschränken und OIDC Trusted Publishing statt langlebiger Token einsetzen. Keine dieser Maßnahmen hätte jeden Vorfall verhindert — zusammen reduzieren sie den Explosionsradius von „alles auf dem Laptop" auf „ein Repository".

{
  "name": "secure-dev",
  "extensions": [
    "[email protected]",
    "[email protected]",
    "[email protected]"
  ],
  "settings": {
    "extensions.autoUpdate": false,
    "extensions.autoCheckUpdates": false
  },
  "containerEnv": {
    "VSCODE_GALLERY_SERVICE_URL": "https://your-internal-allow-list.example.com"
  }
}

Kurz zusammengefasst:

• Verankern Sie jede Erweiterungsversion in devcontainer.json, um Auto-Updates zu deaktivieren.
• Allowlist auf Org-Ebene einrichten, indem Sie VSCODE_GALLERY_SERVICE_URL auf einen internen Mirror zeigen.
• EDR mit IDE-Prozess-Sichtbarkeit: CrowdStrike, SentinelOne oder Microsoft Defender for Endpoint mit VS Code im Scope.
• Jeden Push auf Secrets scannen: Pre-Commit und Push-Zeit, serverseitig.
• Jeden PAT auf ein Repository beschränken: kein *-Scope, niemals.
• OIDC Trusted Publishing: keine langlebigen npm- oder Registry-Token in CI.

Die Linux-copy_file_range-CVE der letzten Woche ist eine Schwestergeschichte: andere Ebene, gleiche Lektion. Die Vertrauensgrenze, die man vergessen hat, beißt zuerst.

Wenn Sie als nächstes KI-Coding-Agenten in Betracht ziehen, wenden Sie dasselbe Audit-Framework an. Sie haben dasselbe Vertrauensprofil wie Erweiterungen. Unser Überblick über die besten KI-Coding-Agenten 2026 zeigt, welche Agenten dieses Vertrauen verdienen.

Häufig gestellte Fragen

Wurde GitHub gehackt?

Nein, nicht in dem Sinne, den die meisten Schlagzeilen suggerieren. GitHub.com-Produktion wurde nicht kompromittiert. Ein GitHub-Mitarbeiter installierte eine schadhafte VS-Code-Erweiterung auf seinem Arbeitsrechner, die rund 3.800 interne GitHub-Quellcode-Repositories exfiltrierte. Kundencode, Kundenkonten und GitHubs Produktionsdienste sind nicht betroffen.

Welche VS-Code-Erweiterung war tatsächlich involviert?

GitHub hat den Erweiterungsnamen offiziell nicht bestätigt. Forensische Belege von StepSecurity, Wiz und GHSA-c9j4-9m59-847w weisen höchstwahrscheinlich auf Nx Console v18.95.0 hin, die am 18. Mai um 12:36 Uhr UTC veröffentlicht und elf Minuten später entfernt wurde. Wir behandeln dies als „höchstwahrscheinlich, nicht bestätigt", bis GitHub es offiziell benennt.

Ist Nx Console jetzt sicher zu verwenden?

Die gepatchte Version ist 18.100.0. Wenn Sie Version v18.95.0 installiert haben, deinstallieren Sie sie sofort, führen Sie den IoC-Scan in unserem Triage-Abschnitt durch und installieren Sie sie nur vom offiziellen Nrwl-Publisher in Version 18.100.0 oder höher neu. Verifizieren Sie die Publisher-Domain vor der Neuinstallation und verankern Sie die Version in devcontainer.json.

Waren Kundendaten vom GitHub-Breach betroffen?

Nein. Laut GitHubs offiziellem Statement via Bleeping Computer wurden Kunden-Quellcode, Kundenkonten, OAuth-Token und GitHub-hosted Production-Daten nicht abgerufen. Die kompromittierten Daten sind GitHubs interner Quellcode vom Mitarbeiter-Endpunkt. Behandeln Sie dies als Mitarbeiter-Laptop-Vorfall, nicht als Plattform-Breach.

Woher weiß ich, ob mein GitHub-PAT gestohlen wurde?

Das wissen Sie nicht mit Sicherheit. Die konservative Annahme: Wenn Sie in den letzten 14 Tagen ein GitHub-PAT in VS Code verwendet haben, gehen Sie von einer Kompromittierung aus und rotieren Sie es. Prüfen Sie Ihr GitHub-Audit-Log via gh api /orgs/{ORG}/audit-log auf unbekannte Push-Events zwischen dem 18. und 20. Mai UTC, dann Token widerrufen und neu ausstellen.

Was ist TeamPCP und UNC6780?

TeamPCP ist eine Bedrohungsgruppe; UNC6780 ist die Tracking-ID, die Incident-Response-Anbieter zugewiesen haben. Sie haben die Attribution für den GitHub-Breach öffentlich beansprucht. Dieselbe Gruppe hat 2026er Kompromittierungen gegen Trivy, KICS, LiteLLM, TanStack und MistralAI beansprucht — ein konsistentes VS-Code- und npm-Supply-Chain-Zielmuster.

Sind VS-Code-Erweiterungen sandboxed?

Nein, nicht wirklich. VS-Code-Erweiterungen laufen im Node.js-Prozess der IDE mit den vollen Dateisystem- und Netzwerkprivilegien des Benutzers. Sie können jede Datei in Ihrem Home-Verzeichnis lesen, einschließlich SSH-Schlüssel, ~/.aws/credentials, ~/.claude/settings.json und Prozessspeicher via /proc/*/mem unter Linux. Microsoft dokumentiert das Laufzeit-Sicherheitsmodell und seine Grenzen in den offiziellen Erweiterungs-Dokumenten.

War GitHub Codespaces oder CI-Runner betroffen?

Bisher keine Belege dafür. Die Kompromittierung betraf einen Mitarbeiter-Arbeitsrechner, nicht die GitHub-gehostete Infrastruktur. Codespaces, GitHub-Actions-Runner und kundenorientierte CI-Infrastruktur werden nicht als betroffen gemeldet. Wir aktualisieren diesen Beitrag, wenn neue IoCs dieses Bild verändern.

Fazit

Drei Punkte zum Mitnehmen:

1. GitHub.com wurde nicht gehackt. Der VS-Code-Arbeitsrechner eines Mitarbeiters wurde kompromittiert. Die Lektion gilt für jeden Entwickler.
2. Jetzt rotieren, Audit-Framework für immer. Der 60-Minuten-Notfallplan ist das Pflaster; das 5-Fragen-Audit-Framework ist das Immunsystem.
3. Das ist kein Einzelfall. Es ist Knoten #6 in einer 9-monatigen Supply-Chain-Welle, die nicht langsamer wird.

Zuletzt aktualisiert: 20. Mai 2026. Dieser Beitrag wird am 27. Mai 2026 mit neuen IoCs, Anbieter-Advisories und einer eventuellen GitHub-bestätigten Erweiterungsattribution aktualisiert.

Wenn Ihr Team Hilfe beim Audit Ihrer VS-Code-Erweiterungs-Oberfläche, Ihrer PAT- und Token-Hygiene oder beim Aufbau einer Org-Level-Allowlist-Richtlinie benötigt, erhalten Sie eine kostenlose Beratung. Wir beschäftigen uns seit dem Vercel-Breach im April intensiv mit der Sicherheit von Entwickler-Endpunkten, und der obige Plan ist das, was wir mit Kunden am ersten Tag durchführen.