GBHackers meldte 28. april at CVE-2026-42208, en kritisk pre-autentiseringssårbarhet i LiteLLM-proxy-gatewayen, er under aktiv utnyttelse. Sårbarheten oppstår fordi systemet ikke parameteriserer Authorization: Bearer-headeren riktig under autentiseringssjekk. Konsekvensen er at enhver uautentisert angriper som når LiteLLM-proxy-porten kan eksekvere vilkårlige SQL-spørringer mot den underliggende databasen.
Ifølge Sysdigs analyse ble advisoryen først publisert til LiteLLM-repoet 20. april 2026, før den ble indeksert i globale CVE-databaser. Den første utnyttelsen ble oppdaget 36 timer etter offisiell indeksering, og angrepene var målrettet snarere enn opportunistisk skanning. Trusselaktørene viste forhåndskunnskap om LiteLLMs interne database-skjema og brukte systematisk column-count enumeration kombinert med roterende IP-adresser for å unngå deteksjon.
«Ethvert internett-eksponert instans som kjører en sårbar versjon bør anses som kompromittert, og krever umiddelbar rotasjon av alle eksponerte hemmeligheter.» — Sysdig, sårbarhetsadvisory
Det praktiske problemet er hva en vellykket SQL-injeksjon henter ut. LiteLLM fungerer som sentral proxy som kobler applikasjoner til OpenAI, Anthropic, Google Vertex, Cohere og dusinvis av andre leverandører. Databasen inneholder dermed leverandør-credentials i klartekst eller dekrypterbar form, virtuelle nøkler utstedt til interne tjenester, brukere og bruksmetadata. En enkelt vellykket utnyttelse kan eksponere hele KI-budsjettet ditt, ikke bare for plattformen som ble truffet, men for hver leverandør som har gitt deg en nøkkel.
Konteksten er verre enn isolert ettersom LiteLLM allerede har vært et mål i det pågående leverandørkjedeangrepet vi nettopp dekket. TeamPCP kompromitterte LiteLLM tidligere i mars som del av samme kjede som rammet Trivy, KICS og Bitwarden CLI. Mercor bekreftet tap av 939 GB kildekode etter den hendelsen. Dette er en ny og uavhengig sårbarhet, men eksponeringen overlapper for utviklere som har LiteLLM kjørende på en internettvendt port.
Hva bør du gjøre?
- Oppgrader til LiteLLM 1.83.7 nå. Patchen implementerer parameteriserte queries i autentiseringssjekken. Verifiser med
pip show litellmellernpm list litellmetter oppgradering, og restart proxy-tjenesten. - Roter alle leverandør-credentials for OpenAI, Anthropic, Google, Cohere og andre tjenester konfigurert i LiteLLM. Anta full eksponering hvis instansen har vært nådd fra internett siden 20. april 2026, ikke bare hvis du ser tegn til utnyttelse i loggene.
- Sett LiteLLM bak en intern proxy. Hvis du kjører den selvhostet, eksponer aldri proxy-porten direkte mot internett. Bruk en autentiserende reverse proxy (Nginx med basic auth eller Cloudflare Access) foran og whitelist kun nødvendige IP-områder.
Bakgrunn
LiteLLM er en open source-gateway brukt av tusenvis av selskaper for å abstrahere bort leverandørspesifikke API-detaljer fra applikasjonskode. Modellen «én proxy, mange leverandører» gjør den til et naturlig høyverdimål: den sentraliserer credentials og rate limits som ellers ville vært spredt utover applikasjoner. Sårbarhetsklassen (utilstrekkelig parameterisering av input fra HTTP-headere) er kjent fra tradisjonell webapp-sikkerhet, men dukker oftere opp i KI-infrastruktur fordi byggetempoet er høyere enn modenhetsgraden i sikkerhetsreviewen.