73 Fake VS Code Extensions entlarvt – Entwickler im Visier

Sicherheitsforscher haben eine ganze Welle manipulierter VS Code Extensions aufgedeckt. Die Methode ist unspektakulär – und genau deshalb so erfolgreich:

Die analysierten Extensions zeigen ein wiederkehrendes Muster, das auch typisch für andere Supply-Chain-Angriffe der letzten Monate ist:

Cyberangriffe haben ihre Lieblingsroute verändert. Wer 2026 noch denkt, „die Firewall hält schon", hat das Spielfeld verlassen.

Eine bösartige VS Code Extension ist kein einfacher Virus. Sie sitzt direkt im Workflow – mit Vollzugriff auf alles, was ein Entwickler täglich anfasst:

Die aktuelle Welle ist Teil der laufenden GlassWorm-Kampagne, die seit März 2026 die offene Erweiterungs-Registry Open VSX ins Visier nimmt. 73 nachgeahmte Extensions wurden identifiziert – mindestens sechs davon sind bereits aktiv und liefern Schadcode aus, die übrigen gelten als High-Confidence-Sleeper, die jederzeit über ein reguläres Update scharfgeschaltet werden können.

Geklonte Listings als Tarnung

Die Angreifer kopieren beliebte Original-Extensions 1:1: gleiches Icon, gleiche Beschreibung, identische README-Inhalte – nur Publisher-Name und Identifier sind neu. Beispiel: Eine geklonte Variante des „Turkish Language Pack" wurde unter einem frisch angelegten Publisher mit nahezu identischer Aufmachung veröffentlicht. Wer in der Hektik installiert, sieht den Unterschied nicht.

Die Publisher-Konten stammen aus neu erstellten GitHub-Accounts mit ein bis zwei Repositories – meist eines davon leer und mit einem zufälligen 8-Zeichen-Namen. Klassisches Wegwerf-Profil, gebaut für genau eine Kampagne.

In dieser Welle nutzt die Kampagne zwei parallele Techniken, um die eigentliche Schadlogik aus dem statisch scanbaren JavaScript-Code herauszuhalten:

1. Native Binary – Schadlogik in .node-Dateien

Die Extension lädt beim Start ein plattform-spezifisches Native-Modul und ruft eine install()-Funktion auf. Im JavaScript steht praktisch nichts Verdächtiges:

const platforms = { win32: "./bin/win.node", darwin: "./bin/mac.node" };
const target = platforms[process.platform];
if (target) {
  const { install } = require(target);
  install();
}

Die eigentliche Logik – inklusive eingebetteter GitHub-Release-URLs und VSIX-Installer-Befehlen wie --install-extension für VS Code, Cursor und Windsurf – steckt in der kompilierten .node-Binary. Statische Marketplace-Scans greifen ins Leere.

2. Obfuskierter JavaScript-Loader

Andere Varianten kommen ohne Binary aus: Der Aktivierungscode ist stark verschleiert, dekodiert sich erst zur Laufzeit und lädt dann ein VSIX-Payload aus einem GitHub-Release nach. Es werden CLI-Pfade für VS Code, Cursor, Windsurf und VSCodium aufgelöst und das nachgeladene Paket per --install-extension installiert. Einige Versionen tragen sogar einen verschlüsselten Fallback-Server für den Fall, dass das primäre GitHub-Repo entfernt wird.

Folgende technische Indikatoren wurden im aktuellen Cluster beobachtet. Sie eignen sich als Hunting-Queries für SIEM, EDR/XDR und Build-Pipeline-Audits.

Native Installer Binaries (SHA-256)

Nachgeladenes VSIX-Payload (SHA-256)

GitHub-Hosting der Payloads

Bestätigt bösartig (6)

Sleeper-Extensions (67)

Diese Erweiterungen erscheinen aktuell harmlos, gehören aber zum selben Kampagnen-Cluster und können jederzeit über ein Update bewaffnet werden. Behandeln wie aktive Malware.

Jede VS Code Extension bekommt 0–100 Punkte aus sechs Risiko-Faktoren. Daraus ergibt sich eine klare Ampel: grün, gelb oder rot. Kein Gefühl – ein Verfahren.

🔴 Risikofaktoren (Scoring)

📊 Score → Ampel

🔥 Live-Beispiele aus dieser Liste

💣 Automatische Regeln

Das ist kein Entwicklerproblem. Es ist ein Unternehmensrisiko.

Wenn nur ein Entwickler betroffen ist, kann das bedeuten:

• • Kompromittierter Code in Produktivsystemen
• • Manipulierte Software-Releases an alle Kunden
• • Datenabfluss von Kundeninformationen
• • Komplette Infrastruktur unter externer Kontrolle

Wenn dein Unternehmen entwickelt – egal ob ein Backend, eine App oder interne Tools – stellen sich drei harte Fragen:

Wenn auch nur einer dieser Punkte zutrifft, sollte heute, nicht morgen, gehandelt werden:

• ▢Unbekannte Prozesse auf Entwickler-PCs
• ▢Ungewöhnlicher Netzwerkverkehr aus der Dev-Umgebung
• ▢Neue oder unerklärlich veränderte VS Code Extensions
• ▢Code-Änderungen, die niemand zuordnen kann
• ▢Verdächtige Login-Aktivitäten in Cloud, Git oder Mail

🧨 Fazit

Die größte Schwachstelle ist nicht die Technik – sie heißt Vertrauen ohne Kontrolle.

Wenn Entwickler-Tools kompromittiert werden, ist das kein Einzelfall mehr. Es ist ein strategischer Angriffspunkt – und 2026 einer der lautesten.

👉 Wer seine Entwicklungsumgebung nicht aktiv absichert, baut sein Unternehmen auf fremdem Code.

EDR/XDR, Supply-Chain-Schutz und Härtung von Entwickler-Umgebungen für Software-Unternehmen, SaaS-Anbieter und IT-Dienstleister in der Region: