CVE-2026-89321 in OpenVSX
Résumé
par VulDB • 14/09/2026
La publication limite la taille compressée d’un VSIX (ovsx.publishing.max-content-size, 512 Mo par défaut), mais rien ne limitait la taille qu’une entrée pouvait atteindre une fois décompressée.
Lors de la première requête adressée à /vscode/unpkg/{namespace}/{extension}/{version}/{path}, WebResourceService ouvrait l’entrée avec ZipFile.getInputStream() et transmettait le flux décompressé à Files.copy(), qui lisait jusqu’à la fin du flux sans compter les octets écrits. Le résultat était mis en cache sous java.io.tmpdir, et ce cache était évacué selon le nombre d’entrées (150), et non par taille, ce qui n’imposait aucune limite à l’utilisation de l’espace disque.
Un éditeur disposant uniquement des droits sur son propre namespace pouvait donc télécharger un VSIX petit mais hautement compressible, provoquant ainsi l’écriture de fichiers bien plus volumineux dans le système temporaire — en répétant l’opération avec différents fichiers ou versions, car une requête identique est servie depuis le cache.
Impact observé : le système de fichiers temporaire s’est rempli ; les demandes de fichiers non encore mis en cache ont renvoyé un code 500 « No space left on device » (plus d’espace disponible sur l’appareil) ; une extraction ayant échoué a laissé un fichier partiel dans le cache, bloquant les tentatives ultérieures pour ce même chemin ; la publication a échoué avec le message « Failed to read extension file ». Les métadonnées et les fichiers déjà mis en cache ont continué de fonctionner, et le serveur n’a pas cessé de s’exécuter.
Le déclenchement de l’extraction ne nécessite aucune authentification — seule l’upload (téléversement) est protégée par une vérification d’identité.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.