CVE-2026-89321
MediumCVSS 4.3Summary
The VSIX publishing service limits the compressed file size (ovsx.publishing.max-content-size, 512 MB by default) but does not limit the decompressed entry size. WebResourceService opens the entry via ZipFile.getInputStream() and copies the decompressed stream without counting bytes, and the java.io.tmpdir cache is evicted by entry count (150), not size, allowing a publisher with their own namespace to fill the temp filesystem.
Risk Assessment
An unauthenticated attacker can repeatedly trigger decompression and fill the temp filesystem, causing 500 errors (No space left on device) for uncached files and publishing failures, resulting in partial denial of service.
Recommendation
Upgrade the service to a version with a decompressed entry size limit and size-based caching, and in the meantime monitor and clean the temp directory.
Other vulnerabilities in Open VSX Registry
See all- CVE-2026-13323Medium
In Open VSX Registry before version 1.0.2, the /vscode/unpkg/ endpoint serves user-supplied HTML files with Content-Type: text/html and without Content-Security-Policy or Content-Disposition: attachment headers. An unauthenticated attacker can register a publisher account, upload a VSIX containing a crafted HTML payload, and trick an authenticated user into visiting the resulting URL.
- CVE-2026-4983Medium
The Open VSX Registry does not sanitize SVG files uploaded as extension icons prior to storage, allowing the publication of a malicious extension with an SVG icon. This leads to stored XSS attacks when a user navigates directly to the icon URL.
Original NVD description (English source)
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.