Krytyczny łańcuch podatności w LiteLLM pozwala przejąć serwery bramy AI

Wprowadzenie do problemu / definicja

LiteLLM to popularna brama AI typu open source, która pośredniczy w komunikacji pomiędzy aplikacjami a wieloma dostawcami modeli językowych przez interfejs zgodny z OpenAI. Tego rodzaju komponent często staje się centralnym punktem dostępu do usług AI, przechowując klucze API, konfiguracje integracji oraz dane przesyłane w promptach i odpowiedziach modeli.

Ujawniony w czerwcu 2026 roku łańcuch podatności pokazuje, że kompromitacja takiej warstwy pośredniej może mieć znacznie poważniejsze skutki niż sam wyciek danych. W najgorszym scenariuszu atakujący może przejść od konta o niskich uprawnieniach do pełnego przejęcia hosta obsługującego bramę AI.

W skrócie

• Badacze opisali trzyetapowy łańcuch ataku obejmujący obejście autoryzacji, eskalację uprawnień i wykonanie kodu na serwerze.
• Atak może rozpocząć użytkownik o niskim poziomie dostępu, a zakończyć się przejęciem uprawnień administratora proxy.
• Skutkiem może być kradzież kluczy API, poświadczeń bazodanowych, materiału kryptograficznego oraz treści promptów i odpowiedzi.
• Pełen zestaw poprawek uwzględniono w wersji LiteLLM v1.83.14-stable i nowszych.

Kontekst / historia

LiteLLM zyskał popularność jako uniwersalna warstwa integracyjna dla środowisk developerskich i produkcyjnych korzystających z wielu modeli AI. Ułatwia zarządzanie ruchem do różnych dostawców, ale jednocześnie konsoliduje w jednym miejscu sekrety, konfiguracje oraz dane operacyjne.

To sprawia, że bramy AI stają się atrakcyjnym celem dla napastników. Przejęcie takiego systemu oznacza nie tylko dostęp do infrastruktury integracyjnej, lecz także możliwość wpływu na dane wejściowe i wyjściowe modeli, a w konsekwencji na działanie agentów, automatyzacji i aplikacji zależnych od odpowiedzi generowanych przez AI.

Analiza techniczna

Łańcuch podatności składa się z trzech kluczowych elementów. Pierwszy z nich, oznaczony jako CVE-2026-47101, dotyczy obejścia autoryzacji. Zgodnie z opisem badaczy zwykły użytkownik może utworzyć wirtualny klucz API i przekazać pole allowed_routes bez właściwej walidacji względem posiadanej roli. Mechanizm ograniczający dostęp staje się w tym scenariuszu źródłem dodatkowych uprawnień.

W efekcie użytkownik o niskich uprawnieniach może wygenerować klucz obejmujący wszystkie ścieżki, w tym endpointy administracyjne. To otwiera drogę do drugiego etapu, czyli CVE-2026-47102. Podatność ta umożliwia eskalację uprawnień poprzez modyfikację własnego rekordu użytkownika bez odpowiedniego ograniczenia pól możliwych do zapisu. Jeśli aplikacja akceptuje zmianę pola roli, napastnik może samodzielnie uzyskać poziom proxy_admin.

Trzecim ogniwem jest CVE-2026-40217 związany z mechanizmem Custom Code Guardrail. Funkcja ta pozwala administratorowi dostarczać własny kod Python wykonywany przez system. Według opisu badaczy kod był uruchamiany z użyciem exec() bez skutecznej filtracji, co umożliwiało odzyskanie dostępu do funkcji wbudowanych, importowanie modułów systemowych i wykonywanie poleceń na serwerze.

Połączenie tych trzech błędów tworzy kompletny łańcuch przejścia od niskich uprawnień do zdalnego wykonania kodu. To szczególnie groźne w przypadku bramy AI, ponieważ po przejęciu napastnik może nie tylko odczytywać sekrety i dane, ale również modyfikować odpowiedzi modeli w locie oraz wpływać na zachowanie systemów zależnych od AI.

Konsekwencje / ryzyko

Najbardziej bezpośrednim skutkiem udanego ataku jest ujawnienie sekretów przechowywanych lub obsługiwanych przez LiteLLM. Mogą to być klucze dostawców modeli, poświadczenia do baz danych, tokeny integracyjne oraz dane wykorzystywane do odszyfrowywania konfiguracji.

Drugim istotnym ryzykiem jest dostęp do treści przetwarzanych przez modele. Prompty i odpowiedzi nierzadko zawierają kod źródłowy, dane wewnętrzne, informacje osobowe, zgłoszenia operacyjne czy inne poufne treści. Przejęta brama AI może więc działać jak punkt przechwytu całego ruchu pomiędzy użytkownikami a modelami.

Nie mniej groźna jest utrata integralności. Atakujący kontrolujący bramę może manipulować odpowiedziami modelu, wstrzykiwać spreparowane instrukcje dla agentów AI, modyfikować kontekst decyzji lub wykorzystywać callbacki i rozszerzenia do utrzymania trwałej obecności. W środowiskach połączonych z narzędziami administracyjnymi, CI/CD czy systemami zgłoszeń może to prowadzić do dalszych kompromitacji.

Rekomendacje

Najważniejszym krokiem jest natychmiastowa aktualizacja do LiteLLM v1.83.14-stable lub nowszej wersji zawierającej komplet poprawek. Organizacje nie powinny jednak ograniczać się wyłącznie do wdrożenia łat.

• Przeprowadzić audyt wszystkich kont posiadających rolę proxy_admin.
• Zweryfikować konfiguracje Custom Code Guardrail, callbacków oraz innych rozszerzeń uruchamianych po stronie serwera.
• W razie podejrzenia kompromitacji wymusić rotację kluczy API, poświadczeń bazodanowych, tokenów integracyjnych i innych sekretów.
• Sprawdzić integralność kontenerów, artefaktów aplikacyjnych i konfiguracji wdrożeniowej.
• Ograniczyć uprawnienia procesu LiteLLM, wdrożyć segmentację sieci i monitorować wywołania endpointów administracyjnych.
• Włączyć centralne logowanie zdarzeń bezpieczeństwa oraz detekcję anomalii w ruchu do modeli i narzędzi wywoływanych przez agentów.

Podsumowanie

Incydent związany z LiteLLM pokazuje, że infrastruktura AI musi być traktowana jak krytyczny element bezpieczeństwa organizacji. Połączenie błędów autoryzacji, eskalacji uprawnień i możliwości wykonania kodu tworzy scenariusz, w którym zwykły użytkownik może przejąć centralny punkt obsługi ruchu do modeli AI.

Dla firm korzystających z bram AI oznacza to konieczność szybkiego patchowania, regularnych przeglądów uprawnień, monitorowania działań administracyjnych oraz architektonicznego ograniczania zaufania do komponentów pośredniczących. W przeciwnym razie pojedyncza luka w warstwie integracyjnej może przełożyć się na szeroki incydent obejmujący dane, sekrety i integralność procesów biznesowych.

Źródła

1. LiteLLM Vulnerability Chain Lets Low-Privilege Users Take Over AI Gateway Servers — https://thehackernews.com/2026/06/litellm-vulnerability-chain-lets-low.html
2. CVE-2026-47101 — https://nvd.nist.gov/vuln/detail/CVE-2026-47101
3. CVE-2026-47102 — https://nvd.nist.gov/vuln/detail/CVE-2026-47102
4. CVE-2026-40217 — https://nvd.nist.gov/vuln/detail/CVE-2026-40217
5. LiteLLM Releases / v1.83.14-stable — https://github.com/BerriAI/litellm/releases/tag/v1.83.14-stable