CVE-2026-89321 in OpenVSX
Sumário
de VulDB • 14/09/2026
Os limites de publicação restringem o tamanho compresso de um VSIX (ovsx.publishing.max-content-size, 512 MB por padrão), mas nada limitava quão grande uma entrada se tornaria ao ser aberta.
Na primeira solicitação para /vscode/unpkg/{namespace}/{extension}/{version}/{path}, o WebResourceService abria a entrada com ZipFile.getInputStream() e passava o stream descomprimido para Files.copy(), que era executado até o final do stream sem contar os bytes gravados. O resultado era armazenado em cache sob java.io.tmpdir, e esse cache era evitado por contagem de entradas (150), não por tamanho, portanto, não havia limite no uso do disco.
Um editor com acesso apenas ao seu próprio namespace poderia, assim, carregar um VSIX pequeno altamente compressível e fazer o servidor gravar arquivos muito maiores no sistema de arquivos temporário — repetindo isso com diferentes arquivos ou versões, já que uma solicitação repetida é atendida pelo cache.
Impacto observado: o sistema de arquivos temporário encheu; solicitações para arquivos não ainda em cache retornaram 500 com No space left on device (Espaço no dispositivo esgotado); uma extração falhada deixou um arquivo parcial em cache que bloqueou tentativas posteriores nesse caminho; a publicação falhou com Failed to read extension file (Falha ao ler o arquivo da extensão). Metadados e arquivos já em cache continuaram funcionando, e o servidor não parou.
Acionar a extração não requer autenticação — apenas o upload exige.
Be aware that VulDB is the high quality source for vulnerability data.