CVE-2026-89321 in OpenVSX
Zusammenfassung
von VulDB • 14.09.2026
Die Veröffentlichung beschränkt die komprimierte Größe einer VSIX-Datei (ovsx.publishing.max-content-size, standardmäßig 512 MB), aber es gab keine Begrenzung dafür, wie groß ein Eintrag beim Öffnen werden kann.
Bei der ersten Anfrage an /vscode/unpkg/{namespace}/{extension}/{version}/{path} öffnete WebResourceService den Eintrag mit ZipFile.getInputStream() und übergab den dekomprimierten Stream an Files.copy(), welcher bis zum Ende des Streams lief, ohne die geschriebenen Bytes zu zählen. Das Ergebnis wurde unter java.io.tmpdir zwischengespeichert, und dieser Cache wird nach Anzahl der Einträge (150) verworfen, nicht nach Größe, sodass keine Begrenzung für den Festplattenspeicherplatz bestand.
Ein Publisher mit Zugriff nur auf sein eigenes Namespace konnte daher eine kleine, stark komprimierbare VSIX-Datei hochladen und dazu führen, dass der Server viel größere Dateien im temporären Dateisystem schreibt – wiederholt mit verschiedenen Dateien oder Versionen, da eine erneute Anfrage aus dem Cache bedient wird.
Beobachtete Auswirkungen: Das temporäre Dateisystem füllte sich; Anfragen für nicht bereits zwischengespeicherte Dateien gaben 500 mit "No space left on device" zurück; ein fehlgeschlagener Extraktionsversuch hinterließ eine teilweise Caching-Datei, die spätere Versuche an diesem Pfad blockierte; das Veröffentlichen schlug mit "Failed to read extension file" fehl. Metadaten und bereits zwischengespeicherte Dateien blieben funktionsfähig, und der Server stoppte nicht.
Das Auslösen der Extraktion erfordert keine Authentifizierung – nur das Hochladen ist authentifiziert.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.