CVE-2026-77775
WysokieCVSS 8.6Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 47 - wyżej niż 47% wszystkich znanych CVE
Streszczenie
Proxy LLM Headroom pozwala klientowi wybrać docelowy serwer za pomocą nagłówka x-headroom-base-url. Brakuje sprawdzenia, czy cel nie jest adresem pętli zwrotnej, link-local lub RFC 1918, co umożliwia dostęp do wewnętrznych usług i adresów metadanych chmury. Dodatkowo, nagłówek Authorization jest przekazywany do wskazanego hosta. Domyślna konfiguracja docker-compose.yml wystawia porty bez wymaganego tokena, co zwiększa ryzyko.
Ocena ryzyka
Atakujący może uzyskać dostęp do wewnętrznych usług i metadanych chmury, a także przechwycić nagłówki autoryzacyjne, co może prowadzić do wycieku danych i eskalacji uprawnień.
Rekomendacja
Zaktualizuj Headroom do wersji z poprawką, skonfiguruj wymagany token i nie wystawiaj portów na sieć bez autoryzacji.
Inne podatności w Headroom
Zobacz wszystkie- CVE-2026-77776Krytyczne
Proxy LLM Headroom wywodzi właściciela pamięci z nagłówka żądania x-headroom-user-id. Nagłówek jest odczytywany bezpośrednio w kilku miejscach, a nic nie wiąże wartości z wywołującym. Klient może podać identyfikator innego użytkownika i odczytać lub zapisać jego pamięć LLM. Poprawka wprowadza pojedynczy punkt resolve_memory_identity, który honoruje nagłówek tylko dla wywołań z loopback lub z listy dozwolonych, a w przeciwnym razie wiąże tożsamość z odciskiem tokena proxy lub użytkownikiem systemu operacyjnego. Domyślna konfiguracja pip wiąże 127.0.0.1, ale referencyjny docker-compose.yml udostępnia porty bez wymaganego tokena, co naraża trasy danych na sieć bez uwierzytelnienia.
- CVE-2026-71416Wysokie
W wersjach Headroom przed 0.35.0 serwer WebSocket nie weryfikuje nagłówka `Origin` przychodzących żądań przed przekazaniem ich do serwera nadrzędnego, co pozwala złośliwym klientom WebSocket na wykonywanie dowolnych żądań do LLM bez uwierzytelnienia. Podatność może zostać wykorzystana przez złośliwego klienta WebSocket działającego w przeglądarce, jeśli ma ona dostęp do proxy Headroom, a klucz OpenAI API jest przechowywany w zmiennej środowiskowej `OPENAI_API_KEY`. Wersja 0.35.0 naprawia ten problem.
Oryginalny opis (angielski, źródło NVD)
Headroom's LLM proxy lets a client choose the upstream destination with the x-headroom-base-url request header. _resolve_openai_upstream_base in headroom/proxy/handlers/openai.py accepts the header value, requires only that it parse with an http or https scheme and a hostname, and returns it for use as the upstream base; _select_passthrough_base_url in headroom/providers/proxy_routes.py reads the same header for the passthrough routes. No check rejects loopback, link-local, or RFC 1918 destinations, and because the component is a proxy the upstream response is returned to the caller, so the request reaches internal services and cloud metadata addresses and their responses are disclosed. The Authorization header accompanying the request is forwarded unchanged to the caller-designated host. The pip console script binds 127.0.0.1 by default, but the reference docker-compose.yml ships --host 0.0.0.0 with published ports and no required HEADROOM_PROXY_TOKEN, which the server itself warns about at startup, so a deployment following the shipped compose exposes the affected data-plane routes to the network without authentication.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS