Die von Koi Security entdeckte Schwachstelle offenbart ein subtiles, aber gravierendes Designproblem: Die Scanning-Pipeline konnte nicht zwischen zwei Zuständen unterscheiden – einerseits “keine Scanner konfiguriert” und andererseits “alle Scanner konnten nicht ausgeführt werden”. Diese Mehrdeutigkeit eines einzelnen Boolean-Wertes führte dazu, dass fehlgeschlagene Scanner-Prozesse als erfolgreiche Sicherheitsprüfung interpretiert wurden.
“Die Pipeline nutzte einen einzigen booleschen Rückgabewert für beide Szenarien,” erklärt Oran Simhony von Koi Security. “Der Aufrufer konnte den Unterschied nicht erkennen. Wenn Scanner unter Last fehlschlugen, behandelte Open VSX dies als ’nichts zu scannen’ und ließ die Erweiterung einfach durch.”
Die Attacke könnte von jedem Angreifer mit einem kostenlosen Publisher-Konto durchgeführt werden – ohne spezielle Privilegien erforderlich. Die Methode war elegant und zerstörerisch zugleich: Durch das Überfluten des Publish-Endpunkts mit mehreren bösartigen .VSIX-Dateien erschöpfte der Angreifer den Datenbank-Verbindungspool. Dies führte dazu, dass Scanner-Jobs nicht eingereiht werden konnten und somit in den fehlgeschlagenen Zustand übergingen – mit den beschriebenen Konsequenzen.
Besonders besorgniserregend war, dass auch der Recovery-Service, der fehlgeschlagene Scans wiederholen sollte, von demselben Problem betroffen war. Dadurch konnten Erweiterungen unter bestimmten Bedingungen den gesamten Scanning-Prozess umgehen.
Die Eclipse Foundation handelte schnell und veröffentlichte ein Patch in Open VSX Version 0.32.0 nach verantwortungsvoller Offenlegung am 8. Februar 2026. Dennoch warnt Koi Security vor einem größeren Anti-Pattern: “Pre-Publish-Scanning ist eine wichtige Sicherheitsschicht, aber eben nur eine,” heißt es in der Analyse. “Das Design der Pipeline ist grundsätzlich sound, doch ein einziger Boolean, der nicht zwischen ’nichts zu tun’ und ’etwas ist schief gelaufen’ unterscheiden konnte, verwandelte die gesamte Infrastruktur in ein Tor, das unter Druck offenstand.”
Die Lektion für Entwickler ist klar: Fehlerzustände müssen explizit gemacht werden. Niemals sollten “keine Arbeit erforderlich” und “Arbeit ist fehlgeschlagen” denselben Rückgabewert teilen. Dies war nicht nur ein einzelner Bug, sondern ein Symptom schlechten Fehlerhandling-Designs, das in ähnlichen Systemen zu achten ist.