LiteLLM CVE-2026-84377: CVSS 6.5, ale proxy wysyła klucze providerów pod adres atakującego

CVE-2026-84377 w LiteLLM ma CVSS 6.5 (Medium) i wymaga konta na proxy. Łatwo go odłożyć. Tymczasem skutkiem jest to, że proxy wysyła skonfigurowane klucze do providerów LLM pod adres wskazany przez atakującego. Bramka LLM zwykle trzyma klucze do wszystkich dostawców, z których korzysta organizacja, więc wartość tego wycieku jest wysoka.

CVE-2026-84377 (LiteLLM, CVSS 6.5, PR:L): uwierzytelniony użytkownik proxy przekierowuje wywołanie do providera na własny adres → proxy wysyła tam credentiale dostawcy.

Poprawki w dziewięciu liniach: 1.88.6, 1.89.7, 1.90.7, 1.91.5, 1.92.2, 1.93.2, 1.94.3, 1.95.1, 1.96.2+.

Attack path

authenticated proxy user -> request body z zagnieżdżonym parametrem routingu -> denylist nie obejmuje parametrów zagnieżdżonych -> outbound provider call kierowany na adres atakującego -> proxy dołącza skonfigurowane credentiale providera

Denylist to słaba kontrola

Walidacja oparta na liście zakazanych parametrów przegrywa z każdą drogą, której autor nie przewidział — tutaj z zagnieżdżeniem. Allowlist (tylko znane, dozwolone parametry routingu) zamyka całą klasę. To ten sam problem co przy innych SSRF w narzędziach AI: kontrola pilnuje jednej reprezentacji danych, a atakujący używa innej.

Severity ≠ blast radius

Wektor PR:L obniża wynik, ale w praktyce „uwierzytelniony użytkownik proxy” to często każdy developer, każda aplikacja z kluczem wirtualnym albo tenant w środowisku współdzielonym. Priorytet zależy od tego, kto ma dostęp do proxy, jakie klucze upstream są w konfiguracji i czy proxy może łączyć się z dowolnym adresem w internecie lub w sieci wewnętrznej. Podobnie jak przy Budibase — średni wynik, ale wyciek aktywnych sekretów.

Co powinien zrobić VE

Ustal linię wersji i zaktualizuj do właściwej poprawki z tej linii (nie kopiuj jednej „fixed version” między liniami). Jeśli aktualizacja nie jest od razu możliwa, zablokuj na API gateway lub reverse proxy możliwość nadpisywania parametrów połączenia i ogranicz klucze proxy do zaufanych użytkowników. Ogranicz też ruch wychodzący proxy do znanych endpointów providerów. Przejrzyj logi wywołań pod kątem nietypowych adresów docelowych. Jeśli proxy było dostępne dla wielu użytkowników przed poprawką — rotuj klucze providerów, bo patch nie unieważnia już wysłanych credentiali.

Powiązane na blogu

Budibase: CVSS 5.4, wyciek tokenów — SSRF z wyciekiem credentiali
MCP Atlassian — walidacja URL a faktyczny cel żądania

Źródła

GitLab Advisory Database — CVE-2026-84377 (LiteLLM) — advisories.gitlab.com
Red Hat Product Security — CVE-2026-84377 — access.redhat.com
GHSA-3cv6-jpf6-8222 — github.com

Nota redakcyjna: stan informacji 6 października 2026, na podstawie draftu VMRT i publicznych advisory (GitLab Advisory DB, GHSA, Red Hat). CVE-2026-84377 (LiteLLM, CVSS 6.5); poprawki w dziewięciu liniach wersji. Artykuł nie potwierdza aktywnej eksploatacji.