CVE-2026-89321: Eclipse OpenVSX · data amplification
Affects Eclipse OpenVSXSource CVE Database V5
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
- 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:LExploitation evidence
Disclosed: evidence found.
CVE published 14 Sep 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by 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
| Product | Affected | Fixed in |
|---|---|---|
| Eclipse FoundationEclipse OpenVSX | Affected
| Fixed in
|
GitHubeclipse-openvsx/openvsxpkg:github/eclipse-openvsx/openvsxOther threats | Affected
| Fixed in
|
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.