Podatności LiteLLM

Podatność w BerriAI LiteLLM przed wersją 1.101.0-rc.1, polegająca na obejściu izolacji dzierżawców w warstwie pamięci podręcznej semantycznej. Uwierzytelniony użytkownik może odczytać odpowiedzi z pamięci podręcznej innych dzierżawców, wykorzystując niezgodność kluczy metadanych między funkcjami _get_semantic_cache_tenant_scope() i _get_metadata_variable_name(). Atakujący z ważnym kluczem wirtualnym może wysyłać podobne semantycznie zapytania, aby uzyskać dane osobowe, finansowe lub kod źródłowy innych dzierżawców oraz spowodować automatyczne wykonanie połączeń narzędziowych pod cudzymi danymi uwierzytelniającymi.

W LiteLLM Proxy przed wersją 1.83.9 uwierzytelniony wywołujący z ważnym kluczem wirtualnym może umieścić api_base w treści żądania user_config, aby obejść is_request_body_safe, które blokuje api_base i base_url na najwyższym poziomie, ale wcześniej nie sprawdzało user_config. Ponieważ user_config konstruuje router wychodzący, zagnieżdżony cel przekierowuje żądanie po stronie serwera do wewnętrznego lub zewnętrznego hosta wybranego przez wywołującego.

BerriAI litellm w wersji 1.82.4 i wcześniejszych jest podatny na Server-Side Template Injection (SSTI). Nieuwierzytelnieni zdalni atakujący mogą wykonać dowolne polecenia systemu operacyjnego poprzez spreparowany parametr dotprompt_content w punkcie końcowym /prompts/test, z powodu użycia niezabezpieczonego środowiska jinja2.Environment.

LiteLLM 1.18.10 zawiera podatność zdalnego wykonania kodu w funkcji tworzenia serwera MCP. Aplikacja pozwala użytkownikom dodawać serwery MCP poprzez konfigurację JSON, określając dowolne wartości command i args, które są wykonywane na hoście bez walidacji. Umożliwia to atakującym uruchamianie dowolnych poleceń systemu operacyjnego.

LiteLLM proxy przed wersją 1.84.0 zawiera podatność związaną z parsowaniem nagłówka Host, która w określonych warunkach umożliwia nieuwierzytelniony dostęp do chronionych tras administracyjnych. Błąd wynika z rozbieżności między trasą ocenianą przez warstwę autoryzacji a trasą faktycznie przetwarzaną przez FastAPI.

Podatność w LiteLLM do 2026-04-08 umożliwia zdalnemu atakującemu wykonanie dowolnego kodu poprzez przepisanie kodu bajtowego na ścieżce /guardrails/test_custom_code.

Podatność w LiteLLM przed wersją 1.83.0, gdy włączone jest uwierzytelnianie JWT (enable_jwt_auth: true), polega na tym, że cache OIDC userinfo używa pierwszych 20 znaków tokena jako klucza cache. Tokeny JWT generowane przez ten sam algorytm podpisu mają identyczne pierwsze 20 znaków, co pozwala nieuwierzytelnionemu atakującemu na stworzenie tokena pasującego do cache'a i przejęcie tożsamości oraz uprawnień legalnego użytkownika.

LiteLLM w wersji przed 1.83.0 zawiera podatność polegającą na braku wymagania autoryzacji roli administratora dla endpointu /config/update. Uwierzytelniony użytkownik może modyfikować konfigurację proxy, zmienne środowiskowe oraz rejestrować własne procedury obsługi endpointów, co prowadzi do zdalnego wykonania kodu, odczytu plików serwera i przejęcia kont uprzywilejowanych.

W LiteLLM przed wersjami 1.88.6 i 1.96.2 wykryto podatność, która pozwala każdemu uwierzytelnionemu użytkownikowi proxy na przekierowanie wychodzącego wywołania dostawcy do kontrolowanego przez siebie miejsca docelowego i spowodowanie wysłania skonfigurowanych poświadczeń dostawcy do tego miejsca. Walidacja żądań w wielu plikach używała niekompletnych kontroli, które nie obejmowały wszystkich wrażliwych parametrów lub nie sprawdzały równoważnych wartości w zagnieżdżonych polach. Parametry routingu i poświadczeń, takie jak api_base, base_url, model_list, fallbacks i litellm_credential_name, mogły być stosowane bez usuwania zapisanego klucza operatora, co ujawniało poświadczenia dostawcy i inne skonfigurowane sekrety oraz umożliwiało żądania po stronie serwera do wewnętrznych usług.

LiteLLM przed wersją 1.82.0-stable nie stosował odpowiedniego sandboxingu i walidacji dla niestandardowych reguł ochronnych (Custom Code Guardrails) podczas ich tworzenia i aktualizacji, co pozwalało uprzywilejowanemu użytkownikowi na wykonanie dowolnego kodu Python w środowisku proxy i potencjalne ujawnienie sekretów procesu.

LiteLLM przed wersją 1.83.7-stable zawiera podatność polegającą na niewystarczającej walidacji ścieżek plików podczas rozpakowywania archiwów ZIP umiejętności (Skills). Uwierzytelniony użytkownik z dostępem do tras API LLM lub kluczem z trasami /v1/skills, anthropic_routes lub llm_api_routes może przesłać spreparowane archiwum, które umożliwia zapis plików poza zamierzonym katalogiem (path traversal).

LiteLLM przed wersją 1.83.10-stable zawiera podatność w punkcie końcowym /health/test_connection, która umożliwia odczyt plików z lokalnego systemu plików poprzez referencje oidc/file/. Luka wynika z rozpoznawania przez serwer referencji do zmiennych środowiskowych i plików OIDC dostarczonych w żądaniu.

LiteLLM przed wersją 1.83.10 pozwala użytkownikowi na zmianę własnej roli poprzez endpoint /user/update. Endpoint ogranicza dostęp tylko do własnego konta, ale nie sprawdza, które pola mogą być zmieniane. Użytkownik może ustawić swoją rolę na proxy_admin, uzyskując pełny dostęp administracyjny do wszystkich użytkowników, zespołów, kluczy, modeli i historii zapytań.

LiteLLM przed wersją 1.83.14 pozwala uwierzytelnionemu użytkownikowi internal_user na tworzenie kluczy API z dostępem do tras, które nie są dozwolone dla jego roli. Pole allowed_routes jest przechowywane bez weryfikacji, czy trasy mieszczą się w uprawnieniach użytkownika, co umożliwia eskalację uprawnień do proxy_admin.

LiteLLM w wersjach od 1.80.5 do 1.83.7 zawiera podatność w endpointcie POST /prompts/test, który akceptuje szablony promptów od użytkownika i renderuje je bez izolacji (sandbox). Specjalnie spreparowany szablon może wykonać dowolny kod w procesie proxy LiteLLM.