CISA varsler aktiv utnyttelse av LiteLLM-feil

CISA har lagt LiteLLM-sårbarheten CVE-2026-42271 inn i den amerikanske katalogen over kjente utnyttede sårbarheter. Det gjør saken større enn en vanlig patch-notis. LiteLLM brukes som AI-gateway for å rute kall mot språkmodeller gjennom et OpenAI-lignende API. Når et slikt lag feiler, kan angriperen komme nær både modellnøkler, interne verktøy og systemene agentene får lov til å bruke.

Sårbarheten gjelder BerriAI LiteLLM fra versjon 1.74.2 til før 1.83.7. Ifølge NVD og GitHub-rådgivningen kunne to test-endepunkter for MCP-servere ta imot full konfigurasjon i request-body, inkludert command, args og env for stdio-transporten. Når endepunktene ble kalt, forsøkte LiteLLM å koble seg til serveren. Det kunne starte den innsendte kommandoen som en prosess på verten der proxyen kjørte. Tilgangen var ikke begrenset til administratorrolle. En gyldig proxy API-nøkkel holdt. Også brukere med lavere internrettigheter kunne i praksis få kjørt vilkårlige kommandoer på hosten.

CISA beskriver feilen som command injection og ber berørte virksomheter følge leverandørens tiltak, bruke relevant BOD 22-01-veiledning for skytjenester eller slutte å bruke produktet hvis tiltak ikke finnes. Fristen i KEV-katalogen er 22. juni 2026. Det korte tidsvinduet er poenget: CISA reserverer denne katalogen for sårbarheter som er observert utnyttet, ikke bare teoretiske CVE-er.

For norske virksomheter er den praktiske lærdommen enkel. AI-gatewayen er ikke bare en utviklerkomponent. Den er et kontrollpunkt mellom brukere, agenter, modellleverandører, interne nøkler og ofte interne datasett. Mange innfører slike proxyer for kostnadskontroll, logging, modellruting og policy. Det er fornuftig. Men da må komponenten inn i samme driftsregime som API-gatewayer, identitetslag og hemmelighetsforvaltning.

Det som gjør CVE-2026-42271 ekstra relevant, er koblingen til MCP og agentdrift. MCP brukes for å gi modeller og agenter tilgang til verktøy. Testfunksjoner som virker ufarlige i utvikling, kan bli produksjonskritiske når de ligger bak en felles AI-proxy. Her var problemet at test-endepunktene kunne brukes til å starte en stdio-prosess. Når agentplattformen samtidig sitter med nøkler og tilgang til flere verktøy, blir en liten rollefeil raskt en vei inn i driftsmiljøet.

BerriAI har patchet feilen i LiteLLM 1.83.7. GitHub-rådgivningen sier at test-endepunktene nå krever PROXY_ADMIN-rolle. Hvis oppgradering ikke kan gjøres med en gang, anbefaler leverandøren å blokkere POST /mcp-rest/test/connection og POST /mcp-rest/test/tools/list i reverse proxy eller API-gateway. Det bør behandles som midlertidig risikoredusering, ikke som endelig løsning.

Dette bør på listen hos CIO og CISO nå:

• Finn alle LiteLLM-installasjoner, også de som er satt opp av utviklerteam, labs eller enkeltprosjekter. Se etter både containerbilder, pip-pakker og interne forks.

• Verifiser versjon. Alt fra 1.74.2 til før 1.83.7 må oppgraderes eller isoleres. Ikke stol på at skyplattformens standard scanning fanger opp alt hvis komponenten kjører som intern proxy.

• Se på nøklene i proxyen. En AI-gateway samler ofte nøkler til OpenAI, Anthropic, Google, Azure, interne MCP-verktøy og observability. Roter nøkler hvis det finnes tegn på uvanlig bruk eller hvis eksponering ikke kan utelukkes.

• Stram inn roller. En gyldig API-nøkkel skal ikke gi tilgang til test-, admin- eller verktøykonfigurasjon. Skillet mellom intern bruker, utvikler, tjenestekonto og administrator må være eksplisitt.

• Logg agent- og gatewayhendelser som sikkerhetshendelser. Kommandoer startet av MCP, endringer i modellruting, nye verktøy og uvanlige proxykall bør være synlige for SOC, ikke bare for plattformteamet.

• Sett AI-gatewayer inn i sårbarhetsprogrammet. De bør ha eier, patch-SLA, backup-plan, hemmelighetsrutiner og driftsmonitorering. Hvis komponenten er kritisk for produksjonsagenter, holder det ikke at den eies av et tilfeldig prosjekt.

Saken peker også på et bredere mønster. Virksomheter bygger raskt nye kontrollplan for AI, ofte med åpen kildekode som lim mellom modeller, agenter og interne systemer. Det gir fart, men også en ny leverandør- og supply chain-risiko. Tradisjonelle sikkerhetsmodeller antar gjerne at applikasjonen er målet. I agentarkitektur kan orkestreringslaget være like attraktivt. Det vet angriperne.

CISA-katalogen gjør det vanskelig å avfeie dette som teoretisk agent-sikkerhet. Når en AI-gateway havner i listen over kjente utnyttede sårbarheter, bør styret og ledelsen lese det som et modenhetssignal. AI-plattformen må inn i vanlig risikostyring. Ikke etter pilotfasen. Nå.

Kilder og medier

Primærkilde: CISA Known Exploited Vulnerabilities Catalog, CVE-2026-42271. Source URL: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

Leverandørkilde: GitHub Security Advisory GHSA-v4p8-mg3p-g94g for BerriAI LiteLLM, https://github.com/BerriAI/litellm/security/advisories/GHSA-v4p8-mg3p-g94g

Sårbarhetsdetaljer: NVD, CVE-2026-42271, https://nvd.nist.gov/vuln/detail/CVE-2026-42271

Thumbnail: OpenAI Image 2 / hogby.ai