CVE-2025-12999 Overview
CVE-2025-12999 is a cache poisoning vulnerability in Eclipse Open VSX Registry. The flaw resides in UrlUtil.getBaseUrl, which constructs absolute URLs from client-supplied X-Forwarded-Host, X-Forwarded-Proto, and X-Forwarded-Prefix headers without verifying a trusted proxy sent them. Responses containing these URLs are cached under keys that omit the host, so a single crafted request replaces download, signature, and public-key URLs for every subsequent client. Extension signing does not mitigate the attack because the attacker controls all three URLs used for verification. Downstream VS Code-compatible editors then fetch and install attacker-controlled VSIX packages [CWE-345].
Critical Impact
An unauthenticated remote attacker can poison Open VSX metadata caches, causing VS Code-compatible editors to download and install malicious extensions with attacker-supplied signatures and verification keys.
Affected Products
- Eclipse Open VSX extension.json cache (since 0.6.0)
- Eclipse Open VSX namespace.details.json cache (since 0.9.0)
- Eclipse Open VSX sitemap cache (since 0.14.5) and latest.extension.version.vscode cache (since 0.34.2)
Discovery Timeline
- 2026-09-21 - CVE-2025-12999 published to NVD
- 2026-09-22 - Last updated in NVD database
Technical Details for CVE-2025-12999
Vulnerability Analysis
Open VSX uses UrlUtil.getBaseUrl to build absolute URLs returned in API responses, including extension download links, icon URLs, and asset endpoints. The helper trusts X-Forwarded-Host, X-Forwarded-Proto, and X-Forwarded-Prefix from any client and falls back to the Host header. The response objects containing these URLs are then written to caches such as extension.json, namespace.details.json, sitemap, and latest.extension.version.vscode. Cache keys do not include the host, so any client that later requests the resource receives the attacker's URLs. Entries live for one hour by default, and the poisoning propagates cluster-wide when ovsx.redis.enabled is set. Because the VSIX URL, signature URL, and public key URL all derive from the same base, extension signing provides no protection.
Root Cause
The root cause is improper trust of client-controlled forwarding headers combined with host-agnostic cache keying. UrlUtil.getBaseUrl performs no validation that the request arrived from a designated reverse proxy before consuming X-Forwarded-* values [CWE-345].
Attack Vector
An unauthenticated remote attacker sends a single HTTP request with a forged X-Forwarded-Host header pointing at an attacker-controlled origin. The response, containing the attacker's absolute URLs, is stored in the shared cache. Every subsequent editor requesting that extension metadata receives the poisoned URLs and installs the malicious VSIX along with its matching signature and verification key. Exploitability depends on topology: servers reachable directly or fronted by a proxy that relays X-Forwarded-Host are vulnerable; proxies that overwrite the header block the attack.
See the GitHub Security Advisory GHSA-f55q-5m46-rmxc and Open VSX pull request #2196 for technical details.
Detection Methods for CVE-2025-12999
Indicators of Compromise
- Cached Open VSX responses whose downloadUrl, signatureUrl, or publicKeyUrl fields reference hostnames outside your registry's canonical domain.
- Access logs showing inbound requests containing X-Forwarded-Host, X-Forwarded-Proto, or X-Forwarded-Prefix headers from sources other than your trusted reverse proxy.
- Editor telemetry showing VSIX downloads or signature retrievals directed to unexpected external domains.
Detection Strategies
- Inspect Redis or in-memory cache entries for extension.json, namespace.details.json, sitemap, and latest.extension.version.vscode keys and validate every embedded URL matches the registry's expected base.
- Compare Host and X-Forwarded-Host header values at the proxy edge and alert on mismatches or client-supplied forwarding headers.
- Monitor outbound network activity from developer endpoints for VSIX or signature downloads to unapproved hosts.
Monitoring Recommendations
- Enable request logging at the reverse proxy layer to capture all X-Forwarded-* headers received from clients.
- Instrument the Open VSX application to log the base URL selected by UrlUtil.getBaseUrl for each cached response.
- Alert when cached metadata is written with a base URL that differs from the configured canonical hostname.
How to Mitigate CVE-2025-12999
Immediate Actions Required
- Upgrade Open VSX to the patched release that validates forwarding headers against trusted proxies.
- Reconfigure the fronting reverse proxy to overwrite, not relay, X-Forwarded-Host, X-Forwarded-Proto, and X-Forwarded-Prefix.
- Flush all Open VSX caches, including Redis when ovsx.redis.enabled is true, because poisoned entries persist across configuration changes.
- Restrict network access so the Open VSX server is reachable only through the trusted proxy.
Patch Information
The fix is delivered in Open VSX pull request #2196. Refer to the GitHub Security Advisory GHSA-f55q-5m46-rmxc and the Eclipse GitLab CVE assignment for release details.
Workarounds
- Configure the reverse proxy to set, rather than relay, X-Forwarded-Host, X-Forwarded-Proto, and X-Forwarded-Prefix; note that nginx's $host variable reflects the client Host header and is not a safe value.
- Ensure the Open VSX server is unreachable except through the trusted proxy.
- Flush all caches after applying configuration changes to evict any previously poisoned entries.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
