CVE-2026-89321: Medium severity Microsoft Visual Studio Code Web (VSIX unpkg /vscode/unpkg) / WebResourceService vulnerability
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.
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs publishing access to a namespace they control. They can upload a small, highly compressible VSIX and trigger extraction through a request to its unpkg path.
Are default deployments affected?
Yes. The default publishing limit is 512 MB compressed, but the affected extraction path did not limit decompressed output, and its temporary-file cache evicted entries by count rather than size.
What operational symptoms indicate exploitation or exposure?
The temporary filesystem can fill, causing uncached file requests to return 500 errors with "No space left on device." Publishing can also fail with "Failed to read extension file," and a failed extraction may leave a partial cache file that blocks later attempts for that path.
What remains available when the temporary filesystem is exhausted?
Metadata and files already present in the cache continue to work. The server itself does not stop, but requests requiring new extraction can fail.