CVE-2026-89321: VSIX Extension DOS Vulnerability

CVE-2026-89321 Overview

CVE-2026-89321 affects Eclipse Open VSX, an open-source registry for VS Code extensions. The vulnerability allows an authenticated publisher to exhaust temporary disk space on the server by uploading a small, highly compressible VSIX archive. When any client requests a file from that extension, the server decompresses the entry without enforcing a size cap and writes the expanded content to java.io.tmpdir. The issue is categorized under [CWE-409] Improper Handling of Highly Compressed Data (Data Amplification).

Critical Impact
A publisher with access only to their own namespace can fill the server's temp filesystem, causing cached-miss requests to fail with 500 No space left on device and blocking new extension publishing.

Affected Products

Eclipse Open VSX Registry (openvsx)
Deployments relying on WebResourceService for extension file extraction
Instances using default ovsx.publishing.max-content-size (512 MB) with an unbounded temp cache

Discovery Timeline

2026-09-14 - CVE-2026-89321 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-89321

Vulnerability Analysis

Open VSX enforces a 512 MB limit on the compressed size of a published VSIX through the ovsx.publishing.max-content-size setting. However, no equivalent bound applies to the decompressed size of individual entries inside the archive. On the first request to /vscode/unpkg/{namespace}/{extension}/{version}/{path}, WebResourceService opens the target entry with ZipFile.getInputStream() and hands the decompressed stream directly to Files.copy(). The copy runs to completion without tracking bytes written.

The extracted file is cached under java.io.tmpdir. The cache evicts by entry count (150 entries) rather than by size, so total disk usage is unbounded. An attacker can publish a small VSIX containing highly compressible content and trigger extraction with a single unauthenticated HTTP request.

Root Cause

The root cause is missing enforcement of an expanded-size limit during ZIP entry extraction. Neither ZipFile.getInputStream() nor the subsequent Files.copy() counts bytes, and the caching layer measures capacity in entries rather than bytes. This is a classic zip amplification pattern, tracked as [CWE-409].

Attack Vector

A publisher uploads a crafted VSIX where one or more entries expand to a very large size on decompression. The publisher, or any unauthenticated client, then issues a GET request to the /vscode/unpkg/... endpoint that targets the amplified entry. The server writes the fully expanded stream to temp storage. Repeating the request with different filenames or versions accumulates cache files until the temp filesystem is full. Once exhausted, cache misses return 500 No space left on device, publishing fails with Failed to read extension file, and partial cache files block retries at the same path. Metadata endpoints and previously cached files continue to serve, and the JVM process itself does not crash.

Refer to the GitHub Security Advisory GHSA-h685-gqw7-fqw7 and the corresponding GitHub Pull Request #2060 for the technical fix.

Detection Methods for CVE-2026-89321

Indicators of Compromise

HTTP 500 responses from /vscode/unpkg/... containing No space left on device
Publishing errors reporting Failed to read extension file on the Open VSX server
Unusually large files appearing under java.io.tmpdir associated with the Open VSX process
Newly published VSIX artifacts with a very high decompressed-to-compressed ratio

Detection Strategies

Monitor free space on the volume backing java.io.tmpdir and alert on rapid consumption tied to the Open VSX process.
Inspect newly uploaded VSIX archives and compute per-entry compression ratios; flag entries exceeding a reasonable threshold (for example, 100:1).
Correlate spikes in /vscode/unpkg/... request volume from a single publisher or namespace with temp filesystem growth.

Monitoring Recommendations

Enable disk-usage and inode metrics for the temp filesystem in application performance monitoring.
Log the size of files written by WebResourceService and aggregate by namespace and extension version.
Review web server access logs for repeated first-hit requests to distinct {path} values within a short window.

How to Mitigate CVE-2026-89321

Immediate Actions Required

Upgrade Open VSX to the release containing the fix from GitHub Pull Request #2060.
Restrict publishing privileges to trusted namespaces and review recent uploads for high-ratio compressed entries.
Provision java.io.tmpdir on a dedicated volume with quotas so a full temp filesystem does not affect other services.

Patch Information

The fix is delivered in the merged pull request eclipse-openvsx/openvsx#2060. It bounds the number of bytes written during entry extraction and aborts when the configured limit is exceeded. Details are published in the GitHub Security Advisory GHSA-h685-gqw7-fqw7.

Workarounds

Place a reverse proxy in front of Open VSX that rejects requests to /vscode/unpkg/... beyond a per-namespace rate.
Configure operating-system disk quotas or a tmpfs size cap on the mount backing java.io.tmpdir.
Add pre-publish validation that inspects VSIX entries and rejects archives whose expanded size exceeds a defined threshold.
Schedule periodic cleanup of stale files under the Open VSX temp cache directory to reduce dwell time of partial extractions.

bash

# Configuration example: cap tmpfs size backing java.io.tmpdir on Linux
sudo mount -o remount,size=2G /tmp

# Example systemd override to constrain the Open VSX service temp directory
# /etc/systemd/system/openvsx.service.d/override.conf
[Service]
PrivateTmp=true
Environment="JAVA_TOOL_OPTIONS=-Djava.io.tmpdir=/var/lib/openvsx/tmp"