LiteLLM podatne na przejęcie kont przez niezweryfikowane adresy e-mail w JWT

LiteLLM to otwartoźródłowy gateway AI, pozwalający ujednolicić metody dostępu do różnych dostawców modeli językowych (np. OpenAI, Anthropic, Azure, Bedrock, Vertex AI). Za pomocą jednego serwera lub SDK pozwala łączyć się z wieloma modelami. Oczywiście w tym celu narzędzie musi posiadać własny mechanizm uwierzytelnienia.

TLDR:

• Badacze z OX Security wykryli w LiteLLM podatność umożliwiającą przejęcie istniejącego konta użytkownika poprzez błędną obsługę adresów e-mail w tokenach JWT.
• LiteLLM podczas logowania JWT może użyć adresu e-mail jako mechanizmu awaryjnego dopasowania użytkownika, ale nie sprawdza wartości email_verified.
• Atakujący może wykorzystać poprawnie podpisany przez zaufany IdP token zawierający niezweryfikowany adres e-mail powiązany z istniejącym kontem LiteLLM.
• Po pierwszym udanym uwierzytelnieniu LiteLLM nadpisuje sso_user_id konta ofiary, przez co atakujący uzyskuje trwały dostęp do konta.
• Problem pozostał niezałatany pomimo zgłoszeń badaczy.

Jedną z jego form stanowią tokeny JWT, które dopasowywane są do istniejącego użytkownika na podstawie user_id lub sso_user_id. Gdy zapytanie nie zwróci żadnego wyniku (czyli nie istnieje taki użytkownik w bazie), dopasowanie wykonywane jest na podstawie adresu e-mail przekazanego z tokenem. Adres ten jednak nie musi być zweryfikowany. Taka sytuacja w praktyce zachodzi np. wtedy, gdy założone zostanie nowe konto z adresem e-mail, a użytkownik jeszcze nie zalogował się na nie przez zewnętrznego dostawcę.

LiteLLM ufa tokenom podpisanym przez IdP (identity providers – takich jak Okta, Microsoft Entra ID, czy Google Workspace), aby uwierzytelnić użytkownika. Token JWT zawiera claim e-mail oraz informację, czy adres jest zweryfikowany (czy po stronie IdP potwierdzono, że faktycznie należy do użytkownika). Wartość ta nie jest jednak brana pod uwagę. Można więc założyć konto u jednego z dostawców IdP podając cudzy adres e-mail, a następnie wygenerować prawidłowo podpisany token JWT z tym właśnie adresem – u niektórych dostawców może być to wykonalne. 

Z punktu widzenia IdP nie musi to być problemem, ponieważ token zawiera informację, że adres nie jest potwierdzony. LiteLLM ignoruje jednak tę wartość, przez co możliwe jest podszycie się pod innego użytkownika.

Co gorsza, jeśli w bazie użytkowników znalezione zostanie konto z takim adresem e-mail, jego sso_user_id jest nadpisywane wartością sub nowego tokenu (w tym przypadku należącego do atakującego) – dzięki czemu każde kolejne żądanie ze sfałszowanym tokenem jest uwierzytelnione. Nie są wymagane dane uwierzytelniające ofiarę ani żadna interakcja z jej strony – wystarczy podpisany token JWT zawierający jej adres e-mail wystawiony przez zaufanego IdP.

Badacze zademonstrowali proof of concept, w ramach którego utworzyli konto ofiary (proxy_admin) i uwierzytelnili się tokenem JWT, którego jedynym związkiem z ofiarą był claim e-mail. Żądanie zakończyło się powodzeniem już przy pierwszym wywołaniu, a kolejne zapytanie pokazało, że sso_user_id konta ofiary został powiązany z wartością sub tokenu atakującego – podatność pozwala więc uzyskać stały dostęp do cudzego konta.

Na moment publikacji badaczy (29 września 2026) problem nie został jeszcze naprawiony. Zgłosili go 18 maja 2026, jednak mimo ponowienia 27 lipca, podatność ma nadal występować w wersji 1.100.1.

Aktualizacja do najnowszej wersji nie rozwiąże więc problemu (przynajmniej do momentu, gdy zostanie wydana łatka). Badacze sugerują opcje zabezpieczenia instancji LiteLLM:

• Blokada żądań z tokenami bez zweryfikowanego adresu (pole email_verified) na poziomie reverse proxy.
• Niepozostawianie “wstępnie” utworzonych kont – aby zminimalizować możliwości ataku, najbezpieczniej tworzyć konta w momencie, gdy nowy użytkownik może od razu się zalogować – aby nie pozostawały aktywne w bazie czekając na pierwsze logowanie.

Powyższe są oczywiście bardziej metodami defense-in-depth niż docelowym sposobem zabezpieczenia. Oczywiście warto również (jak w przypadku każdego samodzielnie hostowanego oprogramowania) rozważyć schowanie tej części infrastruktury za VPN, aby dostęp mieli tylko uprawnieni użytkownicy.

Źródło: ox.security

~Tymoteusz Jóźwiak