O cheie master LiteLLM uitată a deschis drumul către o versiune PyPI compromisă

Un singur secret publicat într-un repository public și nerevocat niciodată i-a permis unui atacator să ajungă până în pipeline-ul de release al LiteLLM. Pe 21 octombrie 2026, o versiune malițioasă LiteLLM 1.107.0 a fost publicată pe PyPI, împreună cu imagini Docker Hub și GHCR. A fost pusă în carantină în aproximativ două ore, dar oricine a instalat-o în acest interval ar trebui să considere sistemul compromis.

Ce s-a întâmplat

Lanțul de evenimente a început cu luni în urmă:

27 mai 2026 – Un fișier de configurare încărcat într-un repository public al LiteLLM conținea cheia master a unei instanțe interne a Agent Platform. Commit-ul a fost suprascris rapid (force-push), iar cheile expuse au fost marcate pentru revocare, însă cheia master nu a fost revocată niciodată.
10 octombrie 2026 – Un actor necunoscut a folosit cheia, încă validă, pentru a intra în Agent Platform și a extras un token OAuth GitHub CLI folosit de serviciu pentru a deschide pull request-uri. Tokenul nu avea permisiuni restrânse și aparținea proprietarului organizației GitHub, ceea ce i-a oferit atacatorului acces de nivel owner la toate repository-urile.
10 și 12 octombrie – Atacatorul a trimis commit-uri pe branch-uri temporare (după modelul ci-tmp-<hex>), fiecare adăugând un workflow la .github/workflows/cache.yml, cu mesajul aparent inofensiv „ci: bump cache config”. Workflow-urile rulau la push, iar branch-urile erau șterse după câteva minute, aproape fără urme în istoricul obișnuit. Ele au colectat tokenurile GitHub CLI a doi ingineri cu drepturi de maintainer, plus o listă lungă de alte secrete.
21 octombrie 2026 – Atacatorul a ocolit protecția branch-ului, a redirecționat pipeline-ul de release către un repository care imita numele original (Berri-AI/litellm în loc de BerriAI/litellm), a publicat versiunea 1.107.0 pe PyPI, a urcat imaginile de container și apoi a șters înregistrările rulărilor din producție și staging.
Incidentul a fost semnalat în aceeași zi; PyPI a pus versiunea în carantină, iar tag-urile Docker afectate (v1.107.0, latest, main-latest, main-stable) au fost eliminate sau redirecționate către imagini curate.

În mod normal, un release trebuie pornit de un inginer autorizat și aprobat de un cont special legat de un dispozitiv fizic din birou. Această regulă fusese relaxată cu câteva zile înainte, ca orice doi ingineri să poată porni și aproba un release, pentru a grăbi backport-urile de bugfix. Cu două tokenuri de maintainer furate, atacatorul a putut face ambii pași. De remarcat că, având un token de owner, atacatorul ar fi putut elimina complet restricția; o explicație plauzibilă este că nu a făcut-o pentru a nu atrage atenția.

Ce au furat workflow-urile malițioase

Workflow-urile de CI au fost construite pentru a colecta credențiale, nu cod. Printre secretele vizate: tokenuri GitHub, identificatorul și cheia privată de semnare a unei aplicații GitHub, chei pentru workspace-ul Linear, pentru instanța LiteLLM și Together AI, iar în a doua rulare chei API pentru Anthropic, OpenAI, AWS Bedrock și Tavily, tokenul serviciului de secret scanning folosit de proiect, date de conectare PostgreSQL și Redis, plus o sesiune de browser Playwright serializată pentru Linear. Acest ultim element contează: o sesiune de browser validă permite autentificarea în contul asociat fără parolă și fără MFA. Furtul tokenului de secret scanning i-ar fi putut oferi atacatorului vizibilitate asupra alertelor menite să detecteze exact această activitate, sau chiar control asupra lor.

LiteLLM spune că revocă toate tokenurile asociate sistemelor interne și platformelor furnizorilor. Echipa a recunoscut și că prima ipoteză – că tokenurile GitHub ar fi scăpat din log-urile unei instanțe interne – s-a dovedit greșită.

Ce face pachetul compromis

Versiunea 1.107.0 plasează fișiere de pornire Python (.pth și sitecustomize.py) în afara directorului pachetului LiteLLM. Pentru că Python le încarcă automat, codul malițios rulează la fiecare pornire a interpretorului Python în acel mediu, chiar dacă nicio aplicație nu importă LiteLLM. Mai departe, are două componente:

Stealer de credențiale – colectează credențiale pentru unelte de dezvoltare și AI, secrete cloud, date din browser, chei SSH, tokenuri Git și GitLab, variabile de mediu și tokenuri pentru npm, PyPI, pip, Yarn, Maven, Gradle, Composer, RubyGems și Cargo. Datele sunt criptate (AES-256-CBC, cu cheia protejată prin RSA-OAEP) și trimise prin HTTP POST către litellm[.]dev/healthcheck, un domeniu înșelător înregistrat pe 13 octombrie 2026.
Backdoor pentru Unix – un proces în fundal care verifică aproximativ o dată pe oră dacă are de descărcat și rulat cod trimis de atacator. Capacitatea a fost identificată în cod, dar nu s-a confirmat că execuția de la distanță a avut loc efectiv.

Deoarece fișierele de pornire se află în afara directorului aplicației, simpla dezinstalare sau actualizare a LiteLLM poate lăsa componentele malițioase pe loc.

De ce contează

Incidentul arată cum atacurile asupra lanțului de aprovizionare software se construiesc din slăbiciuni mici și banale: un secret publicat din greșeală, o revocare care nu s-a făcut, un token cu prea multe permisiuni și un control de release relaxat din comoditate. Luate separat, par minore. Împreună, i-au permis atacatorului să livreze cod tuturor celor care au încredere într-un gateway AI popular. Stațiile dezvoltatorilor și runner-ele de CI, care dețin cheile pentru cloud, registrele de pachete și furnizorii AI, sunt adevărata țintă.

Ce trebuie făcut

Verificați dacă folosiți 1.107.0. Căutați în lockfile-uri, medii virtuale, imagini de container și cache-uri CI litellm==1.107.0, precum și imagini descărcate din tag-urile afectate pe 21 octombrie 2026.
Reconstruiți, nu doar actualizați. Pe orice mașină sau imagine afectată, căutați fișiere .pth neașteptate și sitecustomize.py în site-packages. Cea mai sigură variantă este reconstruirea mediului sau a sistemului dintr-o stare cunoscută ca sigură.
Rotiți tot ce putea accesa acel mediu: chei cloud, chei API ale furnizorilor AI, tokenuri GitHub și GitLab, tokenuri pentru registrele de pachete, chei SSH, parole de baze de date și sesiuni de browser. Presupuneți că au fost furate.
Căutați indicatori de compromitere: trafic către litellm[.]dev sau webhook[.]site și dinspre 69.48.229[.]143; procese Python în fundal care rulează orar fără explicație.
Revizuiți igiena propriului pipeline. Limitați tokenurile de CI și de bot la minimul necesar, revocați imediat secretele expuse (rescrierea istoricului git nu revocă nimic), păstrați aprobările de release legate de conturi cu cheie hardware și setați alerte pentru branch-uri de scurtă durată care adaugă sau modifică workflow-uri.

Secretele publicate în repository-uri și workflow-urile de CI cu permisiuni excesive sunt exact ce caută serviciul nostru de code review asistat de AI. Acesta verifică codul sursă, configurațiile și definițiile de pipeline pentru credențiale scrise direct în cod și automatizări riscante, înainte ca acestea să devină primul pas al unui lanț ca acesta.