En angriper trenger ikke en gyldig API-nøkkel for å treffe sårbarheten. Det holder å sende en spesialformet Authorization-header til en hvilken som helst LLM-rute, for eksempel POST /chat/completions, og forespørselen havner i proxyens nøkkelvalidering. Der har BerriAI bygget databasekallet ved å lime inn nøkkelverdien direkte i SQL-strengen i stedet for å sende den som parameter. Resultatet er klassisk SQL-injeksjon, og fordi den treffes via feilhåndteringsbanen, er ingen autentisering nødvendig.
LiteLLM brukes som gateway foran OpenAI-, Anthropic- og lokale modell-API-er, ofte med delte API-nøkler og brukerkvoter i en bakliggende database. Med leserettigheter kan en angriper hente ut nøklene proxyen forvalter. Med skriverettigheter kan vedkommende endre kvoter, slette logger eller injisere egne nøkler. RedPacket Security klassifiserer den som «priority 1» fordi aktiv utnyttelse allerede er observert og angrepet kan automatiseres.
For multi-tenant-oppsett er konsekvensene størst. En LiteLLM-proxy som forvalter nøkler for flere team blir et enkelt kompromisspunkt: én vellykket injeksjon eksponerer alle leietakeres nøkler og loggdata samtidig. Med skrivetilgang kan en angriper også injisere egne nøkler i tabellen og lure proxyen til å rute trafikk gjennom dem.
For team som kjører LiteLLM bak WAF eller VPN er risikoen lavere, men ikke null. En kompromittert intern host kan fortsatt nå proxyen, og angripere som har plassert seg på innsiden kan eskalere via denne ruten.
Bakgrunn
LiteLLM er en open-source proxy-server (en «AI gateway») fra BerriAI som lar utviklere kalle ulike LLM-API-er gjennom et OpenAI-kompatibelt grensesnitt. Prosjektet har blitt populært i KI-utviklingsmiljøet fordi det forenkler bytte mellom modeller og leverer enhetlig kostnadssporing, kvotehåndtering og nøkkelrotasjon. Sårbarheten ligger i kjernen av denne kvotefunksjonen, der hver innkommende forespørsel slår opp den medfølgende nøkkelen i en SQLite- eller Postgres-database.
Hva bør du gjøre?
- Oppgrader til 1.83.7 umiddelbart hvis du kjører en versjon mellom 1.81.16 og 1.83.6. Det er den eneste fullgode fiksen.
- Sjekk LiteLLM-loggene for SQL-feilmeldinger rundt nøkkelvalidering og uvanlige Authorization-header-formater på
/chat/*og/completions-rutene. Aktiv utnyttelse pågår, så bevisspor kan allerede ligge der. - Hvis patching tar tid, blokker offentlig tilgang via IP-allowlist eller WAF-regler på Authorization-headeren. Roter alle nøkler proxyen forvalter etter oppgraderingen, og sjekk for uventet utgående trafikk fra proxy-prosessen.