LiteLLM 1.107.0 compromisă: infostealer și RAT pe PyPI și Docker
Versiunea 1.107.0 a LiteLLM de pe PyPI și Docker conținea un infostealer și un backdoor care pornesc cu Python: cum s-a întâmplat, indicatori și ce faci.

Pe 21 octombrie 2026, pipeline-ul de lansare al LiteLLM, gateway-ul open source al BerriAI care oferă o interfață unică spre OpenAI, Anthropic, Google Gemini și alți furnizori de modele, a publicat o versiune malițioasă: 1.107.0, pe PyPI, Docker Hub și GHCR. Conținea un infostealer pentru credențiale cloud, de dezvoltare și ale serviciilor de IA, plus un troian de acces la distanță (RAT). Este al doilea atac asupra lanțului de aprovizionare al proiectului anul acesta, după cel din martie legat de scannerul Trivy folosit în CI/CD-ul său.
Ce s-a întâmplat
Conform raportului LiteLLM, atacatorul a folosit token-urile OAuth ale GitHub CLI a trei dezvoltatori: un cont a modificat pipeline-ul și a pornit lansarea, al doilea a aprobat-o, al treilea a șters înregistrările workflow-ului. Conform SecurityWeek, atacatorul a dezactivat și protecțiile ramurilor și a direcționat lansarea spre depozitul Berri-AI/litellm, la o cratimă distanță de cel legitim, BerriAI/litellm. Workflow-ul a semnat și publicat apoi artefactele otrăvite: imaginile semnate introduse după martie nu au fost suficiente.
Compania crede că token-urile au fost luate din jurnalele unei instalări interne LiteLLM expuse pe internet, în care a apărut un cont de utilizator neașteptat, cu un nume inofensiv. A observat cazuri specifice în care Claude Code include token-ul GitHub CLI în corpul unui răspuns: dacă se înregistrează corpurile răspunsurilor, token-ul ajunge în jurnale. Cum a intrat atacatorul nu este confirmat; LiteLLM suspectează o vulnerabilitate corectată recent. Un articol The Hacker News din 24 octombrie indică în titlu o master key LiteLLM scursă: nu am putut citi textul.
Ferestrele de expunere din raport, preluate de BleepingComputer:
- PyPI:
litellm==1.107.0, toate cele șapte wheel-uri pentru Windows, Linux și macOS, între 11:39 și 13:23 UTC; - Docker Hub: tag-urile
v1.107.0,latest,main-latestșimain-stableîntre 11:46 și 14:20 UTC, spre indexulsha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e; - GHCR: aceleași tag-uri până la 13:51 UTC, inclusiv pentru variantele
litellm-databaseșilitellm-non_root.
SecurityWeek, singura dintre surse, estimează peste 49.000 de descărcări. Ultima versiune curată este 1.106.2; clienții registrului privat enterprise nu sunt afectați.
Detalii tehnice
Codul aplicației nu a fost atins: pachetul adăuga trei fișiere în rădăcina site-packages.
cook.pth: liniile executabile din fișierele.pthsunt procesate la fiecare pornire a interpretorului, iar aceasta lanseazăcook.py, infostealer-ul;sitecustomize.py: importat și el la pornire, lansează un loader separat care în fiecare oră citește un pointer găzduit pe GitHub (dead drop), apoi descarcă și execută cod Python.
Prin urmare, malware-ul pornește la fiecare lansare a Python în mediu, chiar dacă aplicația nu folosește LiteLLM, și chiar când rulezi python sau pip pentru investigație.
Conform Wiz, infostealer-ul are 16 module. Colectează credențiale AWS (~/.aws/, variabile de mediu, metadate EC2/ECS), Google Cloud, Azure, Kubernetes și Docker; secrete Git, GitHub, npm, PyPI și CI/CD, fișiere .env, chei SSH și GPG, istoricul shell-ului; chei API OpenAI, Anthropic și ale altor furnizori, fișiere de autentificare Codex, Claude, Gemini și Cursor; parole, cookie-uri și istoricul browserelor. Caută și credențialele furnizorilor salvate în baza de date a proxy-ului LiteLLM: conform cercetătorilor, asta arată intenția, nu un succes dovedit. Datele, criptate cu AES-256-CBC și cu cheia protejată prin RSA-4096, sunt trimise printr-un POST HTTP spre www.litellm[.]dev/healthcheck.
Indicatori publici: conform Aikido, /tmp/.pc_once_* (exfiltrarea a avut loc) și /tmp/remote_code_loader.lock (loader-ul a rulat sau este activ); apoi domeniul litellm[.]dev, depozitul Berri-AI/litellm și digest-ul imaginii indicat mai sus.
Folosirea credențialelor: Wiz a observat atacatorul, la circa patru ore și jumătate după exfiltrare, validând chei AWS luate de pe runner-e CI și noduri Kubernetes și testând accesul la modelele Amazon Bedrock (LLMjacking); în câteva medii a enumerat apoi roluri, utilizatori și chei IAM.
În lectura noastră, tehnicile MITRE ATT&CK relevante sunt T1195.002 (Compromise Software Supply Chain), T1546.018 (Python Startup Hooks), T1552 (Unsecured Credentials) și T1102.001 (Dead Drop Resolver).
Impactul pentru companiile europene și italiene
Un gateway de IA concentrează cheile mai multor furnizori și rulează adesea cu identități cloud și acces la baze de date: paguba poate merge mult dincolo de cheile API. Sunt expuse și stațiile de dezvoltare și runner-ele CI care au instalat biblioteca drept dependență. Două lecții generale: o semnătură validă spune că artefactul nu s-a schimbat după semnare, nu că era sigur; iar jurnalele unui gateway de IA pot aduna secrete.
Pentru entitățile NIS2, securitatea lanțului de aprovizionare este o măsură obligatorie: rularea versiunii 1.107.0 pe sisteme cu acces la infrastructură trebuie evaluată ca posibil incident de notificat, în funcție de accesul obținut. Dacă baza de date a proxy-ului păstra jurnale cu date personale, trebuie evaluată și notificarea prevăzută de GDPR.
Ce faci acum
- Identifică mediile, stațiile și runner-ele cu 1.107.0 și imaginile descărcate în fereastră cu tag-urile
latest,main-latestsaumain-stable: lockfile-uri, registre de pachete, digest-uri. - Nu porni Python sau pip pe sistemele suspecte: caută din exterior
cook.pth,cook.py,sitecustomize.pyși fișierele din/tmp, iar în jurnalele de rețea domeniullitellm[.]dev. Lipsa indicatorilor nu dovedește că mediul este curat. - Izolează și reconstruiește din imagini de încredere, păstrând dovezile: eliminarea doar a pachetului poate lăsa active fișierele de pornire și loader-ul. Fixează 1.106.2 prin hash sau digest, nu prin tag.
- Rotește toate secretele accesibile: cloud, furnizori de IA (inclusiv cei salvați în proxy), Kubernetes, CI/CD, Git și registre, chei SSH; închide sesiunile browserelor de pe stațiile afectate.
- Caută folosirea credențialelor începând cu 21 octombrie: apeluri către Bedrock, enumerare IAM, chei noi, consum anormal de token-uri ale modelelor.
- Întărește pipeline-ul: aprobare independentă a modificărilor workflow-urilor de lansare, fără corpuri de răspuns în jurnalele gateway-ului, interfețe de administrare neexpuse pe internet.
Cum ajută ARXDOME
ARX Sentry colectează cu agentul său inventarul de software și procese al calculatoarelor și serverelor Windows, Linux și macOS și verifică integritatea fișierelor în folderele stabilite: te ajută să găsești mașinile pe care rulează LiteLLM și să observi fișiere noi unde nu ar trebui să fie. Dacă o mașină este suspectă, ARX Shield îți permite să o izolezi de rețea până la reconstruire.
Ultima actualizare:


