Skip to main content
VulnerabilityPublished

CVE-2026-89321: Eclipse OpenVSX · data amplification

Affects Eclipse OpenVSXSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 4.3 Medium : upgrade to 1.2.0 when convenient.

Data as of 29 Oct 2026, 10:37 UTC

CVSS 3.1 base score
4.3Medium
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.4% chance of exploitation in 30 days – higher than 38% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 1.2.0
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 14 Sep 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.

What to do

Upgrade Eclipse OpenVSX and eclipse-openvsx/openvsx to 1.2.0.

Affected software

ProductAffectedFixed in
Eclipse FoundationEclipse OpenVSXAffected
  • >=0.20.0 <1.2.0
Fixed in
  • 1.2.0
GitHubeclipse-openvsx/openvsxpkg:github/eclipse-openvsx/openvsxOther threatsAffected
  • >=0.20.0 <1.2.0
Fixed in
  • 1.2.0

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

If you cannot patch yet, administrators should monitor disk usage on the temporary filesystem and consider implementing manual limits or cleanup procedures. Restricting publishing permissions and controlling access to namespaces may reduce risk. Since extraction requests require no authentication, additional network-level controls could help mitigate exploitation.

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.

References

Community reviews

Loading reviews…