LiteLLM a fost compromis de două ori în 2026. Prima dată în martie; arhiva furată atunci — 153 GB, analizată de Hudson Rock în august — a fost legată de aproximativ 2.500 de domenii corporative. A doua oară, pe 21 octombrie, e cazul mai instructiv, din cauza locului în care atacatorul a găsit credențialul de pornire.
Credențialul stătea chiar în jurnalele furnizorului
LiteLLM rula intern o instanță a propriului produs, iar acea instanță era accesibilă din internetul public. În timpul investigației, compania a găsit acolo un cont de utilizator neașteptat, cu un nume care nu atrăgea atenția. Cum a intrat atacatorul nu s-a confirmat; LiteLLM spune că suspectează o vulnerabilitate patch-uită recent.
Ce a găsit atacatorul înăuntru valora mai mult decât instanța în sine: token-uri OAuth de GitHub CLI aparținând a trei ingineri ai companiei, aflate în jurnalele gateway-ului. Explicația LiteLLM despre cum au ajuns acolo merită citită de două ori. În anumite situații, Claude Code include token-ul OAuth de GitHub CLI al utilizatorului în corpul unui răspuns — iar acolo unde un gateway loghează corpurile răspunsurilor, token-ul ajunge logat împreună cu restul. Un gateway de AI care făcea exact ceea ce face un gateway de AI înregistra credențiale la vedere.
Trei token-uri, trei roluri. Un cont a fost folosit pentru a modifica pipeline-ul de release și a declanșa un release, al doilea pentru a-l aproba, iar al treilea pentru a șterge ulterior înregistrările workflow-ului — motiv pentru care imaginea criminalistică e mai săracă decât ar fi trebuit. Build-ul și-a înregistrat repository-ul sursă ca Berri-AI/litellm, la o cratimă distanță de adevăratul BerriAI/litellm.
Release-ul otrăvit, versiunea 1.107.0, a stat pe PyPI între 11:39 și 13:23 UTC pe 21 octombrie. Tag-urile Docker v1.107.0, latest, main-latest și main-stable au servit imaginea compromisă între 11:46 și 14:20 UTC. Ultima versiune sigură este 1.106.2. Clienții care foloseau registry-ul privat enterprise al LiteLLM nu au fost afectați.
Ce a livrat și cât de repede a fost folosit
Codul malițios a fost plasat în fișierele de pornire ale Python — un fișier .pth care rulează ori de câte ori pornește un interpretor Python în acel mediu, indiferent dacă ceva importă vreodată LiteLLM. Aduna credențiale pentru AWS, Azure, Google Cloud, Kubernetes și Docker, plus credențiale Git, chei SSH și GPG, parole și cookie-uri salvate în browser, istoricul de navigare și de shell, fișierele de autentificare ale Codex, Claude, Gemini și Cursor și tot ce putea citi din baza de date a unui proxy LiteLLM. Datele colectate erau criptate și trimise către o adresă „healthcheck" de pe domeniul litellm[.]dev. O a doua componentă interoga periodic un fișier de pe GitHub pentru un domeniu de unde să descarce și să ruleze cod Python suplimentar; când Socket a verificat acel fișier pe 21 octombrie, era gol.
Wiz a observat cheile furate folosite la circa patru ore și jumătate după ce datele au părăsit sistemele victimelor: credențiale AWS luate de pe runnere de CI și noduri Kubernetes, testate pentru acces la modele pe Amazon Bedrock. Socket estimează descărcările săptămânale ale LiteLLM la aproximativ 23 de milioane.
O componentă pentru care n-ai semnat niciun contract
Majoritatea băncilor n-au auzit de LiteLLM și n-au să contracteze niciodată direct cu el. E genul de componentă care stă cu un etaj mai jos: un gateway sau un proxy de AI prin care un furnizor de chatbot, un instrument de scoring al fraudei sau o funcție internă de tip „întreabă-ți datele" rutează apelurile către model, pentru că scrierea acelui strat de rutare de la zero e efort irosit când există deja unul open-source.
Exact acel strat ar trebui să-l atingă registrul de informații DORA — și, de regulă, nu-l atinge. Articolul 28(3) din Regulamentul (UE) 2022/2554 cere ca fiecare aranjament contractual pentru utilizarea de servicii ICT să fie înregistrat, iar șabloanele din Regulamentul de punere în aplicare (UE) 2024/2956 acoperă lanțul de subcontractare de sub orice aranjament care susține o funcție critică sau importantă — șablonul B_05.02 există tocmai pentru a descrie subcontractanții și rangul lor în acel lanț. În practică, lanțul e documentat până la subprocesorul numit — „acest furnizor folosește acest provider de cloud, în această țară" — și se oprește acolo. Rareori întreabă ce componente AI open-source stau sub produsul furnizorului, cine le mentenanță sau cum își gestionează proiectul respectiv propriile credențiale.
Ce ar trebui să poată spune o intrare din registru
Pentru un aranjament legat de AI, un registru care numește doar furnizorul răspunde la întrebarea greșită. Intrările care merită ținute în evidență includ, cel puțin: componenta sau biblioteca AI concretă folosită, nu doar numele produsului furnizorului; dacă e fixată la o versiune exactă, verificată — ideal prin digest — sau urmărește un tag flotant de tip latest, care se actualizează singur; cum impune procesul de release al furnizorului separarea responsabilităților și dacă acea separare rezistă atunci când un singur atacator deține trei conturi de mentenanță; ce anume loghează gateway-ul sau proxy-ul de AI al furnizorului, mai exact dacă sunt înregistrate corpurile cererilor și ale răspunsurilor și cine le poate citi; ce cadență de rotație a credențialelor se aplică infrastructurii de build și de deployment a furnizorului, nu doar propriei tale infrastructuri; și un contact de notificare specific acelei componente, pentru că „sună-ți account managerul" nu e același lucru cu „sună pe cine patch-uiește gateway-ul de AI".
Nimic din toate astea nu e exotic. E disciplina pe care registrul o cere deja pentru subprocesorii de cloud, aplicată încă un nivel mai jos, asupra tooling-ului open-source și AI de care depind la rândul lor acei subprocesori. Un furnizor care nu poate răspunde azi la aceste întrebări îți dă o informație utilă: înseamnă că nimeni nu l-a întrebat nici intern.
Întrebarea despre logare merită o atenție aparte după acest incident, pentru că e cea care se generalizează. Orice gateway aflat pe traseul traficului către model se află, prin construcție, pe traseul a tot ce transportă acel trafic — chei de API lipite în prompturi, token-uri incluse în răspunsurile uneltelor, date de clienți în ambele sensuri. Logarea nu e opțională pentru un sistem operațional, dar o intrare de registru care consemnează „corpurile complete ale răspunsurilor, păstrate 90 de zile, accesibile echipei de suport a furnizorului" e o linie de risc semnificativ diferită de una care consemnează „doar metadate".
Pune-o ca întrebare, nu ca bifă
Cel mai direct mod de a aduce asta în registru e s-o întrebi pe fiecare furnizor legat de AI la reînnoire, în loc să aștepți ca un supervizor s-o întrebe pe tine: ce gateway de AI, strat de orchestrare sau bibliotecă de inferență folosește produsul vostru, cum e fixată versiunea, ce loghează și care e traseul de notificare a incidentelor dacă exact acea dependință e compromisă. Un furnizor cu un răspuns clar e o linie cu risc mai mic în registru. Unul care trebuie să se ducă să afle e o gaură de subcontractare pe care tocmai ai închis-o înainte să devină raport de incident.
Același inventar lucrează și sub NIS 2, unde obligațiile de securitate a lanțului de aprovizionare pentru entitățile esențiale și importante acoperă același teren, dintr-un alt unghi. Practica noastră de audit, risc și conformitate și checklist-ul de pregătire NIS 2 și DORA acoperă partea de documentare; unde întrebarea e dacă un sistem care depinde de AI rezistă efectiv la un atac, acolo intervine testarea de penetrare pentru LLM și AI; iar obiceiurile de igienă a credențialelor și de pipeline de release de mai sus sunt exact ce urmărește să formeze un training de securitate pentru dezvoltatori, înainte ca un furnizor să ajungă lângă o cheie de producție.
Surse: Help Net Security — LiteLLM hit by second supply chain attack this year, Wiz — LiteLLM compromised, steals credentials, Socket — LiteLLM PyPI package and Docker images compromised, Datadog Security Labs — LiteLLM supply chain compromise, Regulamentul (UE) 2022/2554 (DORA), art. 28, Regulamentul de punere în aplicare (UE) 2024/2956. LiteLLM descrie incidentul ca fiind limitat, cu investigația încă deschisă; calea de intrare în instanța internă e declarată explicit neconfirmată, iar folosirea cheilor AWS furate e o observație Wiz, nu o declarație a furnizorului.
Acest articol este informație generală, nu consultanță juridică sau de conformitate.