.png)
Achtzehn Minuten, 2,2 Millionen Ziele
Es war eine harte Woche für GitHub. Gestern bestätigte GitHub, dass es Opfer eines Hackerangriffs geworden war. Den Berichten zufolge haben die Angreifer Daten aus rund 3.700 internen Repositorys abgegriffen, wobei der Einstiegspunkt eine manipulierte VS-Code-Erweiterung war, die auf dem Rechner eines GitHub-Mitarbeiters lief.
Am Tag zuvor hatte Nx Console (eine beliebte VS-Code-Erweiterung für das Nx-Monorepo-Build-System) den Mechanismus aufgezeigt, der den Angriff erst möglich gemacht hatte. Was die Sicherheit angeht, sind VS-Code-Erweiterungen der Wilde Westen.
Was ist mit der Nx-Konsole passiert?
Am 18. Mai wurde die Version 18.95.0 der Nx Console-Erweiterung (2,2 Millionen Installationen, verifiziertes Herausgeber-Abzeichen) um 12:30 Uhr UTC auf den Visual Studio Marketplace hochgeladen. Microsoft hat den Upload nicht markiert. Der Nx-Betreuer erhielt die E-Mail-Benachrichtigung des Marketplaces über den Upload erst um 12:36 Uhr UTC, also sechs Minuten später. Die kompromittierte Version wurde um 12:47 Uhr UTC aus dem Verkehr gezogen, und Microsoft registrierte die Entfernung vollständig um 12:48 Uhr UTC. Gesamtdauer der Veröffentlichung im Visual Studio Marketplace: etwa achtzehn Minuten.
Die gleiche Version wurde auch auf OpenVSX veröffentlicht. Frühere Berichte besagten, dass OpenVSX nicht betroffen sei, doch laut der aktualisierten Mitteilung der Betreuer war sie dort von 12:33 UTC bis 13:09 UTC verfügbar. Das sind etwa 36 Minuten – doppelt so lange wie das Zeitfenster im Visual Studio Marketplace.
Laut der Sicherheitswarnung sollte jeder, bei dem Nx Console während dieser Zeiträume installiert war und die automatische Aktualisierung aktiviert war, davon ausgehen, dass sein System kompromittiert wurde, und alle auf der Festplatte gespeicherten Daten (Zugangsdaten, secrets, SSH-Schlüssel und alles, was mit Anmeldedaten zu tun hat) müssen ausgetauscht werden.
Die eigentliche Ursache war das GitHub-Token eines Mitwirkenden, das bei einem früheren Angriff auf die Lieferkette gestohlen und anschließend zur Veröffentlichung der schädlichen Version genutzt worden war. Die Veröffentlichungspipeline akzeptierte das gestohlene Token ohne Weiteres, und mehr brauchten die Angreifer nicht.
Das eigentliche Problem ist die automatische Aktualisierung
Bei allen gängigen Erweiterungs-Marktplätzen ist die automatische Aktualisierung standardmäßig aktiviert. VS Code, Cursor, das gesamte Angebot. Für sich genommen ist diese Vorgehensweise sinnvoll, da die meisten Entwickler nie etwas manuell aktualisieren; würde man diese Funktion deaktivieren, gäbe es eine lange Reihe von Editoren, auf denen veralteter, anfälliger Code läuft.
Dieser Kompromiss verliert seinen Sinn, sobald man böswillige oder kompromittierte Herausgeber mit einbezieht. Durch automatische Updates erhält ein Angreifer, der die Veröffentlichung kontrolliert, einen direkten Push-Kanal zu jedem Rechner, auf dem diese Erweiterung läuft. Marktplätze sehen keine Überprüfung oder Wartezeit zwischen der Veröffentlichung eines Updates und dem Abruf durch die installierten Clients vor.
Die Überprüfung selbst erfolgt nicht in festen Zeitabständen. Es gibt eine 12-Stunden-Ausfall-Timer in extensionsWorkbenchService.ts (1 Stunde bei „Insiders“ mit einem anstehenden Produkt-Update), eine sofortige Überprüfung beim Start sobald die Arbeitsfläche nicht mehr genutzt wird und mehrere ereignisgesteuerte Auslöser (Prüfung auf Produkt-Updates, Änderung der Whitelist-Richtlinie, Umstellung der Verbindung von datenvolumenbegrenzt auf unbegrenzt, Aktivierung der automatischen Überprüfung). Darüber hinaus gibt es einen separaten Pfad, der Updates als Nebeneffekt jeder anderen Interaktion mit dem Marketplace erfasst. Wenn VS Code aus irgendeinem Grund die Galerie abfragt (Seitenleiste „Erweiterungen“ sichtbar, Suche im Marketplace, Empfehlungsaufforderungen, Hintergrundsubsysteme, die Metadaten aus der Galerie abrufen), wird gleicht das Ergebnis mit den installierten Erweiterungen ab und überprüft, ob einige davon inzwischen veraltet sind, Brände eventuallyAutoUpdateExtensions, das über ein Verzögerung auf 1 Sekunde begrenzt. Mit extensions.autoUpdate Wenn diese Option aktiviert ist (Standardeinstellung), erfolgt die Installation im Hintergrund ohne Eingabeaufforderung.
Das achtzehnminütige Zeitfenster im Visual Studio Marketplace erfasste jeden laufenden Editor, der während dieser Minuten eine Interaktion mit der Galerie durchführte, die den Eintrag zur Nx-Konsole betraf: sichtbare Seitenleiste, Suche im Marketplace, Abruf von Empfehlungen oder eines der Hintergrundsubsysteme, die Metadaten aus der Galerie abrufen. Über Zeitzonen und Arbeitszeiten hinweg, bei einer Erweiterung mit 2,2 Millionen Installationen und einer Erweiterungs-Seitenleiste, die viele Entwickler geöffnet lassen, ist diese Nutzergruppe weitaus größer, als es ein einfacher periodischer Timer vermuten lassen würde. Bei unseren eigenen Tests dieser Funktionen haben wir beobachtet, dass die automatische Aktualisierung innerhalb von Minuten nach der Veröffentlichung einer neuen Version ausgelöst wurde, was eher dem Galerie-Synchronisationspfad als dem 12-Stunden-Timer entspricht. Das OpenVSX-Fenster verhielt sich etwa 36 Minuten lang genauso.
Der Zeitablauf der Betreuer verdeutlicht zudem die Sicherheitslücke, die durch die automatische Aktualisierung entsteht. Sechs dieser achtzehn Minuten vergingen, bevor der Betreuer überhaupt die Upload-Benachrichtigung des Marktplatzes sah. Während dieser sechs Minuten wurde die schädliche Version durch die automatische Aktualisierung auf die Rechner der Nutzer übertragen, noch bevor jemand auf Seiten des Anbieters davon Kenntnis erlangen und Maßnahmen ergreifen konnte.
Warum das immer wieder funktioniert
Der Fall Nx ist nicht das erste Mal, dass so etwas bei einer VS-Code-Erweiterung passiert ist. Im November 2025 war der Angriff auf AsyncAPI der erste Vorfall der Shai-Hulud-2.0-Wurmwelle. Die Angreifer hatten sowohl die npm- als auch die OpenVSX-Veröffentlichungstoken von AsyncAPI gestohlen, die secrets Jahren in secrets des GitHub-Repositorys gespeichert waren, und nutzten diese, um bösartige AsyncAPI-npm-Pakete und eine bösartige Version der AsyncAPI-VS-Code-Erweiterung auf OpenVSX zu veröffentlichen. Mindestens ein Entwickler meldete im projektinternen Issue-Tracker, dass er über die Erweiterung infiziert worden sei, bevor die Betreuer die betroffenen Versionen als veraltet kennzeichnen konnten. Es handelte sich um denselben Mechanismus: gestohlene Anmeldedaten, die genutzt wurden, um innerhalb eines kurzen Zeitfensters bösartigen Code an eine sich automatisch aktualisierende Nutzerbasis zu übertragen.
Hier sprechen einige Faktoren gegen die Verteidiger:
- Hohe Installationszahlen und Abzeichen für verifizierte Anbieter signalisieren Vertrauen – und genau dieses Vertrauen wollen Angreifer ausnutzen. Beliebte Erweiterungen sind bereits auf Millionen von Computern installiert, sodass eine kompromittierte Version bösartigen Code automatisch in all diese bestehenden Installationen einschleust, ohne dass Social-Engineering-Angriffe auf neue Nutzer erforderlich wären.
- Erweiterungen werden als interpretiertes JavaScript und nicht als kompilierte Binärdateien ausgeliefert. Die schädliche Nx-Console-Nutzlast umfasste 2.777 Byte, die in eine minimierte Datei eingeschleust wurden; diese holte daraufhin einen 498 KB großen, verschleierten Dropper aus einem verwaisten Commit im offiziellen
nrwl/nxRepository. EDR verfügt über keine Signatur für einen minimierten JavaScript-Diff im Vergleich zu einer Erweiterung, der die Benutzer bereits vertrauen. - Die Anmeldedaten von Betreuern lassen sich leichter durch Phishing oder Scraping abgreifen, als es eigentlich sein sollte. Der Nx-Fall begann mit einem Token aus einem separaten Angriff, das anschließend gegen ein vertrauenswürdiges Ziel eingesetzt wurde. Der AsyncAPI-Fall begann mit einem OpenVSX-Token, das seit Jahren in einem geheimen GitHub-Repository gespeichert war.
- Die Community wird zwar immer schneller darin, solche Vorfälle zu entdecken, aber achtzehn Minuten automatische Verbreitung reichen aus, um Schaden anzurichten – und das nur auf einem der beiden Marktplätze, auf denen die Erweiterung angeboten wird.
Sobald es auf einem Gerät installiert ist, kann der Marktplatz dir nicht mehr helfen
Marktplätze haben zudem keine Möglichkeit, eine Erweiterung zurückzurufen, sobald sie einmal installiert wurde. Durch das Entfernen des Eintrags werden zwar keine neuen Installationen mehr zugelassen, doch jeder, der die schädliche Version bereits heruntergeladen hat, nutzt sie so lange weiter, bis er auf eine saubere Version aktualisiert oder sie manuell deinstalliert. Die automatische Aktualisierung wird betroffene Nutzer schließlich auf die gepatchte Version umstellen, sobald der Betreuer eine solche bereitstellt, doch der Marktplatz verfügt weder über einen „Kill-Switch“ noch über eine Möglichkeit, eine Installation schneller rückgängig zu machen.
Die Analyse des „Long Tail“ von Shai-Hulud 2.0Wiz veranschaulicht diese Dynamik in der Praxis. Die bösartige AsyncAPI-Erweiterung für VS Code (v1.0.1) wurde am 26. November 2025 aus OpenVSX entfernt, doch das Repository wurde auf die vorherige, saubere Version (v1.0.0) zurückgesetzt. Für installierte Kopien der Version v1.0.1 war keine neuere Version verfügbar, sodass die automatische Aktualisierung nie ausgelöst wurde. Die Erweiterung lief auf den Rechnern der Entwickler weiter und exfiltrierte fast einen Monat lang Anmeldedaten, was über 90 % der Long-Tail-Infektionen der Kampagne ausmachte und vom 25. November bis zum 24. Dezember zu etwa 100 bis 200 neuen kompromittierten Repositorys pro Tag führte. Der Ablauf kam erst zum Stillstand, als AsyncAPI am 24. Dezember eine saubere Version v1.1.0 veröffentlichte (nachdem Wiz ihnen das Problem am Vortag gemeldet hatte); daraufhin aktualisierten sich die IDEs automatisch darauf, und die Zahl der täglichen neuen Kompromittierungen sank innerhalb weniger Tage auf eine Handvoll.
Microsoft entfernt Angebote zudem stillschweigend. Nutzer, die die Erweiterung während des Zeitraums der Sicherheitslücke installiert haben, erhalten keine Benachrichtigung. Der Editor zeigt keine Meldung wie „Möglicherweise haben Sie eine kompromittierte Version installiert. Bitte überprüfen Sie Ihren Computer“ an. Sofern Sie am Tag des Vorfalls nicht die Sicherheitsnachrichten verfolgt haben, ist Ihr einziger Hinweis möglicherweise, dass die Erweiterung nicht mehr in den Suchergebnissen des Marktplatzes erscheint. Im Nx Console-Repo gibt es bereits ein Ticket von einem Entwickler, der in gutem Glauben fragt, warum die Erweiterung aus dem Marketplace verschwunden ist. Die meisten Nutzer würden gar nicht auf die Idee kommen, danach zu fragen.
Das hat zur Folge, dass die einzige wirksame Maßnahme des Marktplatzes darin besteht, Neuinstallationen einer als fehlerhaft bekannten Version zu verhindern. Für Entwickler, die den schädlichen Build bereits während des Zeitfensters heruntergeladen haben, liegt die Beseitigung des Problems vollständig in ihrer Verantwortung und hängt davon ab, dass sie über einen anderen Kanal als den Marktplatz selbst von dem Vorfall erfahren.
Was man konkret tun sollte
Falls Sie Nx Console während dieser Zeitfenster am 18. Mai mit automatischer Aktualisierung installiert hatten, sind die Empfehlungen des Sicherheitshinweises der richtige Ausgangspunkt: Ändern Sie Tokens, secrets, SSH-Schlüssel und alles andere, worauf von dem betroffenen Rechner aus zugegriffen werden kann. Wer die OpenVSX-Version ausgeführt hat, fällt unter das längere Zeitfenster von 36 Minuten und nicht unter das des Visual Studio Marketplace.
Im Allgemeinen besteht die kostengünstige Lösung darin, eine Verzögerung zwischen der Veröffentlichung einer Version und dem Zeitpunkt ihrer Installation einzubauen. Aikido Geräteschutz wird standardmäßig mit einer 48-stündigen Wartezeit für neue Paket- und Erweiterungsversionen ausgeliefert, wodurch Nx Console (und die jüngste dauerhafte Aufgabe PyPI-Hack) ohne dass jemand dies zuvor als bösartig identifizieren muss. Als Privatperson ohne eine Anbieterlösung können Sie höchstens Automatische Erweiterungs-Updates in VS Code deaktivieren und stattdessen nach einem festgelegten Zeitplan aktualisieren. Das dauert zwar länger, und Sie hinken den offiziellen Veröffentlichungen um ein oder zwei Tage hinterher. Das ist der Preis dafür, dass Sie den frisch veröffentlichten Code anderer nicht sofort nach der Veröffentlichung auf Ihrem Laptop ausführen.
VS Code unterstützt bereits die zugrunde liegende Richtlinienoberfläche, um dies zu einer Einstellung auf Organisationsebene. Das extensions.allowed Die Unternehmensrichtlinie ermöglicht es Administratoren, festzulegen, welche Herausgeber, Erweiterungen und sogar bestimmte Versionen auf verwalteten Geräten installiert werden dürfen. Eine zusätzliche Wartezeitoption (etwa „nur Versionen automatisch installieren, die älter als N Stunden sind“) würde in dieselbe Einstellung passen. Es gibt keinen triftigen technischen Grund, warum es diese Funktion nicht bereits gibt, und angesichts der Häufigkeit, mit der solche Vorfälle auf dem mitgelieferten Marktplatz auftreten, sollte sie vorhanden sein. Das Gleiche gilt für Cursor und jeden anderen VS Code-basierten Editor: Wenn Organisationen bereits eine Whitelist durchsetzen können, sollten sie auch eine Cooldown-Funktion durchsetzen können.
Die GitHub-Geschichte wird noch wochenlang für Schlagzeilen sorgen, weil das Opfer berühmt ist, und die gleichen Mechanismen im Hintergrund werden weiterhin Sicherheitslücken hervorbringen. Solange Marktplätze Updates automatisch von Konten aus veröffentlichen, die auf Dutzende gängige Arten kompromittiert werden können, ist jede beliebte Erweiterung nur einen gestohlenen Token davon entfernt, sich in einen Wurm zu verwandeln.
Schutzausrüstung Aikido
Wenn Sie bereits heute eine Abklingzeit benötigen, ohne darauf zu warten, dass VS Code oder Cursor eine solche nativ bereitstellen, empfehlen wir Ihnen Aikido Protection “. Diese Lösung erzwingt auf Geräteebene eine konfigurierbare Richtlinie zum Mindestalter (Standard: 48 Stunden) für die Installation von Paketen und Erweiterungen, sodass dieselbe Richtlinie für jeden VS Code-basierten Editor gilt, den Ihre Entwickler verwenden.
