Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-14T09:17:01.797Z",
  "pubdate": "2026-09-14T09:17:01.797Z",
  "executiveSummary": "This vulnerability is an Unbounded Zip Extraction flaw affecting the WebResourceService component of the extension publishing infrastructure. The system fails to enforce size constraints on decompressed files during the extraction process triggered by requests to /vscode/unpkg/{namespace}/{extension}/{version}/{path}. By uploading a highly compressed VSIX file, an authenticated attacker can force the server to write disproportionately large files to the local disk, leading to total exhaustion of the temporary filesystem space. This results in a persistent denial-of-service condition where the server is unable to process new file requests, cache entries, or perform internal publishing operations. Although the initial upload requires namespace authorization, the triggering mechanism is publicly accessible, allowing for unauthenticated exploitation once the malicious payload is staged. The lack of size-based cache eviction exacerbates the impact, as cached files effectively occupy permanent disk space until the system is manually remediated. The risk is critical, as it directly compromises the availability of the extension publishing service by leveraging legitimate decompression functions to bypass published content size limits.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper handling of compressed input streams within the WebResourceService. When the /vscode/unpkg endpoint is accessed, the service utilizes ZipFile.getInputStream() to decompress VSIX contents. The application subsequently streams this data to the local disk using Files.copy() without implementing a threshold or byte-count check on the resulting output. While the publishing platform enforces a 512 MB limit (ovsx.publishing.max-content-size) on the compressed VSIX artifact, it does not account for the compression ratio. An attacker can craft a 'zip bomb'—a small, highly compressible file that expands to several gigabytes upon extraction.\nThe attack flow proceeds as follows: First, a publisher with access to a specific namespace uploads a maliciously crafted, highly compressed VSIX. Second, the attacker (or any unauthenticated actor) sends a request to the /vscode/unpkg path corresponding to the uploaded artifact. Third, the WebResourceService initiates the extraction process. Because the Files.copy() operation runs to the end of the decompressed stream, the server writes the full uncompressed data to java.io.tmpdir. Fourth, the server caches the file; however, the caching mechanism only enforces an entry count limit of 150, ignoring the physical size of the files stored on disk. By requesting multiple versions or files, an attacker can rapidly saturate the available disk capacity of the host system.\nThe post-exploitation impact is significant. Once the temporary filesystem reaches maximum capacity, all requests for new, uncached files result in HTTP 500 errors ('No space left on device'). Furthermore, failed write attempts during the decompression process result in partial, corrupted cache files that permanently block subsequent attempts to access those specific paths, requiring manual administrative intervention to clear the temp directory. This state persists across service reboots if the temp storage is not purged. The vulnerability is highly effective because it exploits the decoupling of the ingestion limit (compressed size) from the processing limit (decompressed output size), effectively circumventing the infrastructure's protective boundaries without requiring elevated system privileges."
}