CVE-2026-89321
Received Received - Intake

VSIX Archive Extraction Leading to Disk Exhaustion

Publication date: 2026-09-14

Last updated on: 2026-09-14

Assigner: Eclipse Foundation

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-09-14
Last Modified
2026-09-14
Generated
2026-09-14
AI Q&A
2026-09-14
EPSS Evaluated
N/A
NVD
CVE-2026-89321
EUVD
EUVD-2026-77328

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
eclipse openvsx *

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-409 The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability involves a lack of size limits when decompressing VSIX packages served via the /vscode/unpkg endpoint. The server only enforced limits on compressed upload size but not on decompressed file size. A highly compressible VSIX entry could expand to an arbitrarily large file on disk when requested, risking filesystem exhaustion.

Detection Guidance

Monitor disk usage in the Java temporary directory where cached files are stored. Check for repeated 500 errors from /vscode/unpkg endpoints and failed extraction attempts. Look for partial cache files blocking retries in java.io.tmpdir.

Impact Analysis

An attacker with access to upload a VSIX could cause the server's temp filesystem to fill up by repeatedly requesting decompression of a small, highly compressible file. This could lead to disk exhaustion, failed requests, and service disruption. Partial cache files from failed extractions could block future attempts.

Compliance Impact

This vulnerability could lead to disk exhaustion attacks, causing service disruption or data unavailability. For GDPR, this may impact availability of personal data processing systems. For HIPAA, it could disrupt access to protected health information systems. Both standards require availability controls, and this flaw undermines those requirements by allowing denial-of-service conditions.

Mitigation Strategies

Apply the patch from PR #2060 to enforce decompressed size limits and switch to size-based cache eviction. Set ovsx.caching.files-webresource.max-file-size to a reasonable value and enable size-based cache limits with ovsx.caching.files-webresource.max-total-size.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-89321. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart