The vulnerability originates from Eclipse OpenVSX’s handling of VSIX files. The server accepts a VSIX of up to 512 MB in its compressed form, but it imposes no limit on the size of the file once it is extracted. When the server first receives a request for a VSIX path, it opens the archive, streams the contents to a temporary file, and writes the decompressed data without tracking the number of bytes written. The temporary cache is evicted only by entry count, not by size, so an attacker can repeatedly upload highly compressible VSIX packages to cause the server to create very large temporary files. This depletes the disk containing the temporary directory, resulting in 500 responses with “No space left on device”, failed extraction errors, and publication failures for the attacker’s own extensions. The effect is a denial of service that undermines availability, without leaking confidential data or allowing arbitrary code execution.

Eclipse Foundation Eclipse OpenVSX (all versions). The issue is present in any deployment of the open-source runtime that has not yet incorporated the fix referenced in the advisories linked above.

The CVSS score of 4.3 indicates a moderate severity. The EPSS score of less than 1 % suggests that, although exploitation is technically straightforward, the likelihood of exploitation is low. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Attackers only need the ability to publish a new extension in their own namespace; no authentication is required to trigger the decompression. Once an attacker’s VSIX is cached, subsequent requests are served from the temporary cache, amplifying the impact. The lack of disk‑space controls exposes the server to a resource‑exhaustion denial‑of‑service attack that can be triggered by legitimate users who can upload extensions.