CVE-2026-89321
ŚrednieCVSS 4.3Streszczenie
W usłudze publikowania VSIX limitowany jest rozmiar skompresowanego pliku (ovsx.publishing.max-content-size, domyślnie 512 MB), ale nie ma limitu rozmiaru wpisu po dekompresji. WebResourceService otwiera wpis przez ZipFile.getInputStream() i kopiuje zdekompresowany strumień bez liczenia bajtów, a cache w java.io.tmpdir jest usuwany po liczbie wpisów (150), nie po rozmiarze, co pozwala wydawcy z własnym namespace zapełnić dysk tymczasowy.
Ocena ryzyka
Nieuwierzytelniony atakujący może wielokrotnie wywołać dekompresję i zapełnić system plików tymczasowych, powodując błędy 500 (No space left on device) dla niebuforowanych plików oraz niepowodzenia publikacji, co prowadzi do częściowej odmowy usługi.
Rekomendacja
Zaktualizuj usługę do wersji z limitem rozmiaru dekompresowanego wpisu i cache'owaniem opartym na rozmiarze, a w międzyczasie monitoruj i czyść katalog tymczasowy.
Inne podatności w Open VSX Registry
Zobacz wszystkie- CVE-2026-13323Średnie
W Open VSX Registry przed wersją 1.0.2 endpoint /vscode/unpkg/ serwuje pliki HTML dostarczone przez użytkownika z typem MIME text/html i bez nagłówków Content-Security-Policy ani Content-Disposition: attachment. Nieuwierzytelniony atakujący może zarejestrować konto wydawcy, przesłać rozszerzenie VSIX z złośliwym ładunkiem HTML i nakłonić uwierzytelnionego użytkownika do odwiedzenia spreparowanego URL.
- CVE-2026-4983Średnie
Rejestr Open VSX nie sanitizuje plików SVG przesyłanych jako ikony rozszerzeń przed ich zapisaniem, co pozwala na publikację złośliwego rozszerzenia z ikoną SVG. To prowadzi do przechowywanego ataku XSS, gdy użytkownik odwiedza bezpośrednio URL ikony.
Oryginalny opis (angielski, źródło NVD)
Publishing limits the compressed size of a VSIX (ovsx.publishing.max-content-size, 512 MB by default) but nothing limited how large an entry becomes when opened. On the first request to /vscode/unpkg/{namespace}/{extension}/{version}/{path}, WebResourceService opened the entry with ZipFile.getInputStream() and passed the decompressed stream to Files.copy(), which ran to the end of the stream without counting bytes written. The result was cached under java.io.tmpdir, and that cache evicted by entry count (150), not by size, so it placed no bound on disk usage. A publisher with access only to their own namespace could therefore upload a small, highly compressible VSIX and cause the server to write far larger files to the temp filesystem — repeating with different files or versions, since a repeat request is served from the cache. Impact observed: the temp filesystem filled; requests for files not already cached returned 500 with No space left on device; a failed extraction left a partial cache file that blocked later attempts at that path; publishing failed with Failed to read extension file. Metadata and already-cached files kept working, and the server did not stop. Triggering the extraction needs no authentication — only the upload does.