Biblioteca ce îți ține toate cheile API a fost compromisă
Pe 24 martie 2026, cineva a publicat pe PyPI versiuni de LiteLLM cu backdoor. Versiunile 1.82.7 și 1.82.8 conțineau un program în mai multe etape care fura credențiale: chei API, chei SSH, credențiale AWS/GCP/Azure, tokenuri Kubernetes, șiruri de conectare la baze de date și portofele de criptomonede. Pachetele malițioase au stat pe PyPI aproximativ 5 ore până să fie puse în carantină.
LiteLLM nu e o bibliotecă obscură. E cel mai popular proxy LLM open-source, cu 95 de milioane de descărcări lunare și integrări în practic orice framework major de agenți AI. Dacă echipa ta rulează în producție orice aplicație bazată pe LLM, sunt șanse mari ca LiteLLM să fie undeva în arborele tău de dependențe.
Atacul nu a fost un typosquat și nici un maintainer care a luat-o razna. Un grup numit TeamPCP a compromis chiar pipeline-ul CI/CD al LiteLLM: întâi a pus un backdoor în scannerul de vulnerabilități Trivy de la Aqua Security, apoi a folosit credențialele furate ca să publice pachete malițioase direct pe PyPI. Scannerul de securitate a fost punctul de intrare.
Cum a funcționat atacul
Lanțul de atac a avut trei etape și fiecare ar trebui să te pună pe gânduri:
Etapa 1: compromiterea uneltei de securitate. Pe 19 martie, TeamPCP a injectat malware de furat credențiale în GitHub Actions și în release-urile oficiale ale Trivy. Trivy e folosit de mii de pipeline-uri CI/CD ca să caute vulnerabilități. Versiunea malițioasă descărca memoria procesului Runner.Worker, căuta tipare {"value":"<secret>","isSecret":true} și trimitea în afară tot ce găsea.
Etapa 2: strângerea secretelor din CI/CD. Fiecare pipeline CI care a rulat acțiunea Trivy compromisă și-a scurs secretele. Pipeline-ul LiteLLM a fost unul dintre ele. Atacatorii au obținut tokenurile de publicare pe PyPI.
Etapa 3: publicarea pachetelor cu backdoor. Cu tokenurile furate, TeamPCP a publicat LiteLLM 1.82.7 și 1.82.8. Versiunea 1.82.8 era deosebit de urâtă: includea un fișier .pth (litellm_init.pth) care se execută automat la pornirea oricărui proces Python, fără niciun import. Era suficient ca pachetul să fie instalat. Fiecare pip install, fiecare pornire a language serverului din IDE, fiecare comandă python -c declanșa programul de furat.
Datele furate erau criptate cu AES-256 și o cheie de sesiune împachetată cu RSA-4096 înainte să fie trimise în afară. Malware de nivel profesionist, țintit pe lanțul de aprovizionare al dezvoltării AI.
Verifică dacă ai fost expus
Dacă oricare dintre punctele de mai jos e adevărat, trebuie să investighezi:
# Check if you installed the affected versions
pip show litellm | grep Version
# Affected: 1.82.7 or 1.82.8
# Check pip install logs for the time window
# Affected window: March 24, 2026, 10:39 UTC to ~16:00 UTC
# Check your lockfile history
git log --oneline -20 -- requirements.txt Pipfile.lock poetry.lock
# Search Docker image layers for the bad versions
docker history your-image:latest | grep litellmDacă ai rulat pip install litellm sau pip install --upgrade litellm pe 24 martie în acel interval, pornește de la ideea că variabilele de mediu, cheile API, credențialele de cloud și cheile SSH au fost scoase în afară. Rotește tot.
Cinci lucruri de făcut chiar acum
Nu sunt bune practici teoretice. Sunt pașii concreți care ar fi prevenit sau ar fi limitat impactul exact al acestui atac.
1. Fixează dependențele cu hash-uri, nu doar cu versiuni.
Fixarea versiunii (litellm==1.82.6) nu te-ar fi salvat aici. Atacatorul a publicat un număr de versiune nou. Fixarea pe hash îl prinde, pentru că hash-ul pachetului legitim diferă de cel cu backdoor.
# requirements.txt with hash pinning
litellm==1.82.6 \
--hash=sha256:abc123...your_known_good_hash_hereRulează pip install --require-hashes -r requirements.txt și pip va refuza să instaleze orice pachet al cărui hash nu se potrivește. E un mod totul-sau-nimic: dacă dai hash pentru un pachet, ai nevoie de hash-uri pentru toate. Folosește pip-compile --generate-hashes din pip-tools ca să automatizezi asta.
2. Fixează acțiunile CI/CD pe SHA-uri de commit, nu pe taguri.
Compromiterea Trivy a mers pentru că pipeline-urile foloseau aquasecurity/trivy-action@latest sau un tag care se poate muta. Tagurile pot fi rescrise cu force-push. SHA-urile de commit nu.
# Bad: mutable tag
- uses: aquasecurity/trivy-action@master
# Good: pinned to immutable commit SHA
- uses: aquasecurity/trivy-action@a7a829a # v0.18.0Dependabot de la GitHub poate actualiza automat SHA-urile fixate când apar release-uri noi, deci nu pierzi comoditatea actualizărilor automate.
3. Izolează tokenurile de publicare pe PyPI.
Tokenul PyPI al LiteLLM era accesibil runnerului CI care rula și Trivy. Dacă tokenul de publicare ar fi stat într-un mediu separat și restricționat, la care Trivy nu ajungea, atacatorul ar fi avut acces la Trivy, dar niciun drum spre PyPI.
În GitHub Actions, folosește secrete la nivel de environment, cu revieweri obligatorii, pentru workflow-ul de publicare. Jobul de scanare de securitate nu ar trebui să aibă niciodată acces la secretele de publicare.
4. Fă un Software Bill of Materials (SBOM) pentru stack-ul AI.
Un AI-BOM merge mai departe decât un SBOM clasic. Acoperă pachetele Python, artefactele de model, proveniența datelor de antrenare și dependențele de inferență. Ghidul NSA/CISA despre riscurile din lanțul de aprovizionare AI/ML, publicat pe 4 martie 2026, spune explicit: trebuie să știi ce e în pipeline-ul tău AI înainte să-l poți apăra.
# Generate SBOM with syft (not Trivy, for obvious reasons right now)
syft dir:/path/to/your/ml-project -o spdx-json > ai-sbom.json5. Monitorizează apelurile de rețea neașteptate din mediul de ML.
Programul de furat din LiteLLM trimitea datele pe un server extern. Dacă mediul tău de antrenare sau de inferență face apeluri HTTP spre domenii care nu sunt pe lista ta permisă, e un semnal. Segmentarea rețelei pentru sarcinile de ML nu mai e paranoia. E igienă de bază.
Problema mai mare despre care nu vrea nimeni să vorbească
O cercetare Mitiga pe 10.000 de proiecte ML open-source a arătat că 68,4% folosesc GitHub Actions de la terți nefixate, ceea ce le face ținte sigure pentru exact acest tip de atac. Ecosistemul AI/ML a importat toate obiceiurile proaste din dezvoltarea software clasică și a pus peste ele suprafețe de atac noi: fișiere de model care execută cod arbitrar la încărcare, date de antrenare care pot fi otrăvite și pipeline-uri de inferență care rulează cu acces la baze de date de producție.
Campania TeamPCP nu s-a oprit la Trivy și LiteLLM. Patru zile mai târziu, grupul a compromis și GitHub Action-ul Checkmarx, cu aceeași tehnică. Uneltele de securitate folosite ca vector de atac nu sunt un caz izolat. Sunt un tipar.
Unde e probabil vulnerabil pipeline-ul tău de ML
Dacă rulezi sarcini de ML în producție, iată o autoevaluare rapidă:
- Fișierele de requirements folosesc fixare pe hash? (Cele mai multe nu.)
- GitHub Actions sunt fixate pe SHA-uri? (Cele mai multe nu sunt.)
- Scannerul de securitate din CI are acces la tokenurile de publicare? (Probabil are.)
- Știi fiecare pachet Python din containerul de inferență? (Probabil nu.)
- Mediul de ML are controale pe traficul de ieșire? (Aproape sigur nu are.)
Dacă ai răspuns „nu" la trei sau mai multe, pipeline-ul tău de ML are aceeași expunere pe care o aveau maintainerii LiteLLM înainte de 24 martie.
Lanțul de aprovizionare AI nu e o problemă de viitor. A fost exploatat săptămâna asta, prin singura bibliotecă ce stă între aplicația ta și fiecare API de LLM pe care îl apelezi. Soluția nu e să mai cumperi o unealtă. E să aplici disciplina de gestionare a dependențelor pe care ecosistemul ML a tot sărit-o ani la rând.
Despre DeviDevs: construim platforme de ML și sisteme AI securizate și ajutăm firmele să se conformeze cu EU AI Act. devidevs.com