Hvad der skete i LiteLLMs build-pipeline i marts

Indbruddet startede ikke hos LiteLLM selv. TeamPCP kompromitterede først open source-sikkerhedsscanneren Trivy ved at udnytte et lækket automatiseringstoken, hvilket gav gruppen et vindue på omkring 20 dage inde i Trivys eget repository, før nogen opdagede det. I den periode tvangspushede gruppen ondsindet kode ind i Trivys versionstags - de specifikke udgivelsesmærker, som downstream-projekter peger på, når de henter en afhængighed.

LiteLLMs continuous integration-pipeline installerede Trivy uden at fastlåse den til en bestemt, verificeret version, så den automatisk hentede den forgiftede udgivelse, næste gang pipelinen kørte. Denne ene ufastlåste afhængighed var hele åbningen, TeamPCP havde brug for: den ondsindede kode fulgte med ind i LiteLLMs eget build-proces og derfra ind i to udgivne pakker, LiteLLM version 1.82.7 og 1.82.8, uploadet til Python Package Index.

Forsvaret alle stoler på, og hvordan det blev omgået

De fleste udviklere, der bekymrer sig om ondsindede PyPI-pakker, stoler på flaget --ignore-scripts, som forhindrer, at en pakkes installationsscripts kører vilkårlig kode. TeamPCPs payload havde ikke brug for et installationsscript. Den var gemt i en .pth-fil, en Python-stikonfigurationsfil, som fortolkeren selv kører automatisk ved opstart, hver gang, uanset hvordan pakken blev installeret. Det designvalg er den detalje, alle overskrifter om dette brud udelod, og det er den, der betyder mest for ethvert udviklingsteam, som troede, --ignore-scripts beskyttede dem mod netop denne angrebstype.

Når den kørte, indsamlede payloaden SSH-nøgler, cloud-legitimationsoplysninger til AWS, Google Cloud og Azure, Kubernetes-tokens, indholdet af .env-filer og API-nøgler fra AI-udbydere fra enhver maskine, der havde installeret den forgiftede pakke. De stjålne data blev krypteret med AES-256 og sendt enten til et typosquatting-domæne bygget til at ligne en legitim LiteLLM- eller Trivy-ressource, eller uploadet direkte til repositories på offerets eget GitHub-konto - en detalje, der lod operationen blande sig med normalt udseende udvikleraktivitet i stedet for at udløse en åbenlys advarsel om udgående trafik.

2.500 virksomheder, otte navngivet i Europa og et hul på fem måneder

CloudSEK offentliggjorde sin forskning den 11. august 2026, fem måneder efter martskompromitteringen, og identificerede mere end 2.500 organisationer og cirka 434.000 CI/CD-pipelines som potentielt eksponerede - hvad firmaet kalder det største AI-forsyningskædebrud, der er afdækket i 2026 indtil videre. Blandt de resultater med høj sikkerhed, som CloudSEK navngiver, er Siemens AG, Siemens Energy, Deutsche Bahn AG, Orange S.A., Vodafone Group Plc, London Stock Exchange Group, det finske energiselskab Fortum Oyj og genforsikringsselskabet Munich Re, som spænder over fremstilling, telekommunikation, jernbane, finans og forsikring i flere europæiske jurisdiktioner.

CloudSEK gør det eksplicit klart, at det at optræde i datasættet ikke automatisk beviser et vellykket brud - resultatet betyder, at legitimationsoplysninger, domæner, repositories eller infrastruktur knyttet til den organisation dukkede op i de indsamlede data, og hver organisation skal selv undersøge, hvad der, om noget, faktisk blev taget eller misbrugt. Det, der ikke er tvivl om, er hullet på fem måneder mellem martsindbruddet og augustoffentliggørelsen, et vindue, hvor enhver af de navngivne organisationer kunne have kørt på infrastruktur med kompromitterede legitimationsoplysninger uden nogen offentlig advarsel om, at kompromitteringen havde fundet sted.

Hvad det betyder for alle, der driver AI-infrastrukturværktøjer

FBI's FLASH-advarsel fra juli 2026 tilføjer en ubehagelig detalje til tidslinjen: de legitimationsoplysninger, der blev indsamlet i marts, betragtes stadig som aktive og brugbare måneder senere, og myndigheden forventer, at TeamPCP eller tilknyttede aktører vil våbenmæssigt udnytte dem i fremtidige, urelaterede indtrængninger i stedet for at lade dem udløbe. For enhver organisation, der kørte LiteLLM version 1.82.7 eller 1.82.8 i produktion eller CI i marts 2026, er det korrekte svar ikke at vente på individuel bekræftelse fra CloudSEK eller LiteLLM - det er at behandle enhver legitimationsoplysning, der har rørt ved den build-pipeline, som kompromitteret og rotere den nu, uanset om det er fem måneder for sent eller ej.

Den strukturelle lære rækker ud over LiteLLM. Enhver organisation, der lader sin CI-pipeline hente en sikkerhedsværktøjsafhængighed, som en scanner, uden at fastlåse den til en verificeret version, har den samme åbning, TeamPCP brugte her, og --ignore-scripts er ikke den beskyttelse, de fleste teams tror, det er, mod en payload leveret via en .pth-fil. Europæiske sikkerhedsansvarlige, der driver AI-infrastrukturværktøjer bygget på den samme open source-forsyningskæde, bør betragte dette mindre som en LiteLLM-historie og mere som en forsmag på, hvordan det næste AI-værktøjskompromis mest sandsynligt vil blive leveret.