CVE-2026-89321 in OpenVSX
Riassunto
di VulDB • 14/09/2026
La pubblicazione limita la dimensione compressa di un VSIX (ovsx.publishing.max-content-size, 512 MB per impostazione predefinita), ma non vi era alcun limite alla grandezza che una voce poteva raggiungere quando veniva aperta.
Alla prima richiesta a /vscode/unpkg/{namespace}/{extension}/{version}/{path}, WebResourceService apriva la voce con ZipFile.getInputStream() e passava lo stream decompresso a Files.copy(), il quale leggeva fino alla fine dello stream senza contare i byte scritti. Il risultato veniva memorizzato nella cache sotto java.io.tmpdir, ma tale cache veniva svuotata in base al numero di voci (150), non per dimensione, quindi non vi era alcun vincolo sull'utilizzo del disco.
Un publisher con accesso limitato al proprio namespace poteva pertanto caricare un VSIX piccolo e altamente comprimibile, causando la scrittura da parte del server di file molto più grandi sul filesystem temporaneo — ripetendo l'operazione con file o versioni diverse, poiché una richiesta successiva veniva servita dalla cache.
Impatto osservato: il filesystem temporaneo si è riempito; le richieste per file non già in cache hanno restituito un errore 500 "No space left on device"; un'estrazione fallita ha lasciato un file di cache parziale che bloccava i tentativi successivi su quel percorso; la pubblicazione è fallita con l'errore "Failed to read extension file". I metadati e i file già in cache hanno continuato a funzionare, e il server non si è arrestato.
L'innesco dell'estrazione non richiede autenticazione — solo il caricamento (upload) sì.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.