CVE-2026-89321

Published Sep 14, 2026 CVSS 3.1 · 4.3 Medium EPSS < 1% KEV · Not listed
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.

Analysis

AI-generated

Technical impact

The vulnerability originates from Eclipse OpenVSX’s handling of VSIX files. The server accepts a VSIX of up to 512 MB in its compressed form, but it imposes no limit on the size of the file once it is extracted. When the server first receives a request for a VSIX path, it opens the archive, streams the contents to a temporary file, and writes the decompressed data without tracking the number of bytes written. The temporary cache is evicted only by entry count, not by size, so an attacker can repeatedly upload highly compressible VSIX packages to cause the server to create very large temporary files. This depletes the disk containing the temporary directory, resulting in 500 responses with “No space left on device”, failed extraction errors, and publication failures for the attacker’s own extensions. The effect is a denial of service that undermines availability, without leaking confidential data or allowing arbitrary code execution.

Affected Systems

Eclipse Foundation Eclipse OpenVSX (all versions). The issue is present in any deployment of the open-source runtime that has not yet incorporated the fix referenced in the advisories linked above.

Risk and Exploitability

The CVSS score of 4.3 indicates a moderate severity. The EPSS score of less than 1 % suggests that, although exploitation is technically straightforward, the likelihood of exploitation is low. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Attackers only need the ability to publish a new extension in their own namespace; no authentication is required to trigger the decompression. Once an attacker’s VSIX is cached, subsequent requests are served from the temporary cache, amplifying the impact. The lack of disk‑space controls exposes the server to a resource‑exhaustion denial‑of‑service attack that can be triggered by legitimate users who can upload extensions.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade Eclipse OpenVSX to the latest release that incorporates the fix for this vulnerability.
  • Configure a strict disk quota or limit on the directory used for temporary files to prevent disk exhaustion.
  • Disable or modify the temporary caching mechanism so that it evicts entries based on size rather than count, or remove the cache entirely.
  • Monitor disk usage on the server’s temp filesystem and set alerts for thresholds that approach capacity.

Generated by OpenCVE AI on September 15, 2026 at 15:00 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories available
History
Type Values Removed Values Added
Title Disk Exhaustion via Malicious VSIX Upload in Eclipse OpenVSX
Type Values Removed Values Added
Title Disk Exhaustion via Malicious VSIX Upload in Eclipse OpenVSX
Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Type Values Removed Values Added
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.
Weaknesses CWE-409
References
Metrics cvssV3_1

{'score': 4.3, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L'}

Subscriptions

No data.

Weaknesses
  • CWE-409

    Improper Handling of Highly Compressed Data (Data Amplification)

Sources

Status
PUBLISHED
Assigner
eclipse
Published
Updated
Sep 14, 2026, 10:30 AM
Reserved
Sep 11, 2026, 1:59 PM
Status
Awaiting Analysis
Published
Sep 14, 2026, 9:17 AM
Modified
Sep 16, 2026, 8:38 PM