Eclipse Open VSX versions >=0.6.0 <=1.1.2 have a vulnerability where UrlUtil.getBaseUrl constructs absolute URLs from X-Forwarded-Host, X-Forwarded-Proto, and X-Forwarded-Prefix headers without verifying the sender's trustworthiness, falling back to the client-supplied Host header. These URLs are cached under keys that do not include the host, allowing an attacker to poison the cache with attacker-controlled URLs for up to one hour cluster-wide if Redis caching is enabled. This enables an unauthenticated remote attacker to supply malicious VSIX download, signature, and public key URLs, causing clients to fetch and install malicious extensions. Exploitability depends on whether the server is directly reachable or if a proxy overwrites these headers. Workarounds include configuring proxies to set rather than relay these headers, restricting server access, and flushing caches.

An unauthenticated remote attacker can poison the per-extension metadata cache with malicious URLs by supplying crafted X-Forwarded headers, causing VS Code-compatible editors to download and install malicious VSIX extensions. This undermines the extension signing mechanism because the attacker controls the package, signature, and verification key URLs. The impact is high as it can lead to remote code execution or compromise of client systems using affected Open VSX servers.

No official patch or fix is currently confirmed. Workarounds for unpatched versions include: (1) configuring the reverse proxy to set (not relay) the X-Forwarded-Host, X-Forwarded-Proto, and X-Forwarded-Prefix headers with safe values, ensuring these headers are not client-controllable; (2) restricting direct access to the Open VSX server so it is only reachable through a trusted proxy; (3) flushing the extension metadata caches after making configuration changes to remove any poisoned entries. Patch status is not yet confirmed — check the vendor advisory for current remediation guidance.