I. Hintergrund und Beschreibung des Problems

1.1 Stand des KI-IDE-Ökosystems

In den letzten 12 Monaten wurden Tools zur Codegenerierung, die auf großen Sprachmodellen (LLM) basieren, schnell in die Arbeitsabläufe von Entwicklern integriert. Eine neue Generation von KI-IDEs wie Cursor, Windsurf und Google Antigravity basieren auf Microsofts VSCode und bieten Codevervollständigung, Multitasking und die Bearbeitung mehrerer Dokumente durch die Integration von Modellen wie Claude, GPT-4 und Gemini. Diese Plattformen bieten durch die Integration von Modellen wie Claude, GPT-4 und Gemini Funktionen zur Code-Vervollständigung, zur Bearbeitung mehrerer Dateien und zur autonomen Ausführung von Aufgaben. Diese Plattformen haben sich aufgrund ihrer Benutzerfreundlichkeit und verbesserten Entwicklungseffizienz schnell durchgesetzt und haben insgesamt mehr als 1 Million Benutzer.

Diese IDEs werden jedoch nicht von Grund auf neu entwickelt, sondern durch Forking des VSCode-Quellcodes implementiert. Das Forking-Modell beschleunigt zwar den Entwicklungszyklus, übernimmt aber auch zentrale Designentscheidungen des ursprünglichen Projekts - einschließlich der Erweiterung der Empfehlungslogik.

1.2 Kernmechanismen der Verwundbarkeit

Probleme mit der Konfigurationsvererbung: Die von VSCode empfohlene Konfiguration für Erweiterungen codiert einen Verweis auf den offiziellen Visual Studio Marketplace von Microsoft fest ein. Cursor, Windsurf und Google Antigravity waren jedoch aufgrund von rechtlichen und lizenzrechtlichen Einschränkungen nicht in der Lage, Microsofts Extension Marketplace direkt zu nutzen, und verließen sich stattdessen auf OpenVSX, eine Open-Source-Alternative, die von der Eclipse Foundation betrieben wird; dennoch behielten diese IDEs ihre ursprünglichen Konfigurationen während des Forking-Prozesses ohne entsprechende Anpassungen bei.

Empfohlener Auslösemechanismus: Erweiterte Empfehlungen für KI-IDEs wie n8n fallen in zwei Kategorien:

Dateibasierte Empfehlungen:Schlägt automatisch Erweiterungen vor, wenn es erkennt, dass ein Benutzer einen bestimmten Dateityp geöffnet hat (z. B. azure-pipelines.yaml).

Softwarebasierte Empfehlungen:Wird ausgelöst, wenn es feststellt, dass eine bestimmte Anwendung (z. B. PostgreSQL) auf dem System installiert ist

Risiko des Namespace-Hijacking: Das Hauptproblem ist, dass diese empfohlenen Erweiterungen (z.B. ms-ossdata.vscode-postgresql, ms-azure-devops.azure-pipelines) in der Regel keine Entität in OpenVSX haben, was bedeutet, dass sich der Publisher-Namespace in einem "undeklarierten" Zustand befindet. Dies bedeutet, dass sich Publisher-Namespaces in einem "undeklarierten" Zustand befinden. Jeder Angreifer kann diese Namespaces registrieren, bösartige Erweiterungen hochladen und der Empfehlungsmechanismus der IDE wird diese bösartigen Versionen den Benutzern automatisch anzeigen, als wären sie offizielle Produkte.

1.3 Konzeptnachweis und praktische Auswirkungen

Die Forscher von Koi Security überprüften die Durchführbarkeit des Angriffs durch einen Proof of Concept (PoC). Sie behaupteten mehrere nicht deklarierte Namespaces, darunter die folgenden:

ms-ossdata.vscode-postgresql

ms-azure-devops.azure-pipelines

msazurermtools.azurerm-vscode-tools

usqlextpublisher.usql-vscode-ext

kuchen-erstellen.kuchen-vscode

Obwohl die Forscher Erweiterungen hochluden, die eindeutig als Platzhalter gekennzeichnet waren und keine Funktionen enthielten, wurden sie von mehr als 1.000 Entwicklern installiert, wobei mehr als 500 Installationen erfolgten, bei denen die Erweiterungen völlig ohne Symbole und eindeutige Kennzeichnung waren. Diese Daten belegen das große Vertrauen, das Entwickler in IDE-Empfehlungen setzen, und die Praktikabilität des Angriffs.

II. technische Analyse

2.1 Vollständige Angriffskette für Angriffe auf die Lieferkette

Die Schwachstelle fällt in die zweite Kategorie der Supply-Chain-Angriffe - d.h. groß angelegte nachgelagerte Auswirkungen durch die Kontaminierung von Tools, denen die Entwickler vertrauen. Im Gegensatz zu traditionellen Angriffen auf Pakete, wie dem Shai-Hulud 2.0 npm-Wurm, sind die Angriffsvektoren dieser Schwachstelle direkter und schwieriger zu verteidigen:

Ersteintrag:Der Angreifer erkennt nicht deklarierte Namespaces in OpenVSX (identifiziert durch Scannen der IDE-Konfigurationsdatei)

Namespace-Registrierung:Registrieren Sie den von der Ziel-IDE empfohlenen Namespace in OpenVSX.

Bösartige Erweiterungen werden hochgeladen:Bösartige Erweiterungen schreiben, die Backdoor-, Anmeldedaten-Diebstahl- oder Datenexfiltrationslogik enthalten

Automatisch empfohlene Auslöser:Die IDE empfiehlt automatisch bösartige Erweiterungen, wenn der Benutzer eine bestimmte Datei öffnet oder wenn das System eine entsprechende Anwendung erkennt.

Installation und Aktivierung durch den Benutzer:Aufgrund der Glaubwürdigkeit der Empfehlung installieren die meisten Nutzer die Erweiterung ohne zusätzliche Überprüfung

Codeausführung und Persistenz:Bösartige Erweiterung erhält vollen Zugriff auf IDE-Prozesse, Dateisysteme und Benutzeranmeldeinformationen

2.2 Folgenabschätzung zur Informationssicherheit

Die Auswirkung der Schwachstelle erstreckt sich auf mehrere wichtige Anlagen im Ökosystem der Entwickler:​

Dieses Ereignis bildet ein systemisches Risikomuster mit mehreren großen Ereignissen in der Lieferkette im Jahr 2025:

OpenVSX-Sicherheitslücke (Juni 2025)Koi Security entdeckte eine CI/CD-Schwachstelle im Freigabeprozess von OpenVSX, die es einem Angreifer ermöglicht, die Umgebungsvariable OVSX_PAT zu kapern, um Schreibzugriff auf den gesamten Marktplatz zu erhalten. Die Schwachstelle wird als "Ein-Klick-Marktplatz-weite Übernahme" eingestuft und betrifft über 8 Millionen Entwickler.

Shai-Hulud npm Wurm (2025):Die sich selbst verbreitende Malware entwendete automatisch die npm-Token der Entwickler, indem sie Code in kompromittierte npm-Pakete einfügte und diese zur Kontaminierung anderer Pakete nutzte. Der Angriff betraf schließlich mehr als 500 Paketversionen.

GitHub-Aktionen Supply Chain Events (März 2025)Die weit verbreitete tj-actions/changed-files Action wurde von einem Angreifer modifiziert, was dazu führte, dass der geheime CI/CD-Schlüssel in öffentlichen Protokollen bekannt wurde.

Diese Vorfälle deuten darauf hin, dass die Entwickler-Toolchain zum wertvollsten Angriffsziel geworden ist, da ein einziges Eindringen Hunderte oder Tausende von nachgelagerten Projekten beeinträchtigen kann.

III. die Reaktion des Verkäufers und die Reparatur

3.1 Vergleich des Zeitplans für die Offenlegung und der Einstellung der Anbieter

Analysieren Sie die wichtigsten Punkte:

Die schnelle Reaktion von Cursor beweist die Reife seines Sicherheitsteams, und die Tatsache, dass die Behebung innerhalb von acht Tagen abgeschlossen war, zeigt, wie wichtig dem Unternehmen sein Schwachstellenmanagementprozess ist.

Google nahm zunächst die Haltung ein, die Schwachstelle nicht zu beheben, was darauf hindeutet, dass die anfängliche Einschätzung des Schweregrads der Sicherheitslücke unzureichend war. Unter dem Druck der Community und der Medien hat Google die Schwachstelle schrittweise behoben: Zunächst wurden am 26. Dezember 13 Verweise entfernt, und am 1. Januar wurde dann die vollständige Behebung bestätigt. Diese schrittweise Reaktion spiegelt möglicherweise die Komplexität der internen Einführung und Priorisierung wider.

Die mangelnde Reaktionsfähigkeit von Windsurf ist besonders besorgniserregend, da die Plattform eine breite Basis von Unternehmensnutzern hat und lange Verzögerungen bei der Problembehebung bedeuten, dass diese Nutzer ständig einem Risiko ausgesetzt sind.

3.2 Rehabilitationsprogramm

Die Korrekturen von Cursor und Google beruhen auf den folgenden Grundsätzen:

Empfohlene Bereinigung der Liste:Entfernen von Verweiseinträgen, die auf nicht existierende Erweiterungen verweisen

Konfigurieren Sie die Kalibrierung:Überprüfen Sie während der Erstellung, ob die empfohlenen Erweiterungen in OpenVSX vorhanden sind

Namespace-Validierung:Vergewissern Sie sich, dass es sich bei dem empfohlenen Herausgeber um eine offiziell zertifizierte Identität handelt.

Version sperren:Hardcoding, um auf eine bestimmte Version einer Erweiterung zu verweisen, anstatt sich auf dynamisches Parsing zu verlassen

IV. ökologischer Schutz und langfristige Herausforderungen

4.1 Risikobereitschaft der Eclipse Foundation

Als Betreiber von OpenVSX hat die Eclipse Foundation systematische Abwehrmaßnahmen ergriffen:

Verbesserung der Namespace-Validierung:Einführung eines strengeren Authentifizierungsverfahrens für Verlage, um zu verhindern, dass Unbefugte offizielle Namensräume beanspruchen

Erweiterter Signatur-Mechanismus:Förderung der Einführung digitaler Signaturen für Erweiterungen, die es den Nutzern ermöglichen, die wahre Herkunft von Erweiterungen zu überprüfen

Sicherheitsaudit:Vollständige Überprüfung der deklarierten Namespaces in OpenVSX in Zusammenarbeit mit Koi Security, Identifizierung und Entfernung verdächtiger Einträge

Verbesserungen des Post-Workflows:Verbesserte Verwaltung von Anmeldeinformationen für CI/CD-Pipelines zur Verhinderung des Austretens von Umgebungsvariablen

4.2 Systemisches Risiko und das MITRE ATT&CK Framework Update

MITRE hat das ATT&CK-Framework im April 2025 offiziell um "IDE Extensions" erweitert und damit diese Art von Angriff zu einer umsetzbaren Bedrohungstechnik aufgewertet. Der Code für diese neue Technik lautet Txxxxdie die folgenden Teiltechnologien abdecken:

Empfehlungen für bösartige Erweiterungen:Verbreitung von bösartigen Erweiterungen über den Empfehlungsmechanismus der IDE

Erweitertes Namespace Hijacking:Registrierung und Angabe eines offiziellen Namensraums für Erweiterungen

Zurückladen von bösartigem Code:Einschleusen von bösartigem Code in legitime Erweiterungen über den Prozess der Erweiterungsaktualisierung

Die Aktualisierung spiegelt die Tatsache wider, dass die Branche das systemische Risiko von IDE-Erweiterungen als Angriffsvektoren allgemein erkannt hat.

4.3 Sicherheitsempfehlungen für Entwickler

In Anbetracht der Vertrauensbasis des erweiterten Empfehlungsmechanismus sollten die einzelnen Entwickler die folgenden Schutzmaßnahmen ergreifen:

Manuelle Validierung:Bevor Sie die empfohlene Erweiterung installieren, besuchen Sie manuell die OpenVSX-Website, um zu überprüfen, ob die Erweiterung tatsächlich von dem angegebenen Herausgeber stammt.

Der Grundsatz des geringsten Privilegs:Überprüfen Sie die installierten Erweiterungen regelmäßig, behalten Sie nur wichtige Erweiterungen und deaktivieren Sie inaktive Erweiterungen

Voucher Management:Vermeiden Sie die Speicherung sensibler Anmeldedaten im Klartext in IDEs; verwenden Sie Schlüsselverwaltungssysteme (z. B. 1Password, HashiCorp Vault)

Isolierung der Umwelt:Isolierung von IDE-Umgebungen mit Containerisierung oder VMs bei kritischen Projekten

Erweiterte Überwachung:Einsatz eines Endpunkt-Überwachungstools (EDR) zur Verfolgung des Netzwerkverhaltens und des Dateizugriffs für erweiterte Prozesse

4.4 Empfehlungen zur Governance auf Unternehmensebene

Für Organisationen, die KI-IDE einführen, wird der folgende Governance-Rahmen zur Umsetzung empfohlen:

Dimension der Governance	Spezifische Maßnahmen
Liste der Ressourcen	Pflege eines Live-Inventars aller bereitgestellten IDE-Versionen, einschließlich der Benutzer, Bereitstellungsorte und sensiblen Projektzuordnungen
Erweiterte Whitelist	Durchsetzung einer erweiterten Whitelist über IDE-Konfiguration, EDR-Regeln oder Netzwerkisolierung
Code Signing Verifizierung	Der Implementierungsprozess stellt sicher, dass der gesamte Code signiert und gescannt wird, bevor er veröffentlicht wird, um erweiterten, veränderten Code zu erkennen.
Log-Aggregation	Aggregieren Sie IDE-Prozessprotokolle, um Ereignisse wie Erweiterungsinstallationen, Aktivierungen, Netzwerkanrufe usw. zu verfolgen.
Bewertung der Lieferanten	Verlangen Sie von IDE-Anbietern Sicherheitsbewertungsberichte, SLAs für die Reaktion auf Schwachstellen und erweiterte Richtlinien zur Marktsteuerung.
Ausbildung Bewusstsein	Regelmäßige Sicherheitsschulungen für das Entwicklungsteam, mit Schwerpunkt auf Social Engineering und erweiterten Risiken

 

V. Systemisches Angriffsflächenrisiko

5.1 Anfälligkeit der VSCode-Ökologie

Das derzeitige Paradigma der IDE-Entwicklung weist tiefgreifende strukturelle Probleme auf:

Obwohl VSCode quelloffen ist, hat seine Monopolstellung in Unternehmensumgebungen dazu geführt, dass neue Anbieter es abspalten mussten, um schnell auf den Markt zu kommen. Das Forking-Modell übernimmt jedoch alle Konfigurationen, Abhängigkeiten und impliziten Annahmen des ursprünglichen Projekts, und die Verbreitung von Sicherheitsupdates wird durch die Fragmentierung erschwert. Dies birgt ein langfristiges Risiko in Form von technischen Schulden.

5.2 Die sich ausweitende Bedrohungslandschaft der AI IDE

KI-IDEs bieten eine neue Angriffsfläche im Vergleich zu herkömmlichen IDEs:

LLM modellierte Vergiftung:Die böswillige Eingabe von Prompt-Wörtern kann dazu führen, dass Modelle Code mit Hintertüren erzeugen

Kontext Leaks:KI-Modelle können bei der Verarbeitung von Code sensible Informationen an die Cloud senden

Anhebung der Privilegien:KI-Agentenmodi können bei der autonomen Ausführung von Aufgaben die vom Benutzer festgelegten Berechtigungsgrenzen überschreiten

5.3 Erwartungen der Industrie und der Regulierungsbehörden

Der regulatorische Fokus auf die Sicherheit der Lieferkette erreicht im Jahr 2025 einen neuen Höchststand. Sowohl die U.S. Cybersecurity Executive Order 14144 als auch der Cyber Resilience Act der Europäischen Union stellen klare Anforderungen an die Software-Lieferkette. Vor diesem Hintergrund sehen sich IDE-Anbieter den folgenden Zwängen ausgesetzt:

Implementierung von SBOM (Software Bill of Materials) Publikation Erweiterte Dependenz

Zusagen für die Behebungszeit (SLAs) und öffentliche Bekanntgabe der Antworten

Nachweis der Sicherheit erweiterter Märkte durch dreigliedrige Audits

vi. schlussfolgerungen und empfehlungen

Die Sicherheitsverletzung spiegelt das grundlegende Spannungsverhältnis zwischen schneller Innovation und Sicherheitsvorkehrungen für neu entstehende KI-Entwicklungstools wider. Die schnelle Reaktion von Cursor setzte Maßstäbe für die Branche, während die Verzögerungen bei Google und Windsurf die unterschiedlichen Sicherheitsprioritäten in den Unternehmen deutlich machten.

Wichtige Empfehlungen:

1. Sofortige Maßnahmen: alle AI IDE-Benutzer sollten auf die neueste Version aktualisieren (Cursor ≥ feste Version, Google Antigravity ≥ 1. Januar Version), und Windsurf-Benutzer sollten die Migration zu einer festen Alternative oder die proaktive Einschränkung von Erweiterungen in Betracht ziehen.
2. Eco-Governance: Die Eclipse Foundation sollte die Sicherheitsmechanismen von OpenVSX weiter stärken und regelmäßige Sicherheitsvereinbarungen mit allen nachgelagerten IDE-Anbietern treffen.
3. Technische Standards: schlägt vor, dass die OWASP- und CWE-Gemeinschaften einen standardisierten Rahmen für die Erkennung und Eindämmung von IDE-Erweiterungsangriffen schaffen
4. Langfristige Investitionen: Förderung der Integration generativer KI in Entwicklungswerkzeuge und Einrichtung geeigneter Sicherheitsbewertungssysteme

Der Vorfall erinnerte die Entwicklergemeinschaft auch daran, dass das Vertrauen nicht auf einem einzigen automatischen Empfehlungsmechanismus beruhen sollte. In einer Zeit, in der KI-gestützte Tools zunehmend in den Entwicklungsprozess eingebettet werden, sind eine manuelle Überprüfung und mehrere Verteidigungsebenen weiterhin unerlässlich.

Referenzquelle:

BleepingComputer: "VSCode IDE forks expose users to 'recommended extension' attacks". 2026/1. /5.
https://www.bleepingcomputer.com/news/security/vscode-ide-forks-expose-users-to-recommended-extension-attacks/
Codecademy. "Agentic IDE Comparison: Cursor vs Windsurf vs Antigravity." 2025/12/29.
https://www.codecademy.com/article/agentic-ide-comparison-cursor-vs-windsurf-vs-antigravity
Veracode: "Software Supply Chain Attacks in 2025". 2025/9/23.

Angriffe auf die Software-Lieferkette im Jahr 2025: Was wir von Gartner® gelernt haben

The Hacker News: "Kritischer Fehler in der Open VSX-Registrierung gefährdet Millionen von Entwicklern", 2025/6/26.
https://thehackernews.com/2025/06/critical-open-vsx-registry-flaw-exposes.html
Silobreaker. "12 Monate, die die Sicherheit der Lieferkette verändert haben". 2025/12/16.
https://www.silobreaker.com/blog/cyber-threats/supply-chain-attacks-in-2025-a-month-by-month-summary/
Security Affairs: "Übernahme von Millionen von Entwicklern durch Ausnutzung einer Schwachstelle in der Open VSX-Registrierung", 2025/6/26.
https://securityaffairs.com/179398/hacking/taking-over-millions-of-developers-exploiting-an-open-vsx-registry-flaw.html
OWASP: "A03 Software Supply Chain Failures - OWASP Top 10:2025".
https://owasp.org/Top10/2025/A03_2025-Software_Supply_Chain_Failures/
Koi Security. "Wie wir mit einer VSCode-Gabel jeden Entwickler hätten übernehmen können". 2025/6/25.
https://www.koi.ai/blog/marketplace-takeover-how-we-couldve-taken-over-every-developer-using-a-vscode-fork-putting-millions-at-risk
Microsoft: "Shai-Hulud 2.0: Anleitung zum Erkennen, Untersuchen und Verteidigen". 2025/12/8. https://www.microsoft. com/de-us/security/blog/2025/12/09/shai-hulud-2-0-guidance-for-detecting-investigating-and-defending
Koi Security: "Wie wir Cursor, Windsurf und Google Antigravity daran gehindert haben, Malware zu empfehlen". 2026/1/5.
https://www.koi.ai/blog/how-we-prevented-cursor-windsurf-google-antigravity-from-recommending-malware
Eclipse Foundation: "Schwachstelle im Veröffentlichungsprozess der Eclipse Open VSX Registry-Erweiterung", 2025/6/26.
https://newsroom.eclipse.org/news/announcements/vulnerability-eclipse-open-vsx-marketplace-extension-publication-process