CVE-2026-77776
KrytyczneCVSS 9.1Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 28 - wyżej niż 28% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Atakujący może uzyskać dostęp do pamięci LLM innych użytkowników, co może prowadzić do naruszenia poufności danych lub ich manipulacji.
Rekomendacja
Zaleca się skonfigurowanie wymaganego tokena HEADROOM_PROXY_TOKEN oraz ograniczenie dostępu do proxy, a także aktualizację do wersji z poprawką.
Inne podatności w Headroom
Zobacz wszystkie- 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.
- CVE-2026-77775Wysokie
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.
Oryginalny opis (angielski, źródło NVD)
Headroom's LLM proxy derives the memory owner from the x-headroom-user-id request header. The header is read directly at several points in headroom/proxy/handlers/openai.py, including the chat completion and websocket paths, and nothing binds the value to the caller. A client can therefore name another user's identifier and read or write that user's stored LLM memory. The fix introduces a single resolve_memory_identity seam in headroom/proxy/identity.py that honors the header only for loopback or allowlisted callers and otherwise binds the identity to the proxy-token fingerprint or the operating system user. 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