LiteLLM na produkcji po incydentach z 2026 roku

Czy LiteLLM jest bezpieczny po incydentach z 2026 roku

Tak, jeśli potrafisz go łatać i weryfikować jak usługę krytyczną, bo nią jest. Incydenty były prawdziwe, ale każdy dotyczył jasno określonych wersji i miał jasne wyjście. Dwa były atakami na sposób dystrybucji LiteLLM, jeden był błędem w kodzie. Tabela podsumowuje je na podstawie raportów LiteLLM i rekordu CVE, stan na 7 listopada 2026.

Przypadek z października niesie najcenniejszą lekcję dla zespołów utrzymaniowych. Według analizy przyczyn LiteLLM wszystko zaczęło się od klucza administracyjnego do wewnętrznej instancji LiteLLM Agent Platform, który 27 maja 2026 trafił do publicznego repozytorium i ponad cztery miesiące później nadal był ważny. Przez tę usługę atakujący zdobył token GitHub należący do właściciela organizacji. Podpis też nie pomógł: złośliwe obrazy miały ważny podpis poprzednim kluczem, dlatego LiteLLM zaleca dodatkowo sprawdzać digesty. Wyciągamy z tego wniosek, że przy każdej bramie chronią cię te same nawyki: przypinanie dokładnych artefaktów, krótki czas życia kluczy i zauważanie, kiedy coś, co uruchamiasz, się zmienia. LiteLLM opublikował już listę zmian w pipeline wydań, zarządzaniu tożsamością i wykrywaniu.

Jak sprawdzić, czy cię to dotknęło

Zacznij od inwentaryzacji wszystkich miejsc, w których działa LiteLLM: wdrożeń proxy, zadań CI, laptopów programistów i każdej aplikacji w Pythonie, która importuje SDK. Potem przejdź przez każdy incydent z tą listą w ręku.

1. 1

   Zapisz wersje i digesty

   Dla każdego wdrożenia zapisz wersję LiteLLM i digest obrazu, który teraz działa. Może się on różnić od tagu w manifeście. W środowisku Pythona, które może zawierać 1.107.0, LiteLLM odradza zaczynanie od pip install, bo każde uruchomienie Pythona może tam ponownie odpalić złośliwy kod. Zamiast tego przejrzyj pliki w site-packages.

2. 2

   Marzec: szukaj 1.82.7 i 1.82.8

   Przeszukaj logi CI, logi buildów i pliki lock pod kątem tych wersji, a site-packages pod kątem pliku litellm_init.pth. LiteLLM podaje też jako wskaźniki ruch wychodzący do models.litellm.cloud i checkmarx.zone, a raport z incydentu przyjmuje jako okno do sprawdzenia 10:39 do 16:00 UTC 24 marca 2026.

3. 3

   CVE-2026-42271: sprawdź wersje i wywołania endpointów

   Każde proxy od 1.74.2 do wersji poprzedzającej 1.83.7 było podatne. Jeśli któreś było dostępne dla osób lub usług, którym nie ufasz w pełni, przeszukaj logi dostępowe pod kątem żądań POST do /mcp-rest/test/connection i /mcp-rest/test/tools/list, a nieoczekiwane wywołania traktuj jak kompromitację hosta. To sprawdzenie logów to nasza własna propozycja. LiteLLM nie publikuje takiej procedury.

4. 4

   Październik: szukaj 1.107.0 i jego plików

   Szukaj litellm 1.107.0, plików cook.pth, cook.py i sitecustomize.py w site-packages, procesu Pythona trzymającego /tmp/remote_code_loader.lock oraz digestu obrazu, który LiteLLM opublikował jako wskaźnik. LiteLLM zaznacza, że brak znalezisk niewiele dowodzi, bo kontenery i katalogi tymczasowe mogły już zostać wyczyszczone, więc sprawdź też, czy któreś wdrożenie pobrało 21 października latest, main-latest, main-stable albo v1.107.0.

5. 5

   Zrotuj wszystko, do czego host miał dostęp

   Tam, gdzie narażenie jest prawdopodobne, przebuduj środowisko ze sprawdzonej wersji i zrotuj wszystko, do czego host miał dostęp. Dla października LiteLLM wymienia rolę instancji lub zadania, każdy klucz dostawcy zapisany w bazie proxy, klucz główny i klucze wirtualne, hasło do bazy danych oraz każdy sekret w środowisku dowolnego procesu na hoście. Unieważnij stare poświadczenia. Samo wydanie nowych nie wystarczy.

Czy potrzebujesz Redisa i Postgresa

Postgres potrzebujesz, gdy tylko wydajesz klucze wirtualne, a Redisa, gdy ruch obsługuje więcej niż jeden proces workera. Klucze wirtualne w LiteLLM wymagają bazy Postgres wskazanej przez DATABASE_URL. Strona o wymaganiach dla Redisa określa go jako wysoce zalecany przy każdym wdrożeniu z więcej niż jednym workerem, a to obejmuje zarówno jeden kontener uruchomiony z kilkoma workerami, jak i wdrożenie Kubernetes z więcej niż jedną repliką. Bez Redisa każdy worker trzyma własny stan:

• Limity zapytań liczone są per worker, więc w przykładzie z dokumentacji limit 100 zapytań na minutę przy czterech workerach przepuszcza 400
• Twarde budżety mogą zostać przekroczone, bo równoległe zapytania na różnych workerach są liczone, zanim baza danych nadąży
• Usunięcie klucza, zmiana budżetu czy zmiana w zespole docierają do innych workerów dopiero po wygaśnięciu ich lokalnego wpisu w cache, więc unieważniony klucz nadal działa na workerach, które nie obsłużyły unieważnienia
• Trafienia w cache odpowiedzi zdarzają się tylko na workerze, który zapisał odpowiedź
• Logowanie SSO do panelu administracyjnego może się nie udać, gdy przekierowanie przeglądarki trafi do innego workera niż ten, który je rozpoczął

Ten trzeci punkt to zwykle odpowiedź na pytanie, dlaczego unieważnione klucze jeszcze przez jakiś czas działają. Ustawienie user_api_key_cache_ttl określa, ile sekund klucze są trzymane w pamięci, a wspólny stan w Redisie sprawia, że unieważnienie obowiązuje na wszystkich workerach. Napisz test offboardingu, który unieważnia klucz, a potem wywołuje nim każdą replikę, i uruchamiaj go przed startem oraz po każdej aktualizacji. Dokumentacja zaznacza też, że same zmienne środowiskowe REDIS_HOST i REDIS_PORT nie wystarczą: na Redisa muszą wskazywać zarówno ustawienia routera, jak i blok cache.

Dla LiteLLM na Kubernetes strona z dobrymi praktykami produkcyjnymi zaleca jeden worker Uvicorn na pod i skalowanie liczbą podów, jako minimum około 1 vCPU i 4 GiB pamięci na worker, Redis 7.0 lub nowszy przy więcej niż jednej instancji oraz limit połączeń z bazą przez database_connection_pool_limit, domyślnie 10. Endpoint gotowości /health/readiness nadal zwraca 200, gdy baza jest niedostępna, więc pody dalej obsługują ruch. Świadomie zdecyduj, czy tego chcesz podczas awarii bazy.

Jak przypinać, weryfikować i aktualizować wersje

Przypnij digest obrazu, zweryfikuj jego podpis i przełączaj po jednym środowisku, gdy przejdą twoje własne testy regresji. Strona LiteLLM o bezpieczeństwie obrazów zaleca przypinanie po digeście, bo ustala dokładną zawartość obrazu niezależnie od zmian tagów, ostrzega przed latest na produkcji i oznaczyła main-stable oraz main-latest jako wycofywane. Obrazy na GHCR są podpisywane przez cosign od v1.83.0. Po incydencie z października LiteLLM zmienił klucz podpisujący i zaleca ufać staremu kluczowi tylko przy obrazach opublikowanych przed 1.107.0. W naszej ocenie wdrożenie przypięte po digeście zostałoby w czasie incydentu przy dotychczasowym obrazie, niezależnie od tego, na co wskazywały tagi.

Zmienił się też rytm wydań. Stan na 7 listopada 2026: kandydaci do wydania i wydania stabilne ukazują się co tydzień we wtorek rano, począwszy od tygodnia 2 listopada 2026, a kandydaci dostają przed promocją siedmiodniowe okno dla wczesnych testerów. LiteLLM zaleca przypinanie produkcji do najnowszego wydania stabilnego. Testuje też przez miesiąc linię długoterminowego wsparcia, zaczynając od 1.108, i na czas pilotażu zawiesił zasadę łatania czterech najnowszych linii stabilnych. Zanim założysz, że twoja linia nadal dostaje poprawki, sprawdź stronę o wsparciu wersji.

1. 1

   Wybierz wersję docelową i przeczytaj informacje o wydaniu

   Wybierz wydanie stabilne, przeczytaj informacje o wydaniu pod kątem zmienionych ustawień domyślnych i zapisz digest. Dwa świeże przykłady: od 1.104.0 proxy nie startuje bez silnego klucza głównego, a serwery MCP typu STDIO są wyłączone, dopóki nie ustawisz LITELLM_ENABLE_MCP_STDIO=true. Od 1.105.0 wyłączona jest ścieżka /sso/debug.

2. 2

   Zweryfikuj artefakt

   Uruchom cosign verify z kluczem publicznym z przypiętego commita, tak jak pokazuje dokumentacja LiteLLM, i porównaj digest z zapisanym. Skopiuj zweryfikowany obraz do własnego rejestru, żeby produkcja nigdy nie pobierała go z publicznego tagu.

3. 3

   Uruchom testy regresji

   Na stagingu odtwórz stały zestaw zapytań dla każdej trasy modelu i sprawdź kody statusu, streaming, wywołania narzędzi, zapisy kosztów, unieważnianie kluczy i egzekwowanie budżetów. Linia długoterminowego wsparcia LiteLLM dostaje poprawki tłumaczenia zapytań do dostawców i śledzenia kosztów, co podpowiada, gdzie aktualizacje najczęściej zmieniają zachowanie.

4. 4

   Wdrażaj etapami

   Przełączaj jedno środowisko albo część ruchu naraz, obserwuj odsetek błędów i opóźnienia dla każdego dostawcy i trzymaj poprzedni digest gotowy do wycofania. Migracje schematu mogą utrudnić wycofanie, więc najpierw zrób kopię bazy. Przewodnik produkcyjny pozwala też zablokować migracje w podach przez DISABLE_SCHEMA_UPDATE i uruchamiać je jako osobny krok.

Bezpieczne wystawienie LiteLLM i obsługa logów

Wystawiaj tylko ścieżki, które wywołują twoi klienci, w miarę możliwości z sieci prywatnej, a wszystko, co administracyjne, trzymaj wewnątrz. To także sedno strony LiteLLM o dobrych praktykach bezpieczeństwa. W praktyce:

• Uruchamiaj proxy za ingressem lub wewnętrznym load balancerem, z politykami sieciowymi Kubernetes, które wpuszczają tylko przestrzenie nazw klientów i pozwalają na ruch wychodzący tylko do dostawców modeli, Postgresa i Redisa
• Udostępniaj panel administracyjny tylko pod wewnętrzną nazwą hosta lub przez VPN albo wyłącz go we wdrożeniu publicznym przez DISABLE_ADMIN_UI=True. Gdy administratorzy logują się przez SSO lub jako imienni użytkownicy admin, ustaw disable_env_credential_login: true, bo inaczej UI_USERNAME i UI_PASSWORD działają jak wspólny login administratora, a przy nieustawionym UI_PASSWORD akceptowany jest sam klucz główny
• Ustaw razem NO_DOCS, NO_REDOC i NO_OPENAPI na True. Domyślnie Swagger UI, ReDoc i schemat OpenAPI są dostępne bez uwierzytelnienia, a ustawienie tylko jednej zmiennej zostawia pozostałe do odczytu
• Trzymaj klucz główny i LITELLM_SALT_KEY w magazynie sekretów, daj każdemu obciążeniu własny klucz wirtualny i nie rotuj klucza salt po zapisaniu poświadczeń, przed czym ostrzega LiteLLM
• W przypadku MCP zostaw serwery STDIO wyłączone, jeśli ich nie potrzebujesz, i oznacz każdy serwer MCP jawnie przez available_on_public_internet. Dokumentacja jest niespójna co do wartości domyślnej, a wywołujący liczy się jako wewnętrzny tylko wtedy, gdy jego adres IP mieści się w mcp_internal_ip_ranges
• Za reverse proxy ustaw PROXY_BASE_URL na dokładnie ten adres https, który widzą użytkownicy, żeby ciasteczka sesji miały flagę Secure

Logowanie i retencja logów

Domyślnie LiteLLM zapisuje dla każdego zapytania log wydatków i logi błędów, ale nie przechowuje treści promptów i odpowiedzi. Ustawienie store_prompts_in_spend_logs włącza zapisywanie treści, a disable_spend_logs wyłącza zapisywanie logów wydatków do bazy. Retencja jest wyłączona, dopóki jej nie ustawisz: bez maximum_spend_logs_retention_period nic nigdy nie jest usuwane. Ustawienia czyszczenia działają bez licencji enterprise, a zagregowane dzienne wydatki według tagów mają osobne ustawienie retencji. Usuwanie wierszy nie zwraca miejsca na dysku systemowi operacyjnemu, więc planuj przestrzeń dla Postgresa pod szczyt, a nie pod stan ustalony. Z inspektorem ochrony danych ustal, czy prompty w ogóle wolno przechowywać. Brama, która trzyma treść zapytań, przechowuje wszystko, co wysyłają klienci, także poświadczenia wklejone do promptów.

# config.yaml (excerpt)
general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  disable_env_credential_login: true
  store_prompts_in_spend_logs: false
  maximum_spend_logs_retention_period: "30d"
  maximum_spend_logs_cleanup_cron: "0 4 * * *"
  database_connection_pool_limit: 10

# Redis: both blocks are needed for multi-worker state
router_settings:
  redis_host: os.environ/REDIS_HOST
  redis_port: os.environ/REDIS_PORT
  redis_password: os.environ/REDIS_PASSWORD
litellm_settings:
  cache: true
  cache_params:
    type: redis
    host: os.environ/REDIS_HOST
    port: os.environ/REDIS_PORT
    password: os.environ/REDIS_PASSWORD

# Environment of the client-facing pods
LITELLM_MODE=PRODUCTION
NO_DOCS=True
NO_REDOC=True
NO_OPENAPI=True
DISABLE_ADMIN_UI=True

Które funkcje wymagają licencji enterprise

Na 7 listopada 2026 brama open source obejmuje routing, klucze wirtualne i logi wydatków, a klucz licencyjny na tym samym obrazie włącza funkcje związane z nadzorem. Najczęściej zespoły najpierw trafiają na SSO: do panelu administracyjnego jest bezpłatne dla maksymalnie pięciu użytkowników, powyżej trzeba licencji enterprise. LiteLLM podaje, że cena zależy od wielkości wdrożenia i użycia, oferuje 30-dniowy okres próbny i sprzedaje licencje przez marketplace'y AWS i Azure. Tabela zestawia funkcje enterprise, których najpewniej będziesz potrzebować, z drogą obejścia w open source. Prawa kolumna to nasza własna ocena.

Nasza praktyczna zasada: jeśli potrzebujesz SSO w panelu dla więcej niż pięciu osób, dowodów audytowych dla audytora lub regulatora albo osobnych miejsc docelowych logów dla zespołów, porównaj licencję z czasem inżynierów potrzebnym, by odbudować te funkcje wokół bramy i utrzymać je w działaniu przy kolejnych aktualizacjach. Do tego porównania należy jeszcze jeden punkt. Według strony LiteLLM o dobrych praktykach bezpieczeństwa klienci enterprise dostają e-mail o większych aktualizacjach bezpieczeństwa siedem dni przed publicznym ujawnieniem, co ma znaczenie, jeśli nie jesteś w stanie załatać systemu w ciągu jednego dnia.

Lista kontrolna przed startem samodzielnie hostowanej bramy LiteLLM

Zanim zaczniesz samodzielnie hostować LiteLLM dla prawdziwego ruchu, każdy punkt poniżej powinien mieć właściciela i udokumentowane wykonanie.

1. 1

   Wersja i łańcuch dostaw

   Wydanie stabilne przypięte po digeście, podpis zweryfikowany, obraz skopiowany do własnego rejestru i nigdzie w manifestach ani w CI tagów latest czy main-stable.

2. 2

   Znane incydenty zamknięte

   Inwentarz sprawdzony pod kątem 1.82.7, 1.82.8, 1.107.0 i każdej wersji poniżej 1.83.7, z udokumentowaną rotacją wszędzie tam, gdzie narażenie było prawdopodobne.

3. 3

   Stan

   Postgres z kopiami zapasowymi i przetestowanym odtwarzaniem, Redis 7.0 lub nowszy dla każdego wdrożenia z więcej niż jednym workerem i test offboardingu zaliczony na każdej replice.

4. 4

   Wystawienie

   Panel administracyjny wewnętrzny lub wyłączony, dokumentacja API wyłączona, logowanie poświadczeniami ze środowiska wyłączone, STDIO MCP wyłączone, każdy serwer MCP świadomie oznaczony jako publiczny lub prywatny, polityki sieciowe wdrożone.

5. 5

   Sekrety

   Klucz główny, klucz salt i klucze dostawców w magazynie sekretów, jeden klucz wirtualny na obciążenie z datą ważności i żadna aplikacja nie korzysta z klucza głównego.

6. 6

   Logi

   Okres retencji ustawiony, przechowywanie promptów uzgodnione z ochroną danych, logi przesyłane do twojego stosu obserwowalności z własną retencją.

7. 7

   Testy

   Zestaw testów regresji dla każdej trasy modelu, test obciążenia przy spodziewanym szczycie z zapasem i przynajmniej raz przećwiczone przełączenie między dostawcami.

8. 8

   Utrzymanie

   Wskazana osoba odpowiedzialna za łatki, która śledzi komunikaty bezpieczeństwa i informacje o wydaniach LiteLLM, docelowy czas wdrażania poprawek bezpieczeństwa i runbook rotacji wszystkich poświadczeń, które trzyma brama.

Cloudsail wdraża i utrzymuje LiteLLM na klastrach Kubernetes i kontach chmurowych klientów, łącznie z testami akceptacyjnymi takimi jak w tej liście.

Brama LiteLLM: wdrożenie i utrzymanieInżynieria platformy LLMTestowanie systemów AI