Innhold Vis
LiteLLM versjon 1.82.7 og 1.82.8 ble 24. mars 2026 infisert med skadevare som stjal API-nøkler, SSH-nøkler og skykredentialer. Angrepet ble utført av trusselaktøren TeamPCP, som først kompromitterte Trivy – en populær open source sikkerhetsskanner – og brukte den som springbrett inn i LiteLLMs CI/CD-pipeline.
LiteLLM er en av de mest brukte Python-pakkene i AI-pipelines. Den fungerer som en universell «mellomvare» mellom applikasjoner og språkmodell-APIer fra OpenAI, Anthropic, Google og andre. Med 3,4 millioner daglige nedlastinger og direkte avhengigheter fra prosjekter som CrewAI, DSPy, MLflow og OpenHands er potensialet for skade enormt.
De kompromitterte versjonene var tilgjengelige på PyPI i om lag tre timer – fra cirka 10:39 til 16:00 UTC – før pakken ble fjernet av PyPI. Tre timer er lenge nok til å nå mange.
Hvordan angrepet fungerte – steg for steg
TeamPCP startet ikke med LiteLLM. De startet med Trivy.
Trivy er en open source sikkerhetsscanner fra Aqua Security som brukes av tusenvis av CI/CD-pipelines – inkludert LiteLLMs egen. Angriperne utnyttet en pull_request_target-arbeidsflyt i Trivys GitHub-repository til å stjele Aquas bot-legitimasjon. Deretter overskrev de Git-tagger i trivy-action-repositoriet til å peke på en ondsinnet versjon (v0.69.4).
LiteLLM kjørte Trivy i sin pipeline – uten en fastlåst versjon. Da pipelinen hentet «nyeste» Trivy, fikk den den kompromitterte varianten. Den kompromitterte Trivy-versjonen stjal LiteLLMs PyPI-publiseringstoken. Dermed hadde angriperne nøklene til å publisere hva de ville som «offisielle» LiteLLM-pakker.
Dette er klassisk supply chain-angrep: Angrip et svakt ledd i kjeden, bruk det til å kompromittere neste ledd, og så neste – inntil du har tilgang til millioner av systemer.
Hva ble stjålet fra infiserte systemer?
Den ondsinnede koden i litellm==1.82.8 inneholder en fil kalt litellm_init.pth – en Python-startfil som kjøres automatisk av Python-tolken ved oppstart. Uten at du importerer LiteLLM. Uten at du kjører noe eksplisitt. Bare det å ha pakken installert er nok.
Skadevaren opererte i tre stadier:
- Stadium 1 – Innsamling: Søkte gjennom filsystemet etter
.env-filer, SSH-nøkler, AWS-credentials, GCP/Azure-tjenestekontofiler og Kuberneteskubeconfig-filer. Kryptovaluta-lommebøker var også på listen. - Stadium 2 – Eksfiltrering: Krypterte data med AES-256 og sendte det til domenet
models.litellm.cloud– registrert av angriperne 23. mars, én dag før angrepet. Domenet ser ut som et legitimt LiteLLM-domene. - Stadium 3 – Persistens: Installerte en falsk «System Telemetry Service» via systemd, og deployet ondsinnede pods til alle noder i kube-system for Kubernetes-sidebevegelighet.
LiteLLM sitter i en særlig sensitiv posisjon i AI-stakken. Den fungerer som en proxy mellom applikasjoner og AI-tjenester, og har derfor direkte tilgang til API-nøklene som brukes mot OpenAI, Anthropic, Google og andre. Kompromitteres LiteLLM, kompromitteres potensielt alle disse nøklene i én operasjon.
Hvem er TeamPCP?
TeamPCP – også kjent under navnene PCPcat, Persy_PCP, ShellForce og DeadCatx3 – har ifølge sikkerhetsforskere vært aktive siden minst desember 2025. De er kjent for å koordinere via Telegram-kanaler og bruker noe de selv kaller «hackerbot-claw» – en AI-agent for automatisert angrepsmål.
Det er ikke tilfeldig at LiteLLM ble valgt. Angrepet mot Trivy, Checkmarx (KICS) og LiteLLM ser ut til å være del av en koordinert kampanje mot populære verktøy i DevOps- og AI-stacken. Arctic Wolf beskriver dette som en bredere TeamPCP-kampanje med potensielle downstream-konsekvenser for ytterligere prosjekter.
Hvem er berørt?
Du er direkte berørt hvis du installerte LiteLLM via pip mellom 10:39 og 16:00 UTC den 24. mars 2026, kjørte pip install litellm uten en fastlåst versjon, eller bygget Docker-images med upinnet LiteLLM i dette tidsvinduet.
Indirekte berørt kan du være hvis prosjekter du avhenger av – CrewAI, Browser-Use, Opik, DSPy, Mem0, Instructor, Guardrails, Agno eller Camel-AI – hentet LiteLLM i dette vinduet som en del av sin egen byggeprosess. Disse prosjektene slapp sikkerhetsoppdateringer samme dag ifølge LiteLLMs eget sikkerhetsblogginnlegg.
Ikke direkte berørt: Brukere av den offisielle LiteLLM Proxy Docker-imagen, og brukere av versjon 1.82.6 eller eldre.
Hva bør du gjøre nå?
Første prioritet: Sjekk om litellm_init.pth eksisterer på dine systemer. Filen er den viktigste indikatoren for kompromittering.
Deretter bør du rotere alle hemmeligheter. Alle. API-nøkler til OpenAI, Anthropic, Google og andre AI-tjenester. SSH-nøkler. Cloud-credentials for AWS, Azure og GCP. CI/CD-tokens. Kubernetes-secrets. Det er kjedelig arbeid, men det er eneste måten å ha kontroll på.
Sjekk også etter disse filene og prosessene som indikerer kompromittering:
~/.config/sysmon/sysmon.py– bakdørsskriptlitellm_init.pth– ondsinnet Python-oppstartsfilsysmon.service– persistens via systemd- Nettverkstrafikk mot
models.litellm.cloudeller45.148.10.212
Pinne LiteLLM til versjon 1.82.6 eller oppdater til nyeste versjon (1.82.9 eller nyere, som ikke er kompromittert). Og generelt: Pinne versjoner på alle kritiske avhengigheter i CI/CD-pipelines. «Bruk nyeste» er praktisk til det ikke er det.
Det egentlige problemet – tillitskjeden i AI-pipelines
Dette angrepet er et lærebokeksempel på noe mange AI-utviklere ikke tenker på: Avhengighetskjeden din er angrepsflaten din.
LiteLLM hadde ikke en sikkerhetssvakhet i koden sin. Maintainerne ble ikke hacket direkte. Det var et indirekte angrep via et verktøy de brukte – Trivy – som var kompromittert via en GitHub Actions-sårbarhet. Kjeden er lang: GitHub Actions – Trivy – LiteLLMs PyPI-token – LiteLLM-pakker – alle som kjørte pip install.
I AI-utvikling er det blitt normalt å lene seg tungt på store, kompatible biblioteker. LiteLLM er populær nettopp fordi den abstraherer vekk kompleksiteten i å håndtere mange AI-APIer. Men den posisjonen – mellom applikasjonen og alle AI-nøklene – gjør den til et svært attraktivt mål. Kompromitterer du LiteLLM, kompromitterer du effektivt alle API-nøklene den håndterer.
Verktøy som sitter mellom applikasjoner og sensitiv data trenger særlig nøye vurdering. Det gjelder LiteLLM, det gjelder n8n-integrasjoner, det gjelder alle mellomlag i AI-stakken. Dependency trust er ikke bare et JavaScript-problem lenger.
Har du LiteLLM i pipelines eller prosjekter? Sjekk versjonene, roter nøklene, og pin versjonene for fremtiden.
