Skip to content
Fencer Intel
medium 4.3

CVE-2026-89321 json

Extracting VSIX entries can fill the server's temporary storage

published last mo. modified last mo. also EUVD-2026-77328 , GHSA-h685-gqw7-fqw7

Unreviewed: the maintainers' own advisory

Published by the maintainers on their GitHub repository eclipse-openvsx/openvsx. GitHub has not reviewed it into the GitHub Advisory Database, so the affected packages and versions are the maintainers' word. Read the full advisory on GitHub.

cvss
4.3
version 3.1, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.4%
EPSS 0.4% chance of exploitation in 30 days, percentile 38%
public exploits
0
none known

Summary

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.

Patch / fix

  • Eclipse Foundation Eclipse OpenVSX 1.2.0

Is CVE-2026-89321 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2026-89321 updated cvss 7.5

openvsx: OpenVSX: Denial of Service via uncontrolled temporary file growth

  • Red Hat OpenShift Dev Spaces devspaces/openvsx-rhel9
    affected: workaround, no fix available

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
partial
Assessed
last mo.

Exploit prediction

0.44% chance of exploitation in the next 30 days, higher than 38% of all scored CVEs (FIRST EPSS, 2026-11-11).

CVSS scores

assigned by version score vector
CNA 3.1 4.3 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L

Affected products

  • Eclipse Foundation Eclipse OpenVSX

Classification

Weakness
  • CWE-409 Improper Handling of Highly Compressed Data (Data Amplification)

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.

The maintainers of eclipse-openvsx/openvsx published their own advisory on GitHub. Reviewed sources take precedence over it.