EUVD-2026-77328
GHSA-ggqm-q66x-mqh3
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
Temp filesystem exhaustion is persistent and requires operator intervention, warranting A:H over A:L; PR:L reflects required publisher access for upload.
Primary rating from Vendor (eclipse).
CVSS VectorVendor: eclipse
Lifecycle Timeline
5DescriptionCVE.org
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.
AnalysisAI
Disk exhaustion via zip bomb in Eclipse OpenVSX allows a publisher to cause persistent service disruption on any OpenVSX server instance. A publisher uploads a small, highly compressed VSIX (zip bomb) that the server decompresses without size limits when any client requests a file via /vscode/unpkg/; the decompressed content is cached to java.io.tmpdir under an entry-count eviction policy with no total-size bound, enabling repeated disk exhaustion through new filenames or versions. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires two distinct capabilities: first, an authenticated publisher account with write access to at least one namespace (PR:L) to upload the malicious VSIX via the normal publishing flow; second, the ability to issue unauthenticated GET requests to /vscode/unpkg/ endpoints (the extraction is not gated by auth). … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The official CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L, 4.3) accurately captures the attack vector and privilege prerequisite but understates availability impact. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | Apply the upstream fix from GitHub pull request #2060 (https://github.com/eclipse-openvsx/openvsx/pull/2060); note that a tagged release version containing this fix is not independently confirmed from the available data - verify the current release status against the OpenVSX release history. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today