External risk intelligence

Open VSX Cache Poisoning Allows Malicious Extension Installation.

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2025-12999

The vulnerability affects a public-facing service (Open VSX) designed to be accessed by external clients (VS Code editors). It is commonly deployed as an internet-facing service to provide extensions, and while it can be protected by specific proxy configurations, its default function as a registry and download service makes it a typical internet-facing web application.

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This vulnerability involves how certain software handles specific request headers, potentially allowing an attacker to redirect users to malicious download locations. The issue arises when the system doesn't properly validate these headers, leading to the caching of incorrect URLs that are then served to all users. This could result in users unknowingly downloading and installing malicious software disguised as legitimate updates.

Attackers can redirect downloads to malicious sites.
Exposure of users to compromised software is possible.
Confirming relevance and exposure is the main concern.

Attack Path

How an attacker could exploit the issue

An attacker can poison the Open VSX cache by sending a crafted `X-Forwarded-Host` header. This causes the server to generate absolute URLs for download links, icons, and other assets using the attacker's chosen host. These poisoned entries are then served to all other clients for a default of one hour, potentially leading to the installation of malicious extensions.

Unauthenticated remote attacker.
Craft `X-Forwarded-Host` header.
Install malicious VSIX packages.

Live Threat

Current exploitation, exposure, and threat context

When supported by the advisory, an unauthenticated remote attacker could poison the extension metadata cache by supplying a crafted host header. This could lead to other clients fetching and installing malicious extensions, including their download URLs, signatures, and public keys.

Malicious extensions could be installed.
Cache poisoning via forged headers.
Users may fetch fake extensions.

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability impacts the Open VSX registry, which is typically managed by platform or infrastructure teams responsible for its availability and security. The first practical step is to determine if your deployment is exposed to external, unauthenticated requests that could exploit the header manipulation, identify the specific instances of Open VSX in use, and confirm their business criticality before planning remediation.

Platform or Infrastructure teams own remediation.
Verify proxy configuration and external reachability.
Plan remediation during a maintenance window.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Open VSX and how is it used?

Open VSX is an open-source registry that serves as a central repository for extensions compatible with VS Code and other editors. It functions as a platform where developers publish extensions, and clients fetch these tools, icons, and metadata to enhance their coding environment. It acts as the backbone for distributing software add-ons to a broad community of users.

What does CWE-345 mean in the context of CVE-2025-12999?

CWE-345 represents 'Insufficient Verification of Data Authenticity.' In this advisory, it refers to the server's failure to verify if the headers influencing URL generation—like X-Forwarded-Host—actually come from a trusted proxy. Because the system trusts these unvalidated headers, it inadvertently produces links pointing to attacker-controlled locations, undermining the integrity of the data it provides to all connected clients.

How does an attacker trigger this cache poisoning?

An attacker triggers this by sending a request to the server with a forged X-Forwarded-Host header. If the server is configured to relay this header rather than overwrite it, it creates absolute URLs for downloads and signatures based on that malicious input. Notably, this does not occur if the deployment uses a properly configured reverse proxy that forces the correct host values or if the server is unreachable from the public internet.

Is my deployment at risk according to Halo Surface Signal?

Halo Surface Signal notes that because Open VSX is designed to provide services to external clients, it is commonly found in internet-facing configurations. Deployments that are directly reachable by clients or sit behind proxies that relay rather than replace incoming headers are highly relevant. If your instance is intended for broad public access, it should be treated as a priority for review.

What steps should I take if I run Open VSX?

First, evaluate your reverse proxy settings to ensure it explicitly sets the X-Forwarded headers instead of relaying those sent by the client. Verify that your server is not reachable except through this hardened proxy. Finally, you must flush your application caches, such as Redis, to clear any existing poisoned metadata entries, as these will persist even after you correct your configuration.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.