Vad som hände i LiteLLMs byggpipeline i mars

Intrånget började inte hos LiteLLM själv. TeamPCP komprometterade först säkerhetsskannern med öppen källkod Trivy genom att utnyttja en läckt automatiseringstoken, vilket gav gruppen ett fönster på cirka 20 dagar inne i Trivys eget repository innan någon märkte det. Under den perioden tvångspushade gruppen skadlig kod till Trivys versionstaggar - de specifika utgåvemarkeringar som nedströmsprojekt pekar mot när de hämtar ett beroende.

LiteLLMs kontinuerliga integrationspipeline installerade Trivy utan att låsa den till en fast, verifierad version, så den hämtade automatiskt den förgiftade utgåvan nästa gång pipelinen kördes. Det enda ofastlåsta beroendet var hela öppningen TeamPCP behövde: den skadliga koden följde med in i LiteLLMs egen byggprocess och därifrån in i två publicerade paket, LiteLLM-versionerna 1.82.7 och 1.82.8, uppladdade till Python Package Index.

Skyddet alla litar på, och hur det kringgicks

De flesta utvecklare som oroar sig för skadliga PyPI-paket litar på flaggan --ignore-scripts, som hindrar ett pakets installationsskript från att köra godtycklig kod. TeamPCPs nyttolast behövde inget installationsskript. Den låg gömd i en .pth-fil, en Python-sökvägskonfigurationsfil som tolken själv kör automatiskt vid start, vid varje körning, oavsett hur paketet installerades. Det designvalet är detaljen som varje rubrik om det här intrånget utelämnade, och det är den som betyder mest för varje ingenjörsteam som trodde att --ignore-scripts skyddade dem mot just denna attacktyp.

När den körde samlade nyttolasten in SSH-nycklar, molnuppgifter för AWS, Google Cloud och Azure, Kubernetes-token, innehållet i .env-filer och API-nycklar från AI-leverantörer från varje maskin som hade installerat det förgiftade paketet. De stulna uppgifterna krypterades med AES-256 och skickades antingen till en typosquattingdomän byggd för att likna en legitim LiteLLM- eller Trivy-resurs, eller laddades upp direkt till repositories på offrets eget GitHub-konto - en detalj som lät operationen smälta in i vad som såg ut som normal utvecklaraktivitet i stället för att utlösa ett tydligt larm för utgående trafik.

2 500 företag, åtta namngivna i Europa och ett fem månaders gap

CloudSEK publicerade sin forskning den 11 augusti 2026, fem månader efter komprometterandet i mars, och identifierade fler än 2 500 organisationer och cirka 434 000 CI/CD-pipelines som potentiellt exponerade - vad företaget kallar det största AI-försörjningskedjeintrånget som avslöjats hittills 2026. Bland träffarna med hög tillförlitlighet som CloudSEK namnger finns Siemens AG, Siemens Energy, Deutsche Bahn AG, Orange S.A., Vodafone Group Plc, London Stock Exchange Group, det finska energibolaget Fortum Oyj och återförsäkringsbolaget Munich Re, som spänner över tillverkning, telekom, järnväg, finans och försäkring i flera europeiska jurisdiktioner.

CloudSEK är tydliga med att förekomst i datasetet inte automatiskt bevisar ett lyckat intrång - resultatet betyder att autentiseringsuppgifter, domäner, repositories eller infrastruktur kopplade till organisationen dök upp i den insamlade datan, och varje organisation måste göra en egen utredning för att bekräfta vad som, om något, faktiskt togs eller missbrukades. Det som inte är ifrågasatt är femmånadersgapet mellan marsintrånget och augustioffentliggörandet, ett fönster där var och en av de namngivna organisationerna kan ha kört på infrastruktur med komprometterade autentiseringsuppgifter utan någon offentlig varning om att intrånget hade skett.

Vad detta betyder för alla som driver AI-infrastrukturverktyg

FBI:s FLASH-varning från juli 2026 lägger till en obekväm detalj i tidslinjen: autentiseringsuppgifterna som samlades in i mars betraktas fortfarande som aktiva och användbara månader senare, och myndigheten förväntar sig att TeamPCP eller anslutna aktörer kommer att utnyttja dem i framtida, orelaterade intrång i stället för att låta dem förfalla. För varje organisation som körde LiteLLM-versionerna 1.82.7 eller 1.82.8 i produktion eller CI under mars 2026 är det korrekta svaret inte att vänta på individuell bekräftelse från CloudSEK eller LiteLLM - det är att behandla varje autentiseringsuppgift som rör den byggpipelinen som komprometterad och rotera den nu, fem månader för sent eller inte.

Den strukturella lärdomen sträcker sig bortom LiteLLM. Varje organisation som låter sin CI-pipeline hämta ett säkerhetsverktygsberoende, som en skanner, utan att låsa det till en verifierad version har samma öppning som TeamPCP använde här, och --ignore-scripts är inte det skydd som de flesta team tror att det är mot en nyttolast som levereras via en .pth-fil. Europeiska säkerhetsansvariga som driver AI-infrastrukturverktyg byggda på samma öppen källkod-försörjningskedja bör se detta mindre som en LiteLLM-historia och mer som en försmak av hur nästa AI-verktygskompromettering sannolikt kommer att levereras.

Läs vidare: 141 006 testkörningar, tre äkta intrång  |  Micron: 2027 blir stramare än 2026