Der Wilde Westen der VS Code-Erweiterungen und wie eine manipulierte Erweiterung GitHub kompromittierte

Achtzehn Minuten, 2,2 Millionen Ziele

Es war eine schwierige Woche für GitHub. Gestern bestätigte GitHub eine Sicherheitsverletzung. Die Angreifer sollen Daten aus rund 3.700 internen Repositories entwendet haben, und der Einstiegspunkt war eine manipulierte VS Code-Erweiterung, die auf dem Rechner eines GitHub-Mitarbeiters lief.

Am Tag zuvor zeigte Nx Console (eine beliebte VS Code-Erweiterung für das Nx Monorepo-Build-System) den Mechanismus, der die Kompromittierung ermöglichte. Wenn es um Sicherheit geht, sind VS Code-Erweiterungen der Wilde Westen.

Was geschah mit Nx Console

Am 18. Mai wurde Version 18.95.0 der Nx Console-Erweiterung (2,2 Millionen Installationen, verifiziertes Herausgeber-Badge) um 12:30 UTC auf den Visual Studio Marketplace hochgeladen. Microsoft kennzeichnete den Upload nicht. Der Nx-Maintainer erhielt die Upload-Benachrichtigungs-E-Mail des Marktplatzes erst um 12:36 UTC, sechs Minuten später. Der kompromittierte Build wurde um 12:47 UTC deinstalliert und Microsoft registrierte die vollständige Entfernung um 12:48 UTC. Gesamte Expositionszeit auf dem Visual Studio Marketplace: etwa achtzehn Minuten.

Derselbe Build wurde auch auf OpenVSX veröffentlicht. Frühere Berichte besagten, dass OpenVSX nicht betroffen war, aber die aktualisierte Warnung der Maintainer zeigt, dass er dort von 12:33 UTC bis 13:09 UTC live war. Das sind etwa sechsunddreißig Minuten, doppelt so lang wie das Zeitfenster des Visual Studio Marketplace.

Gemäß der Warnung sollte jeder, der Nx Console mit aktivierter Auto-Update-Funktion während dieser Zeitfenster installiert hatte, davon ausgehen, dass er kompromittiert wurde, und alles auf der Festplatte (Tokens, Secrets, SSH-Schlüssel, alles, was mit Anmeldeinformationen zusammenhängt) musste rotiert werden.

Die Grundursache war ein GitHub-Token eines Mitwirkenden, das bei einem früheren Supply-Chain-Angriff abgegriffen und dann zur Veröffentlichung des bösartigen Releases verwendet wurde. Die Veröffentlichungs-Pipeline akzeptierte das gestohlene Token ohne weitere Prüfung, was alles war, was die Angreifer brauchten.

Auto-Update ist das eigentliche Problem

Jeder beliebte Erweiterungs-Marktplatz wird standardmäßig mit aktivierter Auto-Update-Funktion ausgeliefert. VS Code, Cursor, die ganze Palette. Die Begründung ist isoliert betrachtet sinnvoll, da die meisten Entwickelnden niemals etwas manuell aktualisieren, und es ausgeschaltet zu lassen, würde bedeuten, dass eine große Anzahl von Editoren veralteten, anfälligen Code ausführt.

Der Kompromiss ist nicht mehr sinnvoll, sobald man feindliche/kompromittierte Herausgeber berücksichtigt. Auto-Update gibt einem Angreifer, der ein Release kontrolliert, einen direkten Push-Kanal auf jede Maschine, die diese Erweiterung ausführt. Marktplätze legen keine Überprüfungsschranke oder Wartezeit fest zwischen der Veröffentlichung eines Updates und dem Zeitpunkt, zu dem installierte Clients es abrufen.

Die Überprüfung selbst hat kein einzelnes festes Intervall. Es gibt einen 12-Stunden-Fallback-Timer in extensionsWorkbenchService.ts (1 Stunde bei Insiders mit einem ausstehenden Produktupdate), eine sofortige Überprüfung beim Start sobald die Workbench im Leerlauf ist, und mehrere ereignisbasierte Trigger (Produktupdate-Überprüfung, Änderung der Zulassungslistenrichtlinie, Wechsel der Verbindung von getaktet zu ungetaktet, Aktivierung des Auto-Check-Schalters). Darüber hinaus gibt es einen separaten Pfad, der Updates als Nebeneffekt jeder anderen Marketplace-Interaktion erfasst. Wenn VS Code aus irgendeinem Grund die Galerie abfragt (Erweiterungsseitenleiste sichtbar, Marketplace-Suche, Empfehlungsaufforderungen, Hintergrundsubsysteme, die Galerie-Metadaten abrufen), dann gleicht das Ergebnis mit installierten Erweiterungen ab und, falls welche jetzt veraltet sind, löst aus eventuallyAutoUpdateExtensions, das über einen auf 1 Sekunde gedrosselten Delayer. Mit extensions.autoUpdate aktiviert (Standard), erfolgt die Installation im Hintergrund ohne Aufforderung.

Das achtzehnminütige Fenster im Visual Studio Marketplace erfasste jeden laufenden Editor, der während dieser Minuten eine Galerie-Interaktion mit dem Nx Console-Eintrag durchführte: sichtbare Seitenleiste, Marketplace-Suche, Empfehlungssuche oder eines der Hintergrundsubsysteme, die Galerie-Metadaten abrufen. Über Zeitzonen und Arbeitszeiten hinweg, bei einer Erweiterung mit 2,2 Millionen Installationen und einer Erweiterungsseitenleiste, die viele Entwickelnde offen lassen, ist diese Population viel größer, als ein periodischer Timer allein vermuten ließe. Bei unseren eigenen Tests dieser Funktionen haben wir gesehen, dass Auto-Update innerhalb von Minuten nach der Veröffentlichung einer neuen Version ausgelöst wurde, was eher dem Galerie-Synchronisierungspfad als dem 12-Stunden-Timer entspricht. Das OpenVSX-Fenster tat dasselbe für etwa sechsunddreißig Minuten.

Die Zeitachse der Maintainer zeigt auch die Erkennungslücke, die das Auto-Update öffnet. Sechs dieser achtzehn Minuten vergingen, bevor der Maintainer überhaupt die Upload-Benachrichtigung des Marktplatzes sah. Das Auto-Update zog die bösartige Version während dieser sechs Minuten auf die Benutzergeräte, bevor ein Mensch auf der Publisher-Seite hätte handeln können.

Warum dies weiterhin funktioniert

Der Nx-Fall ist nicht das erste Mal, dass dies einer VS Code-Erweiterung widerfahren ist. Im November 2025 war die Kompromittierung von AsyncAPI das erste Ereignis der Shai-Hulud 2.0 Wurmwelle. Die Angreifer hatten sowohl die npm- als auch die OpenVSX-Veröffentlichungstoken von AsyncAPI gestohlen, die jahrelang in GitHub-Repository-Secrets lagen, und nutzten sie, um bösartige AsyncAPI npm-Pakete und eine bösartige Version der AsyncAPI VS Code-Erweiterung auf OpenVSX zu pushen. Mindestens ein Entwickelnder meldete eine Infektion über die Erweiterung im eigenen Issue-Tracker des Projekts, bevor die Maintainer die betroffenen Releases als veraltet markieren konnten. Derselbe Mechanismus war am Werk: ein gestohlenes Credential, das verwendet wurde, um bösartigen Code über ein kurzes Zeitfenster an eine sich automatisch aktualisierende Benutzerbasis zu pushen.

Einige Dinge sprechen hier gegen die Verteidiger:

• Hohe Installationszahlen und verifizierte Publisher-Badges signalisieren Vertrauen, und Vertrauen ist das, was Angreifer kapern wollen. Beliebte Erweiterungen sind bereits auf Millionen von Maschinen installiert, sodass eine kompromittierte Version bösartigen Code automatisch in all diese bestehenden Installationen pusht, ohne Social Engineering gegen neue Benutzer zu benötigen.
• Erweiterungen werden als interpretiertes JavaScript und nicht als kompilierte Binärdateien ausgeliefert. Die bösartige Nx Console-Payload war 2.777 Bytes, die in eine minifizierte Datei injiziert wurden, welche dann einen 498 KB großen, obfuskierten Dropper von einem verwaisten Commit im offiziellen nrwl/nx Repository abrief. EDR hat keine Signatur für einen minifizierten JavaScript-Diff gegen eine Erweiterung, der Benutzer bereits vertrauen.
• Maintainer-Credentials sind leichter zu phishen oder zu scrapen, als sie sein sollten. Der Nx-Fall begann mit einem Token aus einer separaten Kompromittierung, das nachgelagert gegen ein vertrauenswürdiges Ziel eingesetzt wurde. Der AsyncAPI-Fall begann mit einem OpenVSX-Token, das jahrelang in einem GitHub-Repository-Secret gelegen hatte.
• Die Community wird schnell darin, dies zu erkennen, aber achtzehn Minuten automatischer Verteilung reichen aus, um Schaden anzurichten, und das nur auf einem der beiden Marktplätze, die die Erweiterung hosten.

Sobald es auf einer Maschine landet, kann der Marktplatz nicht mehr helfen.

Marktplätze haben auch keine Möglichkeit, eine Erweiterung zurückzuziehen, sobald sie installiert wurde. Das Entfernen des Eintrags verhindert neue Installationen, aber jeder, der die bösartige Version bereits heruntergeladen hat, führt sie weiter aus, bis er auf eine saubere Version aktualisiert oder sie manuell deinstalliert. Die automatische Aktualisierung wird betroffene Nutzende schließlich auf die gepatchte Version bringen, sobald der Maintainer eine bereitstellt, aber der Marktplatz hat keinen Kill-Switch und keine Möglichkeit, eine Installation schneller rückgängig zu machen.

Die Analyse von Wiz Research zum Long Tail von Shai-Hulud 2.0 zeigt diese Dynamik in der Praxis. Die bösartige AsyncAPI VS Code-Erweiterung (v1.0.1) wurde am 26. November 2025 von OpenVSX entfernt, aber das Repository wurde auf die vorherige saubere Version (v1.0.0) zurückgesetzt. Installierte Kopien von v1.0.1 sahen keine neuere Version verfügbar, sodass die automatische Aktualisierung nie ausgelöst wurde. Die Erweiterung lief fast einen Monat lang auf Entwickelnden-Maschinen und exfiltrierte Anmeldeinformationen, was über 90 % der Long-Tail-Infektionen der Kampagne und täglich etwa 100-200 neue kompromittierte Repositories vom 25. November bis zum 24. Dezember ausmachte. Der Fluss stoppte erst, als AsyncAPI am 24. Dezember eine saubere v1.1.0 veröffentlichte (nachdem Wiz Research ihnen das Problem am Vortag gemeldet hatte), woraufhin IDEs automatisch darauf aktualisierten und die täglichen neuen Kompromittierungen innerhalb weniger Tage auf eine Handvoll sanken.

Microsoft entfernt Einträge ebenfalls stillschweigend. Es gibt keine Benachrichtigung an Nutzende, die während des Expositionszeitraums installiert haben. Ihr Editor zeigt keine Meldung an wie „Sie haben möglicherweise eine kompromittierte Version installiert, bitte überprüfen Sie Ihre Maschine“. Sofern Sie am Tag des Vorfalls nicht die Sicherheitsnachrichten verfolgt haben, könnte Ihr einziges Signal sein, dass die Erweiterung nicht mehr in den Marktplatz-Suchergebnissen angezeigt wurde. Das Nx Console-Repository hat bereits ein Issue von einem Entwickelnden, der gutgläubig fragt, warum die Erweiterung vom Marktplatz verschwunden ist. Die meisten Nutzenden würden nicht daran denken, zu fragen.

Der kombinierte Effekt ist, dass die einzige wirksame Reaktion des Marktplatzes darin besteht, neue Installationen einer bekanntermaßen schlechten Version zu verhindern. Für Entwickelnde, die den bösartigen Build während des Zeitfensters bereits heruntergeladen haben, liegt die Bereinigung vollständig bei ihnen und hängt davon ab, dass sie über einen anderen Kanal als den Marktplatz selbst von dem Vorfall erfahren.

Was wirklich zu tun ist

Wenn Sie Nx Console mit automatischer Aktualisierung während dieser Zeitfenster am 18. Mai installiert hatten, ist die Empfehlung des Advisories der richtige Ausgangspunkt: Tokens, Secrets, SSH-Schlüssel und alles andere, was von der betroffenen Maschine aus erreichbar ist, rotieren. Jeder, der den OpenVSX-Build ausgeführt hat, fällt in den längeren Sechsunddreißig-Minuten-Zeitraum und nicht in den des Visual Studio Marketplace.

Für das breitere Muster ist die kostengünstige Intervention, eine Verzögerung zwischen der Veröffentlichung einer Version und ihrer Installationsfreigabe einzuführen. Aikidos Geräteschutz wird mit einer standardmäßigen 48-Stunden-Sperre für neue Paket- und Erweiterungsversionen ausgeliefert, die Nx Console (und die jüngste durabletask PyPI-Kompromittierung) ohne dass jemand es zuerst als bösartig identifizieren müsste. Als Einzelperson ohne eine Anbieterlösung ist das Nächstbeste, was Sie tun können, automatische Erweiterungsaktualisierungen in VS Code deaktivieren und stattdessen nach einem bewussten Zeitplan aktualisieren. Das ist langsamer, und Sie werden bei legitimen Releases ein oder zwei Tage im Rückstand sein. Das ist der Preis dafür, den frisch veröffentlichten Code anderer Leute nicht sofort auf Ihrem Laptop auszuführen, sobald sie ihn veröffentlichen.

VS Code unterstützt bereits die zugrunde liegende Richtlinienoberfläche, um dies zu einer Einstellung auf Organisationsebene. Das extensions.allowed Unternehmensrichtlinie ermöglicht es Administratoren, einzuschränken, welche Publisher, Erweiterungen und sogar spezifische Versionen auf verwalteten Geräten installiert werden können. Eine Cooldown-Option zusätzlich dazu (etwas wie „nur automatische Installation von Versionen, die älter als N Stunden sind“) würde in dieselbe Einstellung passen. Es gibt keinen guten technischen Grund, warum dies nicht bereits existiert, und angesichts der Häufigkeit, mit der solche Vorfälle auf dem mitgelieferten Marktplatz auftreten, sollte es das. Dasselbe gilt für Cursor und jeden anderen VS Code-basierten Editor: Wenn Sie Organisationen bereits erlauben, eine Positivliste durchzusetzen, sollten Sie ihnen auch erlauben, einen Cooldown durchzusetzen.

Die GitHub-Geschichte wird wochenlang laufen, weil das Opfer bekannt ist, und die gleiche zugrunde liegende Maschinerie wird weiterhin Sicherheitsverletzungen produzieren. Solange Marktplätze automatische Updates von Konten pushen, die auf Dutzende gewöhnliche Weisen kompromittiert werden können, ist jede beliebte Erweiterung nur einen gestohlenen Token davon entfernt, sich in einen Wurm zu verwandeln.

Aikido Device Protection

Wenn Sie heute einen Cooldown wünschen, ohne darauf zu warten, dass VS Code oder Cursor einen nativ bereitstellen, ist Aikido Device Protection das, was wir empfehlen. Es erzwingt eine konfigurierbare Mindestalter-Richtlinie (Standard: 48 Stunden) für Paket- und Erweiterungsinstallationen auf Geräteebene, sodass dieselbe Richtlinie jeden VS Code-basierten Editor abdeckt, den Ihre Entwickelnden verwenden.

​