CloudSEK kopplar mars LiteLLM supply chain-brott till 2 500 organisationer

Säkerhetsföretaget CloudSEK meddelade i en rapport publicerad den 11 augusti 2026 att de har identifierat över 2 500 organisationer som potentiellt exponerats av supply chain-kompromiss av LiteLLM i mars 2026, den öppna källkodsporten som utvecklare använder för att dirigera förfrågningar över AI-modeller, och rekonstruerat cirka 434 000 CI/CD-pipelines som berördes av exponeringen.

Siffrorna kommer från en CloudSEK-forskningsrapport byggd på en offerdataset som företaget säger att dess säkerhetsteam erhöll som täcker marskampanjen. CloudSEKs dataset innehåller högkonfidensmatcher kopplade till företagsdomäner, repositorier, autentiseringsuppgifter eller infrastruktur som tillhör organisationer, inklusive NVIDIA, Samsung Electronics, Cisco Systems, Siemens, S&P Global, ServiceNow, Deloitte, Vodafone, X Corp, Zscaler, FedEx, Volkswagen, Thales och London Stock Exchange Group. Företaget är tydligt med vad matchningarna betyder: hög konfidens beskriver styrkan i bevisen som kopplar exponerad information till en organisation, inte bevis för att organisationen blev inträngd eller att en angripare använde det som togs.

Incidenten i centrum av forskningen började den 24 mars 2026, när en grupp som spårats som TeamPCP publicerade skadliga LiteLLM-versioner 1.82.7 och 1.82.8 till Python Package Index. De bakdörrsreleaserade versionerna var aktiva i cirka 40 minuter innan de togs bort. Det fönstret var tillräckligt: CI/CD-pipelines installerar beroenden automatiskt och kör ofta med breda behörigheter, så en förgiftad paket sprids genom företagsbyggsystem på maskinvaruhastighet utan att någon utvecklare granskar det.

Hur en läckt token nådde 434 000 pipelines

LiteLLM attackerades aldrig direkt. Kedjan som dokumenteras i CloudSEKs rapport börjar ett steg uppströms, med Trivy, en bred använt öppen källkodssäkerhetsscanner. En läckt automatiseringstoken associerad med scannern roterades men inte fullständigt återkallad, vilket lämnade ett fönster på cirka 20 dagar under vilket angriparna tvingade fram skadlig kod över scannerns publicerade versionstag. Eftersom LiteLLMs eget byggpipeline installerade Trivy utan att fästa den från systempaketmanagern, flödade den komprometterade scannern rakt in i bygget, och den förgiftade byggnaden producerade och publicerade de skadliga versionerna 1.82.7 och 1.82.8 till PyPI. En oåterkallad token, tre verktyg djupt.

Payload-designen gjorde att det korta fönstret räknades. Version 1.82.8 släppte en skadlig .pth-fil i Python-miljön, och .pth-filer körs varje gång Python-tolken startar, oavsett om LiteLLM någonsin importeras. Det kringgår installations skydd för skript helt. På komprometterade körare, steg credential-tjuven som FBI kallar SANDCLOCK till rot och svepte SSH-nycklar, AWS-, Google Cloud- och Azure-autentiseringsuppgifter, Kubernetes-tjänstekontotoken, miljöfiler och CI/CD-hemligheter, skrapade värden från processminne som verktyg vanligtvis försöker maskera. Molnycklar kom direkt från instansmetadatatjänsten, med åtkomst som köraren redan hade snarare än någon exploit. För AI-byggnader specifikt, inkluderade bytet LLM API-nycklar och gatewaykonfiguration: autentiseringsuppgifterna för en organisations hela AI-stack.

Stulen data krypterades under en hårdkodad nyckel och exfiltrerades till en typosquattad domän. Där exfiltreringen misslyckades, skapade malware en offentlig repositorium inuti offrets eget GitHub-konto och laddade upp den stulna materialet där som en release-tillgång, vilket innebar att vissa organisationer publicerade sina egna hemligheter i öppen vy.

Varför risken överlevde paketet

Att ta bort de skadliga releaserna från PyPI stängde inte incidenten. Varje autentiseringsuppgift som kopierades medan det förgiftade paketet var aktiv förblir giltig tills ägaren roterar eller återkallar den, och paketets borttagning gör ingenting på egen hand. FBI gjorde samma poäng i en FLASH-advisory den 2 juli 2026 om TeamPCP, varnade för att organisationer som drabbats av kampanjen bör behandla exfiltrerad data och autentiseringsuppgifter som en varaktig risk eftersom associerade aktörer sannolikt kommer att använda dem länge efter den initiala intrången.

Advisorn bekräftar kampanjens omfattning bortom LiteLLM: TeamPCP trojaniserade Trivy, Checkmarx KICS-scanner, LiteLLM och Telnyx Python SDK, verktyg som är inbäddade i företagspipelines, molninfrastruktur och säkerhetsflöden, och parade intrång med utpressning, publicerade offrens namn på en offentlig läckplats och hotade att avslöja stulen data.

FBI:s rekommenderade åtgärder överlappar nästan exakt med vad LiteLLM-kedjan exploaterade: fäst GitHub Actions till verifierade commit-hasher snarare än flytande versionstag, rotera varje CI/CD-hemlighet och publicerings-token som var tillgänglig under exponeringsfönstret, tillämpa minst-privilegierad omfattning på tjänstekonton och registertoken, och sök efter GitHub-organisationer efter repositorier med namn tpcp-docs eller docs-tpcp, som malware skapar med stulen autentiseringsuppgift.

Vad konfidensetiketterna betyder

CloudSEK sorterar organisationerna i sin dataset efter bevisstyrka. En högkonfidensmatch vilar på identifierbara företagsdomäner, repositorier, autentiseringsuppgifter eller infrastruktur; en medelkonfidensmatch bär trovärdiga men svagare indikatorer. Inga etiketter är bevis för en lyckad attack, och företaget betonar att dataset är rekonstruerad exponering: att den visas i det innebär att information som är associerad med organisationen identifierades och bör undersökas, inte att en intrång är bekräftad.

Viss försiktighet med skala är berättigad. 2 500-organisationen och 434 000-pipeline-siffrorna kommer från en dataset som CloudSEK erhöll via sina underrättelskanaler och rekonstruerade, och företaget säljer exponeringsövervakningsplattformen AIVigil som denna forskning pekar mot. Inget av det undergräver kampanjen under: LiteLLM-kompromissen, dess plats i den bredare TeamPCP-operationen och autentiseringsuppgiftsklasser som riskerar att bekräftas av FBI:s råd och av incidentrekordet från mars.

CloudSEK har publicerat en kostnadsfri exponeringskontroll där organisationer kan se om deras infrastruktur visas i dataset. Deras vägledning för varje match är att behandla varje autentiseringsuppgift som den påverkade processen kunde läsa som potentiellt exponerad tills den valideras, granska åtkomstloggar över moln, källkontroll, registret och klustersystem, och rotera brett snarare än bara LiteLLM eller modell-leverantör nyckel. För organisationer som körde de påverkade versionerna i mars har rotationsbeslutet en fem månader gammal klocka som redan körs på det.