Open VSX: Sicherheitslücke hebelt Extension-Checks aus : Fehlerhafte Scan-Logik lässt manipulierte Erweiterungen unbemerkt passieren
Ein kritischer Designfehler in der Sicherheitsprüfung von Open VSX ermöglichte es Angreifern, schädliche Microsoft Visual Studio Code- (VS Code)Erweiterungen trotz vorhandener Schutzmechanismen zu veröffentlichen. Ursache war eine fehlerhafte Logik in der Scan-Pipeline, die Ausfälle nicht korrekt erkannte und Erweiterungen fälschlich freigab.
Sicherheitsanalysten haben eine inzwischen geschlossene Schwachstelle in der Pre-Publish-Scan-Pipeline von Open VSX offengelegt. Die Plattform dient als zentrales Erweiterungs-Repository für zahlreiche Entwicklungsumgebungen wie Cursor, Windsurf und weitere Ableger von Visual Studio Code und spielt damit eine entscheidende Rolle in der Softwarelieferkette. Ziel der noch relativ neuen Sicherheitsprüfung war es, bösartige Erweiterungen bereits vor der Veröffentlichung zu stoppen – doch genau dieser Mechanismus ließ sich aushebeln.
Im Kern des Problems stand eine fehlerhafte Logik innerhalb des Scan-Systems. Die Pipeline lieferte einen einzigen booleschen Rückgabewert, um zwei völlig unterschiedliche Zustände abzubilden. „Die Pipeline gab nur einen einzigen Wahrheitswert zurück – und der stand sowohl für ‚es gibt nichts zu prüfen‘ als auch für ‚die Prüfung ist fehlgeschlagen‘“, so Oran Simhony von Koi Security. „Das System konnte den Unterschied nicht erkennen. Fielen die Scanner unter Last aus, wurde das so interpretiert, als gäbe es nichts zu prüfen – und die Erweiterung wurde einfach freigegeben.“
Angriff ohne Privilegien möglich
Besonders kritisch ist die niedrige Einstiegshürde für Angreifer. Es waren keine erweiterten Berechtigungen erforderlich:
• kostenloses Publisher-Konto ausreichend
• kein Zugriff auf interne Systeme notwendig
• keine Umgehung von Authentifizierungsmechanismen
Angreifer konnten gezielt mehrere manipulierte Erweiterungspakete im .VSIX-Format hochladen und so eine hohe Systemlast erzeugen. Diese Last führte dazu, dass die Scan-Jobs nicht mehr korrekt in die Warteschlange eingereiht werden konnten. Die Folge:
• Erschöpfung des Datenbank-Verbindungspools
• Fehlschlag der Scan-Prozesse
• fälschliche Freigabe schädlicher Erweiterungen
Kaskadeneffekt durch fehlerhafte Wiederherstellung
Ein zusätzlicher Schwachpunkt verschärfte die Situation weiter. Ein Recovery-Dienst, der eigentlich fehlgeschlagene Scans erneut ausführen sollte, war vom gleichen Logikfehler betroffen. Dadurch konnten Erweiterungen unter bestimmten Bedingungen die gesamte Sicherheitsprüfung vollständig umgehen.
Diese Verkettung von Fehlern machte die Schutzmaßnahme praktisch wirkungslos, sobald das System unter Last geriet.
„Fail-Open“ als gefährliches Anti-Pattern
Die Forscher bewerten das Verhalten als klassisches Beispiel für ein sogenanntes Fail-Open-Design – ein riskantes Muster in sicherheitskritischen Systemen. Zwar war die Pipeline grundsätzlich sinnvoll konzipiert, doch ein einzelner Wahrheitswert, der nicht zwischen „nichts zu tun“ und „Fehler aufgetreten“ unterscheiden konnte, machte die gesamte Schutzlogik anfällig. Unter Last öffnete sich das System faktisch wie ein Tor, statt Angriffe zu blockieren.
Besonders kritisch ist dabei, dass Fehlerzustände nicht eindeutig behandelt werden. Stattdessen teilen sich legitime Zustände und tatsächliche Fehlersituationen denselben Rückgabewert. Dadurch bleiben Probleme im System unbemerkt – mit der Folge, dass Sicherheitsmechanismen stillschweigend versagen und schädliche Inhalte durchgewinkt werden.
Die klare Empfehlung der Experten lautet daher:
• Fehlerzustände explizit modellieren
• keine Vermischung von „kein Bedarf“ und „Fehler“ zulassen
• Fail-Closed statt Fail-Open implementieren
Reaktion und Behebung
Die Schwachstelle mit dem Codenamen „Open Sesame“ wurde nach verantwortungsvoller Meldung am 8. Februar 2026 behoben. Mit Version 0.32.0 hat die Eclipse Foundation entsprechende Korrekturen implementiert.
Die Einführung von Pre-Publish-Scans bleibt dennoch ein wichtiger Schritt im Kampf gegen bösartige Erweiterungen, zeigt der Fall doch deutlich, dass selbst zusätzliche Sicherheitsschichten neue Angriffsflächen schaffen können. Das gilt insbesondere dann, wenn grundlegende Designprinzipien nicht konsequent umgesetzt werden.
Eine saubere Fehlerbehandlung in sicherheitskritischen Pipelines bleibt also entscheidend. Eine einzige fehlerhafte Designentscheidung kann ausreichen, um komplexe Schutzmechanismen vollständig auszuhebeln.
Gerade in Zeiten zunehmender Angriffe auf Softwarelieferketten gilt: Sicherheit entsteht nicht durch zusätzliche Prüfungen allein, sondern durch robuste, eindeutig definierte Systemzustände – auch und insbesondere im Fehlerfall.