LiteLLM på PyPI rammet av TeamPCP: dykk dypt inn i kampanjen mot skadelig programvare som stjeler legitimasjon

Home » Python » LiteLLM på PyPI rammet av TeamPCP: dykk dypt inn i kampanjen mot skadelig programvare som stjeler legitimasjon

I noen timer den 24. mars 2026 forvandlet en enormt populær Python-pakke seg stille til en mektig legitimasjonstyv. To forgiftede utgivelser av LiteLLM, et bibliotek som er mye brukt som en enhetlig grensesnitt til store språkmodeller (LLM-er), ble lastet opp til PyPI, noe som kortvarig eksponerte et enormt antall systemer for et sofistikert forsyningskjedeangrep.

De ondsinnede versjonene, 1.82.7 og 1.82.8, samlet en flertrinns nyttelast som kan suge hemmeligheter fra utviklermaskiner, CI/CD-kjørere, skyinfrastruktur og Kubernetes-klynger, og deretter eksfiltrere dem til angriperkontrollerte servere. Kampanjen har vært knyttet til trusselgruppen TeamPCP, som har vært på en månedslang sprell med å bruke Trivy, Checkmarx-verktøy, Docker-bilder, angrep på npm-forsyningskjeden og nå PyPI-økosystemet.

Hva er LiteLLM, og hvorfor var det et så viktig mål?

LiteLLM er en åpen kildekode Python-bibliotek og proxy-server som fungerer som en slags universell adapter for LLM API-er. Den lar applikasjoner kommunisere med over hundre forskjellige modeller – fra leverandører som OpenAI, Anthropic, Google, AWS Bedrock, Vertex AI og andre – gjennom et enkelt API i OpenAI-stil.

På grunn av denne rollen har prosjektet blitt dypt forankret i AI-økosystemet. Rapporter fra flere sikkerhetsleverandører indikerer at LiteLLM ser omtrent 3–3.4 millioner nedlastinger per dag, med noe telemetri som tyder på at den er tilstede i omtrent 36 % av overvåkede skymiljøerFor angripere representerer det å kompromittere en pakke med det fotavtrykket en sjelden sjanse til å få tilgang til en enorm strøm av sensitive data og legitimasjon med ett trekk.

LiteLLM ligger ofte rett mellom applikasjoner og flere leverandører av AI-tjenester. Den posisjonen betyr at den rutinemessig håndterer API-nøkler, miljøvariabler, konfigurasjonsfiler og andre hemmeligheter som kreves for å nå eksterne LLM-endepunkter. En bakdør i en slik avhengighet kan stille fange opp og eksfiltrere disse verdiene uten å kreve et direkte brudd på selve oppstrømsplattformene.

Hendelsen understreker også hvor sammenfiltret moderne utvikling er: lokale arbeidsstasjoner, CI/CD-pipelines, Kubernetes-klynger og skykontoer er alle knyttet sammen via delte hemmeligheter og automatisering. En enkelt kompromittert avhengighet i den grafen kan ende opp med å eksponere legitimasjon på tvers av mange lag i en organisasjons stabel, noe som forsterker virkningen langt utover én enkelt vert.

Hvordan de ondsinnede LiteLLM-versjonene ble introdusert

De forgiftede utgivelsene LiteLLM 1.82.7 og 1.82.8 ble sendt til PyPI om morgenen 24. mars 2026, rundt 08:30 UTCDe forble tilgjengelige i nesten to timer før de ble satt i karantene av PyPI-sikkerhetsteamet og blokkert av tredjepartsforsvar, med fjerning rapportert rundt 11:25 UTC.

Det som gjør denne saken bemerkelsesverdig er at bakdøren dukket ikke opp i den tilsvarende GitHub-kildekodenEndor Labs og andre forskere fant ut at den ondsinnede logikken ble injisert i det innebygde hjulet distribuert på PyPI, ikke i det offentlige depotet, noe som tyder på at kompromitteringen skjedde under eller etter bygge-/publiseringsprosessen i stedet for via en synlig kode-commit.

Spesielt observerte analytikere at filen litellm/proxy/proxy_server.py inneholdt en innebygd base64-kodet nyttelast som var fraværende fra samme fil i GitHub-commitenOmtrent et dusin linjer ble satt inn mellom ellers legitime kodeblokker (for eksempel nær definisjonen av REALTIME_REQUEST_SCOPE_TEMPLATE og showwarning Disse ekstra linjene dekodet og utførte et skjult skript i stillhet hver gang modulen ble importert.

I versjon 1.82.8, gikk angriperne et skritt videre ved å slippe en .pth filen heter litellm_init.pth inn i Python-miljøet. Fordi Python behandler alle .pth filer ved oppstart av tolken, dette sikret at nyttelasten ville kjøre på hver Python-påkallelse, selv om LiteLLM i seg selv aldri ble importert av applikasjonen.

Denne opptrappingen gjorde 1.82.8 betydelig farligereEthvert Python-skript, testkjører, byggeverktøy eller automatisering som startes i et miljø med den kompromitterte pakken installert, ville stille utløse logikken for å stjele legitimasjon i bakgrunnen.

Forbindelse med den bredere TeamPCP-kampanjen

LiteLLM-kompromisset skjedde ikke isolert. Undersøkelser fra Sonatype, Wiz, Endor Labs og andre knytter det til en pågående forsyningskjedekampanje drevet av TeamPCP, en gruppe som fikk oppmerksomhet sent i 2025 og som siden har rettet seg mot en rekke åpen kildekode-prosjekter og utviklerosystemer.

Tidligere i mars ble de samme skuespillerne knyttet til bakdøring av Aqua Securitys Trivy sårbarhetsskanner og relaterte GitHub-handlinger, samt skadelige varianter av Checkmarx-verktøy, inkludert KICS, GitHub-handlinger og OpenVSX-utvidelser. Kampanjen har også berørt npm-pakker, Docker Hub-bilder og Kubernetes-miljøer, og har ofte gjenbrukt infrastruktur, krypteringsskjemaer og persistensartefakter.

Ved å spore opp LiteLLM-hendelsen avslørte vedlikeholderne at en PyPI-publiseringstoken lagret som en miljøvariabel i LiteLLMs GitHub-repositorium ble eksfiltrert via den kompromitterte Trivy-arbeidsflyten. Denne tokenen ble deretter misbrukt til å publiser de forurensede PyPI-utgivelsene, slik at angriperne kan omgå tofaktorbeskyttelse på brukerkontoer og injisere ondsinnede hjul uten å endre offentlig kildekode.

Forskere peker også på mistenkelige commits og arbeidsflyter som ble opprettet rundt 23. mars i LiteLLM-relaterte repositorier, inkludert en kortlivet gren og en GitHub Actions-arbeidsflyt som bærer en kjent RSA-offentlig nøkkel som er sett på tvers av andre TeamPCP-nyttelaster. Telemetri fra arbeidsflytkjøringer antyder at hemmeligheter tilgjengelig for disse CI-kjørerne kan ha blitt åpnet og eksfiltrert.

På tvers av hendelser har gruppen vist et gjennomgående mønster: stjele legitimasjon i ett miljø, og deretter bytte til det neste økosystemetI dette tilfellet tillot en feilkonfigurasjon i Trivys GitHub Actions tyveri av et privilegert token. Dette tokenet førte til ondsinnede Trivy-utgivelser og Docker-avbildninger. Disse muliggjorde igjen kompromittering av Checkmarx-verktøy og til slutt LiteLLM PyPI-pakken.

Hvordan LiteLLM-skadevaren fungerer

Analyser fra flere leverandører beskriver LiteLLM-bakdøren som en flertrinns, base64-obfuskert Python-nyttelast designet for å være snikende, fleksibel og robust. Logikken er organisert i omtrent tre lag, som hvert håndterer en annen fase av angrepet.

I det første laget, den injiserte koden i proxy_server.py eller litellm_init.pth fil dekoder og lanserer en skjult orkestrator. I stedet for å bruke funksjoner som er lett å flagge, som exec(), lener skriptet seg på underprosesskall og standard bibliotekfunksjonalitet for å kjøre den dekodede nyttelasten og fange opp utdataene, noe som hjelper den med å blande seg inn i normal applikasjonsoppførsel.

Når den kjører, samler denne orkestratoren inn resultatet fra den påfølgende fasen, krypterer de innsamlede dataene med AES-256-CBC og krypterer deretter selve AES-øktnøkkelen ved hjelp av en hardkodet RSA-offentlig nøkkel som er innebygd i koden. Den krypterte bloben og nøkkelen er samlet i et arkiv med navnet tpcp.tar.gz, som gjenspeiler andre TeamPCP-operasjoner, og er forberedt på eksfiltrering.

Det andre laget er ansvarlig for aggressiv systemrekognosering og innhøsting av legitimasjonDen lister opp vertsnavn, bruker- og nettverksinformasjon og miljøvariabler, og skanner deretter en lang liste med stier og konfigurasjonsfiler for sensitivt materiale. Målene inkluderer:

• SSH-nøkler og konfigurasjonsfiler (klient og server)
• Skylegitimasjon for AWS, GCP og Azure, inkludert metadata-avledede tokener
• Kubernetes kubeconfig-filer, tjenestekontotokener og klyngehemmeligheter
• Miljøfiler slik som .env varianter som ofte brukes til å lagre API-nøkler
• CI/CD-konfigurasjon, hemmeligheter og tilgangstokener
• Terraform, Helm og andre IaC- eller distribusjonsartefakter
• Databasetilkoblingsstrenger og konfigurasjonsfiler
• TLS/SSL private nøkler og autentiseringsmateriale
• Cryptocurrency lommebøker og relaterte data

I noen miljøer stopper ikke tyveren ved innsamling. Den prøver å aktivt bruke oppdagede legitimasjonsdetaljer, for eksempel ved å spørre skyleverandørers API-er, hente Kubernetes-hemmeligheter eller utforske tilgjengelige ressurser, noe som øker sjansen for lateral bevegelse og påfølgende kompromiss.

Det tredje laget gir utholdenhet og fjernkontrollDen skriver et Python-skript til disk (vanligvis observert som sysmon.py) og registrerer den som en langvarig tjeneste, ofte forkledd som noe godartet som en «System Telemetry Service». Denne tjenesten kontakter med jevne mellomrom angriperinfrastrukturen, vanligvis hvert 50. minutt, for å hente ytterligere kommandoer eller nyttelaster.

Forskere legger merke til noe særegen oppførsel her: da visse sikkerhetsleverandører forsøkte å hente nyttelasten fra kommando-og-kontroll-endepunktet, svarte serveren med en lenke til en remastret versjon av sangen «Bad Apple!!», tilsynelatende som en avledningstaktikk mot automatisert analysePå infiserte systemer kan imidlertid den samme mekanismen stille levere ny funksjonalitet over tid.

Eksfiltreringskanaler og angriperinfrastruktur

På tvers av LiteLLM-hendelsene observerte analytikere kommunikasjon med minst to hoveddomener kontrollert av angripere: modelslitellmcloud og sjekkmarssoneDisse er i tråd med infrastrukturen som ble brukt i tidligere TeamPCP-aktiviteter og har forskjellige roller.

Det krypterte arkivet tpcp.tar.gz er typisk lastet opp til models.litellmcloud, slik at operatørene kan hente stjålne legitimasjonsopplysninger fra tusenvis av nedstrømsmiljøer. I noen varianter, forskjellige underbaner av checkmarxzone (for eksempel, checkmarxzone/raw or .../vsx) brukes til å levere persistensskript eller tilleggstrinn.

På kompromitterte systemer har forsvarere rapportert en rekke tilbakevendende indikatorer på kompromiss (IoC-er) knyttet til LiteLLM-skadevaren:

• Arkivets tilstedeværelse tpcp.tar.gz i midlertidige eller arbeidskataloger
• Midlertidige filer som /tmp/pglog og /tmp/.pg_state
• Python-skript og konfigurasjonsstier relatert til sysmon.py og en samsvarende tjenestefil (ofte under bruker- eller systemd-konfigurasjonskataloger)
• Uventet litellm_init.pth filer i Python-nettstedspakker for versjon 1.82.8
• Utgående trafikk eller DNS-oppslag som peker til modelslitellmcloud or sjekkmarssone

Ondsinnet logikk ble sporet til filer, inkludert proxy_server.py (LiteLLM 1.82.7 og 1.82.8) og litellm_init.pth (1.82.8). Sikkerhetsleverandører har katalogisert hasher og ytterligere IoC-er og fortsetter å oppdatere sine råd etter hvert som flere rettsmedisinske detaljer dukker opp.

Innvirkning på AI-, sky- og CI/CD-miljøer

Fordi LiteLLM brukes mye i AI-drevne applikasjoner og tjenester, den praktiske eksplosjonsradiusen til dette kompromisset strekker seg utover enkle pakkeforbrukere. Skymiljøer der LiteLLM fungerte som inngangsport til LLM-leverandører vil sannsynligvis ha samlokaliserte hemmeligheter i samme kjøretid eller konfigurasjonsområde.

Wiz og andre observatører anslår at LiteLLM dukker opp rundt en tredjedel av observerte skymiljøer, noe som understreker den potensielle rekkevidden. Noen kilder sitert av BleepingComputer har antydet at antallet datautfiltreringshendelser kan komme opp i hundretusenvis, selv om uavhengig bekreftelse av nøyaktige tall fortsatt venter.

Spesielt legger skadevaren vekt på Kubernetes-bevisst atferdI mange analyser forsøker nyttelasten å distribuere privilegerte poder på tvers av alle noder i en klynge, og deretter bruke disse podene til å få tilgang til hemmeligheter og konfigurasjonsobjekter. I separate, men relaterte TeamPCP-operasjoner har forskere sett Kubernetes-klynger bli målrettet med skript som sletter noder når miljøet ser ut til å være i Iran, samtidig som de installerer bakdører (som den såkalte CanisterWorm) andre steder.

Fokuset på CI/CD-verktøy er tilsvarende tydelig. Ved å kompromittere Trivy GitHub Actions, Checkmarx VS Code-utvidelser og GitHub Actions, og nå LiteLLM, får angripere inngangspunkter der automatisering har allerede brede privilegier over repositorier, byggeartefakter og distribusjonslegitimasjon. Denne tilnærmingen gjør ellers sikkerhetsorienterte verktøy til springbrett for bredere kompromisser.

FBI-tjenestemenn og bransjeforskere har advart om at med store mengder stjålet legitimasjon i hendene, er det rimelig å forvente flere varsler om brudd, sekundære inntrenginger og utpressingsforsøk i ukene og månedene etter den første LiteLLM-avsløringen.

Deteksjons-, inneslutnings- og utbedringstrinn

For organisasjoner som kan ha hentet eller kjørt LiteLLM-versjoner 1.82.7 eller 1.82.8 Fra PyPI er veiledningen fra sikkerhetsleverandører og PyPI-vedlikeholdere direkte: behandle berørte systemer som kompromitterteBare å avinstallere pakken fjerner ikke vedvarende mekanismer eller angrer eventuelle påloggingstyverier som allerede kan ha skjedd.

Anbefalte umiddelbare tiltak inkluderer:

• Identifiser eventuelle installasjoner av LiteLLM 1.82.7 eller 1.82.8 på tvers av utviklermaskiner, CI/CD-kjørere, containere og produksjonsmiljøer.
• Fjern de skadelige versjonene og fest LiteLLM til en kjent fungerende utgivelse (med 1.82.6 mye sitert som den siste rene versjonen på rapporteringstidspunktet).
• Roter alle legitimasjonsopplysninger tilgjengelig fra berørte miljøer: SSH-nøkler, skyleverandørnøkler og -tokener, Kubernetes-hemmeligheter, CI/CD-hemmeligheter, databaselegitimasjon, TLS-nøkler og eventuelle lommebøker eller betalingsrelaterte hemmeligheter.
• Søk etter persistensartefakter, Eksempel sysmon.py, mistenkelige systemd-tjenestedefinisjoner og uvanlige filer under ~/.config eller midlertidige kataloger som /tmp/pglog og /tmp/.pg_state.
• Inspiser Kubernetes-klynger for uventede privilegerte poder, spesielt i navnerom som kube-system, og for uvanlige tjenestekontoer eller rollebindinger.
• Overvåk utgående tilkoblinger og DNS-spørringer for kjente angriperdomener som models.litellmcloud og checkmarxzone.

I miljøer der bakdøren kan ha blitt kjørt i en betydelig periode, foreslår mange eksperter at en fullstendig gjenoppbygging fra en pålitelig grunnlinje kan være den sikreste veien, spesielt for kritisk infrastruktur. Gitt skadevarens natur, kan ikke subtil manipulering eller ytterligere nyttelast utelukkes ved å fjerne LiteLLM-pakken.

Organisasjoner oppfordres også til å ta i bruk mer robuste avhengighetshåndtering og forsvar i forsyningskjeden: festing til spesifikke, verifiserte versjoner, aktivering av verktøy som blokkerer eller flagger kjente skadelige pakker ved inntak, og integrering av automatisert atferdsanalyse som kan oppdage uventet nettverks- eller filsystemaktivitet under bygg og tester.

Hva LiteLLM-saken sier om forsyningskjeder for AI-programvare

LiteLLM-hendelsen fremhever en bredere trend som har bygget seg opp de siste årene: Komponenter med høy utnyttelse i AI og skystakker blir stadig viktige mål for angripere i forsyningskjeden. I stedet for å gå direkte etter sluttbrukerapplikasjoner, ser trusselaktører i økende grad etter punkter i verktøykjeden der kompromisser med et enkelt bibliotek eller en plugin gir tilgang til mange nedstrømsorganisasjoner.

Pakker som LiteLLM sitter effektivt på en chokepunkt for hemmeligheterDe formidler anrop til AI-leverandører, berører CI/CD og infrastrukturautomatiseringssystemer, og kjører ofte med utvidede tillatelser. Etter hvert som flere bedrifter skynder seg å integrere LLM-funksjoner ved hjelp av åpen kildekode-verktøy, vokser verdien av slike komponenter – og insentivet til å bakdøre dem – bare.

Samtidig illustrerer angrepet utfordringene med å forsvare bygge- og publiseringspipeliner. I dette tilfellet skal angriperne ha utnyttet en feilkonfigurasjon av Trivy-arbeidsflyten til å stjele et token, og deretter brukt det tokenet til å sende infiserte pakker til PyPI, samtidig som de tilsynelatende lot det offentlige kildetreet være rent. Versjonskoder og byggetrinn ble en del av angrepsflaten, og utnytter det faktum at mange pipelines er avhengige av tagger i stedet for pinned commits og implisitt kan stole på artefakter som kommer fra kjente vedlikeholdere.

Leverandører som Sonatype, Wiz og Endor Labs understreker viktigheten av automatiserte sikkerhetstiltak i sanntid som kan oppdage unormal oppførsel – som tidligere usete nettverksdestinasjoner eller kryptert eksfiltrering – selv når pakkemetadata og arkivhistorikk ser legitime ut. Brannmurer for arkiver, trusselintelligensdrevne skannere og kontekstuell analyse av avhengigheter blir i økende grad sett på som nødvendige lag, ikke valgfrie tillegg.

For både vedlikeholdere og organisasjoner er LiteLLM-kompromisset en påminnelse om at håndtering av hemmeligheter, CI/CD-herding og rotasjon av legitimasjon er grunnleggende for sikkerheten i forsyningskjeden. Ufullstendig eller ikke-atomær rotasjon av legitimasjonsinformasjon i tidligere hendelser etterlot åpninger som TeamPCP kunne gjenbruke uker senere, noe som demonstrerer hvordan et enkelt feiltrinn i hendelsesresponsen kan spre seg over økosystemer.

Kampanjen som tok over LiteLLM startet med det som så ut som et problem med begrenset arbeidsflyt, og har siden omfavnet GitHub Actions, Docker Hub, Shai-Hulud npm-hendelsen, OpenVSX og PyPI. Med bakdører gjemt i allment pålitelige verktøy og AI-koblinger, og stjålne legitimasjonsdetaljer som strømmer til angriperinfrastruktur, understreker episoden hvor raskt programvareforsyningskjeden kan bli en attraktiv og svært effektiv angrepsflate.