Krytyczny Odebrany

CVE-2025-12999

opublikowano: 21.09.2026, 11:17

modyfikacja: 21.09.2026, 20:11

Ocena CVSS

9.1

Krytyczny · v4.0

Oficjalne źródła

wektor: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:L/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

UrlUtil.getBaseUrl tworzy w odpowiedzi bezwzględne adresy URL — linki do pobierania, ikony, adresy URL zasobów i interfejsów API — z nagłówków żądań X-Forwarded-Host, X-Forwarded-Proto i X-Forwarded-Prefix, bez sprawdzania, czy nadawca był zaufanym serwerem proxy, wracając do nagłówka hosta dostarczonego przez klienta.

Odpowiedzi te są buforowane pod kluczami, które nie obejmują hosta (extension.json od 0.6.0, namespace.details.json od 0.9.0, sitemap od 0.14.5, najnowsze.extension.version.vscode od 0.34.2). Dlatego pojedyncze żądanie zawierające sfałszowany nagłówek umieszcza wybrane przez atakującego adresy URL we wpisie udostępnianym każdemu innemu klientowi przez cały okres istnienia tego wpisu — domyślnie przez jedną godzinę i w całym klastrze, jeśli ustawiono ovsx.redis.enabled.

Adres URL pobierania VSIX, adres URL jego podpisu i adres URL klucza publicznego pochodzą z tego samego podstawowego adresu URL, więc podpisywanie rozszerzenia nie ogranicza wpływu: osoba atakująca, która zatruwa wpis, dostarcza pakiet, podpis nad nim i klucz używany do jego weryfikacji.

Możliwość wykorzystania zależy od topologii wdrożenia. Serwer osiągalny bezpośrednio przez klientów lub obsługiwany przez serwer proxy, który przekazuje host X-Forwarded-Host klienta, zamiast go nadpisywać, może zostać wykorzystany przez nieuwierzytelnionego zdalnego atakującego. Serwer proxy, który zastępuje nagłówek, nie jest.

Nieuwierzytelniony atakujący może zatruć pamięć podręczną metadanych poszczególnych rozszerzeń Open VSX za pomocą kontrolowanych przez atakującego adresów URL pobierania, podpisu i kluczy publicznych, dostarczając spreparowany nagłówek X-Forwarded-Host, powodując pobranie i zainstalowanie złośliwego VSIX przez dalsze edytory kompatybilne z VS Code.

Obejścia (wersje bez poprawek)

1. Skonfiguruj odwrotne proxy, aby zamiast przekazywać X-Forwarded-Host, X-Forwarded-Proto i X-Forwarded-Prefix — zwróć uwagę, że $Host w nginx jest nagłówkiem hosta klienta i nie jest to bezpieczna wartość.

2. Upewnij się, że serwer jest dostępny jedynie za pośrednictwem tego serwera proxy.

3. Następnie przepłucz pamięci podręczne; zatrute wpisy przetrwają zmianę konfiguracji.

UrlUtil.getBaseUrl builds the absolute URLs in a response — download links, icons, asset and API URLs — from the X-Forwarded-Host, X-Forwarded-Proto and X-Forwarded-Prefix request headers, with no check on whether the sender was a trusted proxy, falling back to the client-supplied Host header.

Those responses are cached under keys that do not include the host (extension.json since 0.6.0, namespace.details.json since 0.9.0, sitemap since 0.14.5, latest.extension.version.vscode since 0.34.2). A single request carrying a forged header therefore places attacker-chosen URLs into an entry served to every other client for the lifetime of that entry — one hour by default, and cluster-wide where ovsx.redis.enabled is set.

The VSIX download URL, its signature URL and the public key URL are all derived from the same base URL, so extension signing does not limit the impact: an attacker who poisons an entry supplies the package, the signature over it, and the key used to verify it.

Exploitability depends on deployment topology. A server reachable directly by clients, or fronted by a proxy that relays the client's X-Forwarded-Host rather than overwriting it, is exploitable by an unauthenticated remote attacker. A proxy that overwrites the header is not.

An unauthenticated attacker can poison Open VSX's per-extension metadata cache with attacker-controlled download, signature, and public-key URLs by supplying a crafted X-Forwarded-Host header, causing downstream VS Code-compatible editors to fetch and install a malicious VSIX.

Workarounds (unpatched versions)

1. Configure the reverse proxy to set rather than relay X-Forwarded-Host, X-Forwarded-Proto and X-Forwarded-Prefix — note that nginx's $host is the client's Host header and is not a safe value.

2. Ensure the server is not reachable except through that proxy.

3. Flush the caches afterwards; poisoned entries survive the configuration change.

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve