Die von Koi Security entdeckte und auf den Namen „Open Sesame" getaufte Schwachstelle betrifft die Art, wie der in Java geschriebene Dienst seine Scan-Ergebnisse meldet. Der Kern des Problems: Der Dienst interpretierte fehlgeschlagene Scanner-Jobs fälschlicherweise als „keine Scanner konfiguriert". In der Folge wurde eine Erweiterung als bestanden markiert, sofort aktiviert und über Open VSX zum Download bereitgestellt.

Derselbe Defekt griff auch in einem zweiten Szenario: wenn Scanner zwar vorhanden waren, die Jobs aber fehlschlugen und sich nicht einreihen ließen, weil der Verbindungspool zur Datenbank erschöpft war. Besonders problematisch ist laut Koi, dass ein Wiederherstellungsdienst, der fehlgeschlagene Scans eigentlich erneut anstoßen sollte, am gleichen Fehler litt. Unter bestimmten Bedingungen ließ sich dadurch der gesamte Scan-Vorgang überspringen.

Ein Angreifer konnte die Schwäche gezielt ausnutzen, indem er den Veröffentlichungs-Endpunkt mit mehreren schädlichen .VSIX-Erweiterungen flutete. Die dadurch erzeugte gleichzeitige Last erschöpfte den Datenbank-Verbindungspool, woraufhin die Scan-Jobs nicht mehr eingereiht werden konnten.

Bemerkenswert ist, dass der Angriff keinerlei besondere Rechte erforderte. Ein böswilliger Akteur mit einem kostenlosen Veröffentlichungskonto hätte die Lücke zuverlässig auslösen können, um den Prüfprozess auszuhebeln und seine Erweiterung zu veröffentlichen. Behoben wurde das Problem in Open VSX 0.32.0 in diesem Monat, nachdem die Forscher die Schwachstelle am 8. Februar 2026 im Rahmen einer verantwortungsvollen Offenlegung gemeldet hatten.

„Vorab-Scans sind eine wichtige Schicht, aber eben nur eine Schicht", erklärte Koi. Das Design der Pipeline sei zwar solide, doch ein einzelner boolescher Wert, der nicht zwischen „nichts zu tun" und „etwas ist schiefgelaufen" unterscheiden konnte, habe die gesamte Infrastruktur in ein Tor verwandelt, das sich unter Druck öffnete.

Koi beschreibt das als verbreitetes Anti-Muster: eine im Fehlerfall offen bleibende Verarbeitung, die sich hinter einem Codepfad versteckt, der eigentlich für den legitimen Fall „nichts zu tun" gedacht ist. Wer ähnliche Pipelines baue, solle Fehlerzustände ausdrücklich kennzeichnen und niemals „keine Arbeit nötig" und „Arbeit fehlgeschlagen" denselben Rückgabewert teilen lassen.