Wprowadzenie do problemu / definicja
LiteLLM to popularna, otwartoźródłowa brama AI, która pośredniczy między aplikacjami a dostawcami modeli językowych. W praktyce pełni funkcję centralnego punktu dostępu do kluczy API, polityk routingu, logów zapytań oraz integracji z usługami zewnętrznymi. To sprawia, że staje się zasobem o wysokiej wartości dla atakujących.
Najważniejszy problem ujawniony przez badaczy dotyczył pozostawienia w publicznie dostępnych wdrożeniach przykładowego klucza administracyjnego sk-1234. W części przypadków wystarczało przesłać ten nagłówek autoryzacyjny, aby uzyskać pełne uprawnienia administracyjne do bramy.
W skrócie
W badaniu przeprowadzonym w lutym 2026 roku wykryto 3074 publicznie dostępne instancje LiteLLM. Spośród nich 294 akceptowały domyślny klucz sk-1234 lub działały bez poprawnie ustawionego klucza głównego.
- problem dotyczył niemal 1 na 10 widocznych w internecie instancji,
- atak nie wymagał zaawansowanych technik ani łamania kryptografii,
- przejęcie bramy mogło prowadzić do ujawnienia kluczy dostawców modeli, logów i konfiguracji,
- w określonych scenariuszach możliwe było również uzyskanie dostępu do poświadczeń chmurowych hosta.
Kontekst / historia
LiteLLM zdobył popularność jako warstwa pośrednia upraszczająca korzystanie z wielu modeli i wielu dostawców w jednolity sposób. W środowiskach produkcyjnych tego typu gateway odpowiada często za kontrolę kosztów, zarządzanie użytkownikami, limity wykorzystania, RBAC oraz integracje z dodatkowymi mechanizmami bezpieczeństwa.
Istotą problemu nie był klasyczny pojedynczy zero-day, lecz kombinacja słabej konfiguracji i ryzykownych założeń projektowych. Dokumentacja przez długi czas prezentowała przykładową wartość sk-1234 jako master key z sugestią, aby zmienić ją przed użyciem produkcyjnym. Część operatorów najwyraźniej pozostawiła jednak tę wartość bez modyfikacji.
Dodatkowo starsze wersje LiteLLM, wcześniejsze niż 1.82.0-stable, traktowały brak poprawnie ustawionego master key w sposób szczególnie niebezpieczny, przyznając żądaniom pełne uprawnienia administracyjne. W połączeniu z innymi lukami bezpieczeństwa ujawnionymi w 2026 roku zwiększało to potencjalną skalę kompromitacji.
Analiza techniczna
Klucz master key w LiteLLM ma znaczenie krytyczne, ponieważ zapewnia uprawnienia administratora proxy. Taki administrator może tworzyć kolejne klucze, zarządzać użytkownikami i zespołami, modyfikować konfigurację, korzystać z tras administracyjnych oraz uzyskiwać dostęp do danych przechowywanych przez gateway.
Z perspektywy atakującego scenariusz był prosty. Jeśli publicznie wystawiona instancja LiteLLM akceptowała nagłówek Bearer sk-1234, napastnik otrzymywał prawa administratora. To otwierało drogę do odczytu kluczy API dostawców modeli, podglądu promptów i odpowiedzi modeli, a także analizy konfiguracji połączeń.
Szczególnie niebezpieczna była możliwość nadużycia funkcji pass-through endpoint. Pozwala ona administratorowi skonfigurować trasę przekazującą żądania do wskazanego adresu URL. Jeśli adres docelowy nie jest odpowiednio filtrowany, przejęta brama może zostać użyta do komunikacji z usługami metadanych chmurowych, localhostem lub prywatnymi segmentami sieci.
W praktyce oznacza to możliwość pozyskania poświadczeń IAM przypisanych do maszyny lub workloadu, a następnie wykorzystania ich do dalszego ruchu bocznego. Nie chodzi więc wyłącznie o przejęcie samego narzędzia AI, ale o potencjalny pomost do szerszego naruszenia środowiska.
Na ryzyko nakładały się również inne słabości ujawnione dla LiteLLM, w tym luki związane z MCP oraz guardrails. Domyślny lub nieustawiony klucz administracyjny mógł znacząco ułatwiać dostęp do tych funkcji i zwiększać skuteczność kolejnych etapów ataku.
Konsekwencje / ryzyko
Skutki przejęcia LiteLLM mogą być znacznie poważniejsze niż zwykły dostęp do pojedynczej aplikacji. Tego typu brama agreguje bowiem klucze do wielu dostawców modeli, przez co jedno naruszenie może umożliwić masowe nadużycia rozliczeniowe, określane jako LLMjacking.
Atakujący może wykonywać kosztowne zapytania na rachunek ofiary, uzyskać wiedzę o wykorzystywanych modelach, politykach dostępu i architekturze środowiska, a także odczytać wrażliwe dane przepływające przez system. W wielu organizacjach są to informacje o wysokiej wartości operacyjnej i biznesowej.
Jeszcze większe ryzyko pojawia się wtedy, gdy gateway działa z szerokimi uprawnieniami chmurowymi. W takim układzie przejęcie LiteLLM może prowadzić do odczytu sekretów, dostępu do baz danych, dalszej eskalacji uprawnień lub kompromitacji innych usług wewnętrznych.
Problemem jest również ocena skutków incydentu po fakcie. Sama aktualizacja oprogramowania nie usuwa wszystkich następstw kompromitacji. Jeśli napastnik wygenerował nowe klucze, dodał własne wpisy konfiguracyjne lub pozyskał poświadczenia, organizacja może być zmuszona do szerokiej rotacji sekretów i pełnego dochodzenia powłamaniowego.
Rekomendacje
Pierwszym krokiem powinno być natychmiastowe sprawdzenie, czy jakakolwiek instancja LiteLLM jest publicznie dostępna oraz czy nie korzysta z przykładowego klucza sk-1234. Klucz główny należy zastąpić długą, losową wartością i przeprowadzić bezpieczną rotację zgodnie z procedurami organizacji.
Drugim priorytetem jest aktualizacja środowiska do wersji 1.84.0 lub nowszej, ponieważ obejmuje ona poprawki dla szeregu istotnych podatności opisywanych w 2026 roku. Jeżeli natychmiastowa aktualizacja nie jest możliwa, warto tymczasowo ograniczyć dostęp do tras administracyjnych, endpointów MCP oraz funkcji związanych z guardrails na poziomie reverse proxy, WAF lub API gateway.
Nie mniej ważne jest ograniczenie uprawnień samego workloadu. Instancja LiteLLM nie powinna działać z nadmiarowymi rolami IAM, a jej ruch wychodzący powinien być filtrowany regułami egress. Dzięki temu nawet w przypadku przejęcia zmniejsza się ryzyko wykorzystania hosta do pobrania poświadczeń z usług metadanych lub komunikacji z wrażliwymi zasobami wewnętrznymi.
- zweryfikować wszystkie wygenerowane klucze, użytkowników i zespoły,
- przejrzeć konfigurację pass-through endpointów,
- skontrolować listę guardrails pod kątem nieautoryzowanych wpisów,
- przeanalizować logi dostępu do tras administracyjnych i MCP,
- zrotować klucze dostawców modeli oraz inne sekrety, jeśli istnieje podejrzenie nadużycia,
- traktować AI gateway jako system krytyczny, porównywalny z menedżerem sekretów lub bramą API wysokiego zaufania.
Podsumowanie
Przypadek LiteLLM pokazuje, że w środowiskach AI największe ryzyko często nie wynika z wyrafinowanych exploitów, lecz z połączenia ekspozycji internetowej, domyślnej konfiguracji i nadmiernych uprawnień infrastrukturalnych. Pozostawienie przykładowego klucza sk-1234 w systemie produkcyjnym mogło otworzyć drogę do pełnego przejęcia centralnej warstwy zarządzającej ruchem do modeli.
Dla zespołów bezpieczeństwa to jasny sygnał, że bramy AI należy inwentaryzować, monitorować i utwardzać równie rygorystycznie jak klasyczne API gateway, systemy IAM czy magazyny sekretów. Bezpieczeństwo generatywnej AI coraz częściej zależy bowiem nie od samego modelu, lecz od bezpieczeństwa warstwy pośredniczącej.
Źródła
- Nearly 1 in 10 Exposed LiteLLM Gateways Accepted the Example „sk-1234” Admin Key — https://thehackernews.com/2026/09/nearly-1-in-10-exposed-litellm-gateways.html
- LiteLLM Documentation – Virtual Keys — https://docs.litellm.ai/docs/proxy/virtual_keys
- BerriAI / LiteLLM Security Advisories — https://github.com/BerriAI/litellm/security/advisories
- Known Exploited Vulnerabilities Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- Microsoft Security Blog — https://www.microsoft.com/en-us/security/blog/