Kritinė LiteLLM spraga (CVSS 9.9): eilinis vartotojas gali perimti visą AI sietuvą

Kibernetinio saugumo tyrėjai iš „Obsidian Security“ aprašė kritinę spragų grandinę plačiai naudojamame atvirojo kodo AI sietuve „LiteLLM“. Surišus tris atskiras klaidas, paprastas, žemiausių teisių vartotojas gali pasidaryti administratoriumi ir paleisti savo kodą tiesiai serveryje. Bendras grandinės pavojingumo įvertis — CVSS 9.9 iš 10, tai yra pačiame kritiškiausiame diapazone. Apie spragą jau įspėja didieji saugumo leidiniai, todėl komandos, savo infrastruktūroje sukusios „LiteLLM“, turėtų reaguoti nedelsdamos.

Įdomiausia detalė — pataisos jau egzistuoja nuo balandžio pabaigos (versija v1.83.14-stable), bet plataus dėmesio istorija sulaukė tik dabar, birželio viduryje. Tai reiškia, kad daugybė savarankiškai talpinamų „LiteLLM“ kopijų pasaulyje greičiausiai vis dar veikia su pažeidžiama versija.

Kas yra „LiteLLM“ ir kodėl tai svarbu

„LiteLLM“ — tai AI sietuvas (angl. AI gateway): vienas suvienodintas, su „OpenAI“ suderinamas API, per kurį programa gali kreiptis į 100+ skirtingų modelių tiekėjų — „OpenAI“, „Anthropic“, „Google“, „Azure“, „Bedrock“ ir kitus. Vietoj to, kad kiekvienoje aplikacijoje atskirai tvarkytum raktus, limitus ir maršrutus, viskas suvedama į vieną tašką: rakto saugojimas, autentifikacija, biudžetai, maršrutizavimas, apsauginiai filtrai (guardrails) ir audito žurnalai. Tas pats serveris dažnai veikia ir kaip MCP bei agentų sietuvas.

Būtent dėl šios centralizacijos „LiteLLM“ yra patogus — ir būtent dėl jos jis yra toks vertingas taikinys. Kas kontroliuoja sietuvą, tas mato ir valdo viską, kas per jį teka.

Kaip veikia atakos grandinė

Grandinę sudaro trys spragos, kurias užpuolikas vykdo viena po kitos, pradėdamas nuo įprastos, mažų teisių paskyros (internal_user).

1 žingsnis — autorizacijos apėjimas (CVE-2026-47101)

Raktų generavimo galiniai taškai (/key/generate, /key/update) priima lauką allowed_routes, bet jo nesutikrina su tikrosiomis prašytojo teisėmis. Žemų teisių vartotojas gali pasigaminti raktą su pakaitos simboliu ["/*"], kuris staiga pasiekia ir tik administratoriui skirtus maršrutus.

2 žingsnis — teisių eskalacija (CVE-2026-47102)

Galiniai taškai /user/update ir /user/bulk_update neturi lauko lygio autorizacijos: vartotojas gali redaguoti savo paties įrašo lauką user_role. Tereikia atnaujinti savo paskyrą nustatant user_role: "proxy_admin" — ir sistema tai priima. Nuo šios akimirkos užpuolikas yra pilnateisis administratorius.

3 žingsnis — kodo vykdymas serveryje (CVE-2026-40217)

Paskutinė spraga — „smėliadėžės“ pabėgimas per pasirinktinius apsauginius filtrus. Kuriant „Custom Code Guardrail“, vartotojas rašo Python logiką tariamai „ribotoje aplinkoje (be importų)“. Tačiau po kapotu naudojamas exec() gauna globalų žodyną, iš kurio nepašalintas __builtins__, todėl Python automatiškai grąžina visą standartinį funkcijų rinkinį. Užpuolikas gali įterpti kodą, kuris importuoja os ir paleidžia, pavyzdžiui, reverse shell — ir jis įvykdomas dar filtro kompiliavimo metu.

Yra ir ketvirtas vykdymo kelias: per stdio MCP serverius, kurie reikalauja proxy_admin teisių, bet leidžia komandų injekciją. O administratoriaus teises užpuolikas jau turi po 2 žingsnio.

Ką užpuolikas gauna

Kai serveris perimtas, atsiveria praktiškai viskas:

• Serverio paslaptys — LITELLM_MASTER_KEY, LITELLM_SALT_KEY (kuriuo iššifruojami saugomi kredencialai) ir DATABASE_URL.
• Visi tiekėjų raktai — „OpenAI“, „Anthropic“, „Azure“, „Bedrock“ ir kt. API raktai, sukrauti vienoje vietoje.
• MCP ir agentų OAuth žetonai, SaaS API raktai, paslaugų paskyrų kredencialai.
• Visi pokalbiai — prompt'ai ir atsakymai, žurnaluose dažnai su asmens duomenimis ar net kliento programos kodu.

Pavojingiausia dalis — pozicija, kurią „Obsidian“ vadina „man-in-the-gateway“. Perėmęs sietuvą užpuolikas gali tyliai perrašinėti modelio atsakymus pakeliui, įterpti savavališkus įrankių iškvietimus į žemiau veikiančius agentus ir apeiti saugos patikras dar prieš joms suveikiant. Tai jau nebe vien duomenų vagystė — tai galimybė manipuliuoti tuo, ką jūsų AI „nusprendžia“ ir padaro.

Kodėl tai aktualu Lietuvos verslui

„LiteLLM“ Lietuvoje populiarus tiksliai dėl tų pačių priežasčių, kaip ir visur: agentūros bei startuoliai juo centralizuoja kelių tiekėjų raktus, kontroliuoja AI sąnaudas ir mato bendrą naudojimą. Bet jeigu toks sietuvas pastatytas „kad tik veiktų“ — su numatytaisiais nustatymais, atviru prievadu ir be reguliarių atnaujinimų — jis tampa vienu tašku, per kurį nuteka visi jūsų AI raktai ir visi klientų pokalbiai vienu metu.

Tai gera proga prisiminti paprastą taisyklę: AI infrastruktūra yra tokia pati produkcijos sistema, kaip ir duomenų bazė ar mokėjimų vartai. Jai galioja tos pačios higienos taisyklės — atnaujinimai, prieigos ribojimas, raktų rotacija ir audito žurnalai. „Patogus įrankis, kurį kažkada pastatėme ir pamiršome“ yra tiksliai tas profilis, kurį užpuolikai šiandien medžioja.

Ką daryti dabar

1. Nedelsiant atnaujinkite iki v1.83.14-stable arba naujesnės versijos — visa trijų CVE grandinė uždaroma būtent joje.
2. Peržiūrėkite visas proxy_admin paskyras ir traktuokite jas kaip prieigą prie viso serverio.
3. Patikrinkite visus pasirinktinius „guardrails“, užregistruotus sietuve — ar nėra įtartino kodo.
4. Patikrinkite config.yaml callback'us — kenkėjiški jų įrašai administratoriaus sąsajoje gali nesimatyti.
5. Rotuokite raktus — tiekėjų API raktus, duomenų bazės kredencialus ir MCP žetonus, jei yra bent įtarimas, kad jie galėjo nutekėti.
6. Nemaršrutizuokite srauto per nepatikimus trečiųjų šalių tarpinius sietuvus tarp savo agentų ir modelių.

Atsakingo atskleidimo eiga buvo ilga: spraga „BerriAI“ komandai pranešta dar vasarį, pataisos diegtos balandžio mėnesį, CVE numeriai priskirti gegužę, o vieša techninė analizė ir platus žiniasklaidos dėmesys atėjo tik birželį. Klasikinis priminimas, kad pataisos buvimas ir pataisos įdiegimas — du visiškai skirtingi dalykai.