# CVE-2026-89321: Open VSX decompression bomb in VSIX file extraction

Source: https://junglewise.ai/threats/cve-2026-89321-open-vsx-decompression-bomb-in-vsix-file-extraction  
Publisher: Junglewise Threat Intelligence, https://junglewise.ai/threats  
Published: 2026-09-14. Updated: 2026-09-26  
License: CC BY 4.0 with a link back

CVE-2026-89321 · Severity: medium · CVSS 4.3 · Published 2026-09-14

Open VSX is an open-source marketplace for distributing Visual Studio Code extensions. The service failed to limit the size of files when extracting compressed VSIX packages, allowing a malicious publisher to upload a small highly-compressed file that expands to fill the server's temporary storage. When the temp filesystem fills, requests for uncached files fail and publishing becomes impossible, effectively causing a denial of service for all users.

## Quick answers

**Is CVE-2026-89321 exploited in the wild?** No. Junglewise Threat Intelligence has no report of CVE-2026-89321 being exploited in the wild.

**How severe is CVE-2026-89321?** Medium severity, with a CVSS score of 4.3, published 14 September 2026.

**Which products and versions are affected?** Eclipse OpenVSX Open VSX 0.20.0 to 1.1.x (before 1.2.0).

**Is there a fix for CVE-2026-89321?** A patch was published on 2026-08-24: Fix merged in PR #2060; version 1.2.0 released Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.

**How is CVE-2026-89321 attacked?** It is attacked over the network, in a hosted service.

**Am I affected by CVE-2026-89321?** Check whether anything you run is named in the advisory. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

## Technical details

The vulnerability is a decompression bomb / zip bomb issue (CWE-409, CWE-400). The root cause: WebResourceService.getWebResource() extracts entries from VSIX packages using ZipFile.getInputStream() without bounding decompressed size; the extracted files are cached to java.io.tmpdir using Files.copy() which reads to stream end without size checks. While upload is size-limited (compressed VSIX max 512 MB), extraction is not. The web resource cache evicts by entry count (default 150) not total size, placing no disk usage bound. Attack requires only published namespace access; triggering extraction needs no authentication. An attacker can upload different highly-compressible files or versions to repeatedly fill the temp filesystem, causing 500 errors and publishing failures. The fix (merged Aug 2026) adds opt-in per-file decompression limits, switches cache to weight-based eviction by actual file size, deletes partial files on extraction failure, and bounds copy operations via SizeLimitInputStream.

## Affected products

- Eclipse OpenVSX Open VSX 0.20.0 to 1.1.x (before 1.2.0)

## Timeline

- 2026-09-14: disclosed: CVE-2026-89321 published
- 2026-09-20: advisory: GHSA-h685-gqw7-fqw7 security advisory published
- 2026-08-24: patched: Fix merged in PR #2060; version 1.2.0 released

## References

- [https://github.com/eclipse-openvsx/openvsx/pull/2060](https://github.com/eclipse-openvsx/openvsx/pull/2060)
- [https://github.com/eclipse-openvsx/openvsx/security/advisories/GHSA-h685-gqw7-fqw7](https://github.com/eclipse-openvsx/openvsx/security/advisories/GHSA-h685-gqw7-fqw7)