Pe 21 octombrie 2026, pipeline-ul de release al proiectului LiteLLM a fost compromis, iar versiunea 1.107.0 a fost publicată pe PyPI și în registrele Docker cu un payload care fură credențiale, secrete și variabile de mediu. Toate cele șapte wheels pentru Windows, Linux și macOS au fost afectate. Fereastra de expunere pe PyPI: 11:39:51 până la 13:23 UTC. Sursa: BleepingComputer.

Ce s-a întâmplat de fapt

LiteLLM este un SDK Python open-source și un AI gateway care permite aplicațiilor să acceseze modele de la mai mulți furnizori printr-un API comun. Proiectul are 61.800 de stele pe GitHub și 92 de milioane de descărcări lunare pe PyPI, iar printre utilizatori se numără NVIDIA, Netflix, AT&T și Okta. Cu alte cuvinte, nu vorbim despre un pachet de nișă, ci despre infrastructură prin care trec chei de acces la modele AI și, implicit, facturi și date de business.

Conform maintainer-ului, pipeline-ul de release a fost spart pe 21 octombrie, iar atacatorul a împins versiunea 1.107.0 atât în Docker registry, cât și pe PyPI. Versiunea conținea malware compilat care fură credențiale și încarcă unelte de execuție de cod la distanță. Clienții care rulează ediția enterprise privată nu au fost afectați, potrivit aceleiași surse.

Artefactele compromise, așa cum apar în post-mortem-ul citat de BleepingComputer:

Companiile de securitate aplicațională au detectat atacul în șase minute de la publicare. Atacatorul nu a modificat codul aplicației LiteLLM, ci doar pachetul de instalare, unde a plasat trei fișiere: cook.pth, cook.py și sitecustomize.py, în directorul de librării Python al mediului.

Mecanismul este elegant și, tocmai de asta, periculos. La startup, Python procesează liniile executabile din fișierele .pth și încearcă apoi să importe sitecustomize. Payload-ul rulează înaintea aplicației, de fiecare dată când pornește Python în acel mediu. Mai rău: chiar dacă rulezi Python sau pip ca să investighezi o instalare suspectă, declanșezi malware-ul. Unul dintre fișiere lansează un loader detașat care verifică la fiecare oră un pointer găzduit pe GitHub și descarcă Python de pe un server extern pentru execuție pe host.

Ce urmărește payload-ul:

Datele furate sunt criptate cu AES-256-CBC, cheia este criptată cu RSA-4096, iar exfiltrarea merge către litellm[.]dev/healthcheck.

Pachetele malicious au fost retrase. Dar retragerea nu înseamnă curățare pe mașinile unde instalarea a avut loc deja.

De ce un pachet de AI gateway e o țintă mai bună decât un site

Există o intuiție greșită în piață: atacurile de supply chain lovesc mai ales librării de infrastructură generică. În realitate, un AI gateway este mai valoros pentru un atacator decât un site de prezentare, pentru că prin el trec exact lucrurile care contează: chei API pentru modele, configurări de furnizori, credențiale de cloud, conexiuni la baze de date vectoriale.

Cine obține o cheie de la un provider AI nu obține doar acces. Obține capacitate facturabilă pe banii altcuiva, acces la prompturi și la datele care trec prin ele, plus o poziție din care poate escalada. Iar dacă aceeași mașină are și secrete CI/CD, atacatorul poate împinge cod în alte pipeline-uri. Exact ce s-a întâmplat în martie 2026, când gruparea TeamPCP a publicat versiuni malicious LiteLLM pe PyPI după ce a spart scanner-ul Trivy folosit în CI/CD-ul proiectului. A doua breșă în același an nu e ghinion, e un semnal despre suprafața de atac a lanțului de release.

Aici e și lecția mai largă pentru orice echipă care rulează servicii AI în producție: modelul de amenințare nu mai e "cine-mi sparge aplicația", ci "cine-mi otrăvește dependența". Iar dependențele din stack-ul AI se mișcă repede, se instalează automat și, de multe ori, rulează cu permisiuni largi.

Ce faci concret dacă folosești LiteLLM

Ordinea pașilor contează, pentru că unele acțiuni declanșează malware-ul.

  1. Nu porni Python în mediul afectat. Nu rula python, pip list, pip show sau scripturi de verificare în directorul respectiv. Investighează sistemul de fișiere din exterior, cu unelte care nu execută cod Python.
  2. Oprește deployment-urile afectate. Containerele oprite nu mai execută loader-ul la startup, dar nu elimină un loader deja activ.
  3. Izolează sistemele infectate și reconstruiește-le din backup-uri curate. Nu încerca să cureți manual un mediu în care s-a executat payload-ul.
  4. Rotește toate secretele expuse. AWS, Azure, GCP, Kubernetes, Docker, chei Git/GitHub/npm/PyPI, CI/CD, chei SSH, GPG, TLS, token-uri de provider AI, cookie-uri de sesiune. Dacă un secret a stat pe mașina respectivă, se consideră compromis.
  5. Revino la LiteLLM 1.106.2, ultima versiune curată înainte de atac, conform recomandării proiectului.
  6. Șterge doar directorul pachetului? Nu e suficient. Pot rămâne fișiere de startup sau un loader activ, avertizează maintainer-ul.

Un detaliu care merită subliniat: ștergerea directorului LiteLLM nu garantează curățarea. Fișierele .pth și sitecustomize.py sunt plasate în directorul de librării Python al mediului, nu neapărat în folderul pachetului. Cine doar face pip uninstall și respiră ușurat poate lăsa în urmă exact mecanismul de persistență.

Ce înseamnă pentru tine, antreprenor sau marketer în România

Probabil nu scrii cod LiteLLM. Dar dacă ai un site pe Shopify, un magazin online, o echipă care construiește automatizări cu AI sau un contractor care ți-a legat CRM-ul la un model prin API, ești în lanțul de risc.

Scenariul tipic: un developer din echipă instalează LiteLLM ca să facă un gateway între aplicația ta și modelele AI. În aceeași mașină stau cheile de la AWS unde e hostată aplicația, token-ul de la furnizorul de email, credențialele de la platforma de analytics și .env-ul cu tot ce trebuie. Dacă instalarea a picat în fereastra de două ore, atacatorul are tot pachetul.

Ce înseamnă practic pentru businessul tău:

Recomandarea mea, explicită și separată de faptele din sursă: tratează orice dependență care atinge credențiale ca pe un furnizor critic. Nu ca pe un pip install rezolvat în două minute. Cere inventarul dependențelor care rulează cu acces la secrete, cere rotația programată a cheilor și cere dovada că pipeline-ul de release are semnătură și verificare de integritate. Dacă furnizorul tău tehnic nu poate răspunde la aceste trei întrebări, ai o problemă mai mare decât un pachet compromise.

Pentru echipele care lucrează cu date și automatizări, disciplina de igienă a accesului contează mai mult decât orice dashboard. Merită citit și materialul despre cum arată o breșă de date confirmată și ce se întâmplă după: diferența dintre "am fost atins" și "am fost expus" se vede în viteza cu care rotești secretele.

Ce verifici în următoarele 48 de ore

Nu e nevoie de panică, e nevoie de ordine. Lista de verificare pe care o propun, ca recomandare a noastră și nu ca fapt din sursă:

O verificare incompletă nu dovedește absența problemei. Dacă nu poți confirma că un mediu e curat, tratează-l ca suspect.

FAQ

Am instalat LiteLLM 1.107.0 acum o săptămână. Sunt compromis? Dacă instalarea s-a făcut în afara ferestrei 11:39:51 - 13:23 UTC din 21 octombrie, pachetul respectiv nu a fost cel malicious. Dacă nu poți confirma ora, tratează mediul ca suspect: nu rula Python în el, izolează-l și rotește secretele.

Trebuie să reinstalez tot sau ajunge să dau uninstall la pachet? Nu ajunge. Fișierele .pth și sitecustomize.py pot rămâne în directorul de librării Python și pot reactiva loader-ul. Reconstruiește mediul din backup curat și revino la versiunea 1.106.2.

Ce rotește primul? Cheile de cloud și CI/CD, apoi token-urile de provider AI, apoi cheile SSH și cele din .env. Ordinea reflectă impactul: un acces la cloud permite escaladare, un token AI permite cost direct pe contul tău.

Concluzia ALLSoft

AI-ul te ajută să analizezi rapid un incident ca acesta: să extragi artefactele afectate, să compari versiunile, să construiești lista de secrete expuse. Dar decizia de a opri un deployment, de a izola un mediu și de a rota chei rămâne umană. Un media buyer sau un ops lead care înțelege că o cheie API e o cheie de la casa, nu un string într-un fișier, face diferența dintre o securizare la timp și o lună de incidente.

Pasul concret îl face ALLSoft Agency: analizăm împreună unde stau credențialele în stack-ul tău de marketing și AI, ce dependențe le ating și ce ordine de rotație are sens. Fără hype, fără promisiuni de invulnerabilitate. Doar verificare, prioritate și execuție.