Výchozí účet s nízkými oprávněními na proxy serveru LiteLLM může díky zřetězení tří zranitelností získat plná administrátorská práva a spustit na serveru libovolný kód, upozornili výzkumníci společnosti Obsidian Security.
Tři chyby v jednom řetězci
LiteLLM je široce nasazovaná open-source brána pro umělou inteligenci, která zprostředkovává volání více než stovky poskytovatelů modelů prostřednictvím jednoho rozhraní kompatibilního s OpenAI. Ovládnutí takového serveru odhalí klíče všech napojených poskytovatelů, tajné údaje sloužící k dešifrování uložených přihlašovacích údajů i veškeré dotazy a odpovědi, které bránou procházejí. Obsidian ohodnotila celý řetězec na CVSS 9,9, tedy do kritického pásma. Tvůrce LiteLLM, firma BerriAI, zahrnula kompletní opravu do verze 1.83.14-stable, kterou GitHub uvádí jako vydanou 2. května; uživatelé by měli aktualizovat alespoň na tuto verzi.
První chybou, CVE-2026-47101, je obejití autorizace. Když běžný uživatel vygeneruje virtuální API klíč, LiteLLM uloží pole allowed_routes zadané volajícím bez ověření vůči jeho roli. Pole má sice omezovat, co klíč může dělat, ale proxy server jej současně bere jako záložní oprávnění – neadministrátor tak může vytvořit klíč s univerzálním přístupem ke všem trasám, včetně těch určených jen administrátorům.
Po obejití této kontroly se otevírají dvě další cesty. První je CVE-2026-47102, navýšení oprávnění: koncový bod pro úpravu uživatelského profilu umožňuje uživateli upravit vlastní záznam bez omezení, jaká pole může měnit, takže si stačí v poli role nastavit hodnotu proxy_admin a server tuto změnu přijme a uloží. Druhou je CVE-2026-40217, útok unikající z izolovaného prostředí ve funkci Custom Code Guardrail, která spouští administrátorem zadaný Python kód. Produkční koncové body spouštěly kód pomocí příkazu exec() bez filtrování na úrovni zdrojového kódu, což v praxi umožnilo spustit libovolný systémový příkaz a otevřít útočníkovi vzdálenou shellovou relaci.
Co útočník díky chybám získá
Plně zneužitý řetězec odhalí hlavní klíč, šifrovací klíč chránící uložené přihlašovací údaje i adresu databáze, a stejně tak veškeré klíče napojených poskytovatelů modelů – ať jde o OpenAI, Anthropic, Gemini, Azure nebo Bedrock. Veškerá komunikace procházející branou, tedy dotazy i odpovědi, se navíc stává čitelnou, což v reálném nasazení často znamená osobní údaje, zdrojový kód, interní tikety nebo vložená hesla.
Obsidian dokumentovala případ, kdy útočník zneužil zabudovaný mechanismus zpětných volání LiteLLM, který se nikde nezobrazuje v administrátorském rozhraní, k tomu, aby v reálném čase nahradil odpověď modelu podvrženým voláním nástroje a přepsal bezpečnostní kontext tak, aby akce vypadala jako schválená. V demonstraci proti nástroji Claude Code routovanému přes kompromitovaný proxy server stačilo, aby vývojář napsal jediné slovo „hello“, a útočník na jeho stroji okamžitě otevřel vzdálenou shellovou relaci.
Mimo samotný řetězec navíc LiteLLM umožňuje administrátorům registrovat MCP servery, které proxy spouští jako lokální procesy – jde o záměrný designový kompromis, nikoli o chybu, díky němuž ale dosažení administrátorských práv v praxi rovná se dosažení spuštění kódu. Obsidian tento postup reprodukovala i ve verzi 1.88.0. Samostatná chyba ve stejném mechanismu, CVE-2026-42271, byla navíc skutečně zneužívána v praxi a byla zařazena do katalogu CISA KEV.
Obsidian zdůrazňuje, že popsaný řetězec prezentuje jako zdokumentovanou chybu s funkčním demem, nikoli jako útok pozorovaný přímo v praxi – pozice nástroje v infrastruktuře z něj ale i tak dělá lákavý cíl. LiteLLM si přitom prošel náročným rokem i jinak: v březnu kompromitace dodavatelského řetězce zadními vrátky napadla dvě vydání na PyPI a v dubnu byla kritická chyba typu SQL injection zneužita už během 36 hodin od zveřejnění.
Co by měli administrátoři udělat
Doporučeným krokem je aktualizace na verzi 1.83.14-stable nebo novější, následovaná důkladným auditem: prověřením všech účtů s rolí proxy_admin, revizí všech nastavení Custom Code Guardrail i kontrolou zpětných volání nahraných z konfiguračního souboru, protože ty se v konzoli nezobrazují a jsou přesně tím místem, kam by útočník po získání přístupu mohl ukrýt svou přítomnost. Při podezření na kompromitaci se doporučuje provést rotaci klíčů poskytovatelů, databázových přihlašovacích údajů i případných uložených tokenů MCP. Celý řetězec přitom stojí na stejném vzorci důvěry na špatném místě: ochrana tras důvěřovala poli zadanému volajícím, jednotlivé funkce důvěřovaly samotné ochraně tras, a nikdo to ve skutečnosti neověřil.
Zdroj: thehackernews.com
Zdroj: IT SECURITY NETWORK NEWS
