Wiz: nästan 1 av 10 exponerade LiteLLM-gateways accepterar exempeladminnyckeln sk-1234

Den 9 september 2026 publicerade Wiz Research en studie av LiteLLM, AI-gatewayen med öppen källkod som ligger mellan applikationer och de modellleverantörer de betalar, och rapporterade att 294 av de 3 074 LiteLLM-distributioner som den kunde nå på det publika internetet – 9,6 %, nästan en av tio – accepterade sk-1234, exempelmasternyckeln som trycks i projektets egen installationsdokumentation, eller inte krävde någon autentiseringsuppgift alls. Den strängen är inte en vanlig API-nyckel: i LiteLLM är den både administratörens autentiseringsuppgift och brytaren som slår på autentiseringen, så den som anger den kan läsa varje nyckel till modellleverantör som lagras i gatewayen, se varje prompt och varje svar som passerar genom den och nå varje verktygsserver som är ansluten via Model Context Protocol. Wiz medförfattare, Amitai Cohen och Yaara Shriki, kedjade samman den åtkomsten med kodkörning på rootnivå och med stölden av värdens moln-IAM-uppgifter. Denna redogörelse bygger på Wiz rapport, LiteLLMs egna säkerhetsmeddelanden och CISA:s lista Known Exploited Vulnerabilities som följde, och AI-incidentarkivet innehåller denna post tillsammans med sina grannposter, var och en med sina egna källor, allvarlighetsgrad och konfidensklass.

Publiceringsdatumet är det enda datum som posten anger, och det är ett publiceringsdatum. Skanningen bakom rubriken kördes i februari 2026; de två kodfel som Wiz beskriver hade fått rättningar levererade senast i mitten av maj, i utgåvor som projektets egna register daterar till mars och maj; CVE-identifierarna utfärdades i juli; och katalogposten kom i september. Nästan allt i rapporten var redan gammalt när den trycktes, vilket är en stor del av det rapporten hävdar.

9,6 % är en enda skanning, och Wiz säger att deras egen uppföljning i augusti inte kan jämföras med den.

Mätningen är enkel och Wiz redogör tydligt för sin metod: 3 074 internetexponerade LiteLLM-proxyer hittades via Shodan i februari 2026, och var och en testades för att se om den skulle autentisera med den dokumenterade exempelnyckeln. Av dessa gjorde 294 det. Inom den gruppen hade 191 ingen master-nyckel konfigurerad alls och skulle ha accepterat vilken sträng som helst som erbjöds dem; resten hade lämnat installationsguidens platshållare på plats. Inget av felfallen kräver en mjukvarubugg. Båda behöver bara gatewayens adress och värdet som trycks i projektets egen README.

Det är också en skanning från en enda leverantör. Wiz siffra har upprepats av Cloud Security Alliance's AI Safety Initiative den 10 september och av The Hacker News samma dag, men båda upprepar den med angiven källa, och ingen oberoende replikering av siffran 3 074 kunde hittas för den här artikeln. Wiz körde en andra skanning i augusti 2026 och hittade fler än 85 000 instanser, ungefär tjugosju gånger antalet i februari. Företaget säger att de flesta av dessa verkar vara honeypots eller testutplaceringar, och att de två antalen inte kan jämföras. Det finns ingen aktuell exponeringssiffra, och alla artiklar som citerar en sådan citerar februari.

Ytterligare en siffra i rapporten är Wiz egen telemetri snarare än en skanning: företaget säger att LiteLLM finns i ungefär en tredjedel av de molnmiljöer det observerar. Det är en leverantörs bild av sin egen kundbas och bör hållas på avstånd, men det förklarar varför forskarna behandlade en feldkonfiguration av gatewayen som ett molnproblem snarare än ett applikationsproblem.

Masternyckeln är både administratörens inloggningsuppgift och strömbrytaren som aktiverar autentisering.

LiteLLMs design ger en hemlighet två uppgifter. Huvudnyckeln autentiserar administrativa förfrågningar, och det är dess närvaro som överhuvudtaget möjliggör autentisering: utan huvudnyckel och utan JWT- eller OAuth2-konfiguration körs proxyn öppet och accepterar alla förfrågningar. Wiz närmade sig kodbasen med Anthropics Claude Code för att leta efter funktioner som tar användarkontrollerad indata och skickar den till en exekveringskontext, och autentiseringshanteraren var en av tre ytor som det flaggade.

Före v1.82.0-stable var konsekvensen av det andra jobbet värre än en öppen proxy. Wiz upptäckte att när ingen huvudnyckel var inställd tilldelade autentiseringshanteraren rollen PROXY_ADMIN till varje inkommande begäran, så en oautentiserad anropare blev inte bara insläppt utan insläppt som administratör. Pull request #22095, som citeras i rapporten, ändrade standardrollen till INTERNAL_USER och lade till en administratörskontroll för guardrail-endpunkterna.

Administrativ åtkomst till en gateway är inte ett smalt privilegium. Instansen har en API-nyckel för varje leverantör den dirigerar till, vilket är det som gör den till ett mål för LLMjacking – att köra modellarbetsbelastningar på offrets räkning. Den ser promptarna och completionerna. Den ansluter utåt till MCP-verktygsservrar, som vid en intern driftsättning sannolikt omfattar issue-trackers, chatt, databaser och driftsättningspipelines.

Wiz visade också en väg från den administrativa rollen till värdens molnidentitet. LiteLLM låter en administratör registrera en genomströmningsrutt till valfri mål-URL, och målet kontrolleras inte mot privata adressintervall, localhost eller molnets metadataadress. Att peka en rutt mot instansens metadatatjänst returnerar de IAM-uppgifter som arbetsbelastningen körs under. Att byta metadatatjänsten till IMDSv2, som normalt sett omintetgör den här typen av request forgery genom att kräva en sessionstoken som hämtas separat, hjälper inte: LiteLLM vidarebefordrar alla headers med prefixet x-pass- till målet med prefixet borttaget, så token-headern kan smugglas igenom. Wiz säger att funktionen rimligen fungerar som avsett enligt en hotmodell som litar på administratörer, och att den därför inte har någon CVE och ingen åtgärd.

Det sista stycket är en demonstration, inte en observerad attack. The Hacker News, som rapporterade om forskningen den 10 september, uppger att ingen källa rapporterar att någon har gjort det mot en verklig driftsättning, och att det först kräver administratörsåtkomst. Wiz formulering är densamma: genomströmningen är en designegenskap som blir en sårbarhet först när administratörsautentiseringsuppgiften är en sträng från dokumentationen.

8,8 och 2,1 betygsätter samma kedja från olika utgångslägen

Två CVE:er innehåller de tekniska fynden, och deras publicerade poäng kan knappast ligga längre ifrån varandra.

{{1}}CVE-2026-59822{{/1}} är autentiseringsbypassen i {{2}}MCP{{/2}}, och {{3}}LiteLLM{{/3}}s rådgivning klassar den som {{4}}High{{/4}}, {{5}}8.8{{/5}} enligt {{6}}CVSS 4.0{{/6}}, utan att några privilegier krävs, utan användarinteraktion och utan attackkrav. {{7}}MCP{{/7}}-slutpunkten har sin egen autentiseringshanterare, byggd för att acceptera antingen en {{8}}LiteLLM{{/8}}-nyckel eller en {{9}}OAuth2{{/9}}-token avsedd för en uppströms verktygsserver. När en token misslyckades med {{10}}LiteLLM{{/10}}s validering fångade hanteraren {{11}}401{{/11}} och ersatte den med ett tomt autentiseringsobjekt i stället för att avvisa begäran. Därför gav vilken {{12}}Bearer{{/12}}-token som helst en giltig {{13}}MCP{{/13}}-session, till och med ett enda tecken: {{14}}Wiz{{/14}}s proof of concept skickar en bearer-token på en enda bokstav och får tillbaka en sessionsidentifierare. Sårbarheten är åtgärdad i {{15}}1.84.0{{/15}}.

CVE-2026-59821 är bristen i guardrail-skyddet, och samma projekts säkerhetsrådgivning klassar den som Low, 2.1, med krav på höga privilegier och förekomst av attackkrav. Funktionen för anpassade kodguardrails låter en administratör skicka in Python som servern kompilerar och kör. Webbgränssnittets testendpoint validerade koden mot en lista över förbjudna mönster och tog bort builtins innan den kördes; produktionsendpointarna för skapande och uppdatering gjorde inget av detta. Python återställer builtins när de saknas, så den inskickade koden nådde standardbiblioteket. Wizs proof of concept registrerar en guardrail som kör ett shellkommando vid registreringstillfället – innan någon modellbegäran – och returnerar kommandots utdata som blockeringsorsak, vilket i deras test kom tillbaka som root. Bristen är åtgärdad i v1.82.0-stable.

De två beskrivningarna är förenliga, och den förenande meningen finns i själva säkerhetsrådgivningen: LiteLLM noterar att anropare i distributioner utan konfigurerad huvudnyckel kunde behandlas som proxyadministratörer, vilket var det som gjorde guardrail-slutpunkterna åtkomliga. A 2.1 förutsätter en privilegierad användare. Wiz kedja är vad som händer när standardnyckeln gör varje anropare privilegierad. Ingen av bedömningarna har fel om sin egen utgångspunkt; de är oense om hur ofta den utgångspunkten är ledig.

En invändning gäller Wizs påstående att en angripare som har standardnyckeln efter 1.82.0 endast kunde köra kod i en sandlåda. The Hacker News hänvisar till en separat rådgivning från maj 2026, CVE-2026-40217, som beskriver hur man tar sig ur sandlådan genom bytekodstekniker i versioner från 1.81.8 upp till men inte inklusive 1.83.10, i en proxyprocess som enligt rådgivningen körs som root i standardcontaineravbildningen. Att nå den slutpunkten kräver en autentiseringsuppgift för proxyadministratör, vilket är precis vad huvudnyckeln är.

8.8 är inte heller universellt. Cloud Security Alliances forskningsnot konstaterar att GitLabs rådgivning anger en baspoäng på 8.2 för samma brist och avstår från att avgöra mellan de två metoderna, och noterar endast att båda ligger i det höga intervallet. Att posten har allvarlighetsgraden hög hänger inte på vilket nummer som används.

En CVE utnyttjades i det vilda; exponeringen av standardnyckeln har inget namngivet offer.

CISA lade till CVE-2026-59822 i katalogen Known Exploited Vulnerabilities den 2 september 2026 och satte en tidsfrist för åtgärd till den 16 september 2026 för federala civila myndigheter; katalogposten anger CWE-287 och CWE-306, felaktig autentisering och saknad autentisering. I en not från Cloud Security Alliance rapporteras att branschobservatörer har beskrivit det som den första MCP-specifika sårbarheten på listan. Wiz har publicerat det utnyttjande de observerade: från och med den 7 juli 2026 loggade deras honeypots förfrågningar med bearer-token på ett enda tecken som sondrade slutpunkter för modelllistning, och Wiz beskriver inget annat utnyttjande av sårbarheten.

Inget jämförbart finns för standardnyckeln. Ingen utsatt person namnges, ingen gateway identifieras som övertagen via sk-1234, och ingen telemetri visar att de 294 värdarna används. Arkivposten registrerar ingen verklig skada, vilket är ett uttalande om bevis snarare än om mekanismen: exponeringen mättes, inte bevittnades användas.

Två andra poster arkiveras ofta tillsammans med dessa och är inte samma sak. CVE-2026-42271, kommandokörning via två MCP-testslutpunkter, är den LiteLLM-sårbarhet som angripare faktiskt har använt för att köra kod; Wizs honungsfällor registrerade att den installerade en kryptovalutaminerare. Fallet från augusti 2026 som Microsoft publicerade, där en inträngande läste en gateway-containers miljövariabler, återfick huvudnyckeln, leverantörsnycklarna och en databasanslutningssträng och sedan kopierade poster från LiteLLM:s tabeller för modeller och virtuella nycklar, illustrerar vad en komprometterad gateway är värd snarare än ett nytt sätt att ta sig in; The Hacker News rapporterar att Microsoft bedömer ingångspunkten som CVE-2026-42271-kedjan.

Underhållarnas ståndpunkt är att en saknad huvudnyckel är ett installationsmisstag, inte en sårbarhet.

LiteLLMs säkerhetspolicy är tydlig. Bland frågor utanför omfånget listar den "attacker som kräver en felaktig konfiguration vid installation (t.ex. att inte sätta en master_key i proxykonfigurationen)", och anger att dessa uttryckligen inte ingår i omfånget och inte anses vara sårbarheter. Wiz når en förenlig slutsats från motsatt håll när de kallar pass-through-beteendet för att möjligen fungera som avsett.

Den ståndpunkten har prövats offentligt. Den 15 augusti 2026 lämnade en forskare in GitHub-ärende #37054 och rapporterade att en proxy där LITELLM_MASTER_KEY inte är satt autentiserar vilket nyckelvärde som helst, och att den medföljande docker-compose-filen inte anger någon sådan. Ärendet stängdes 30 minuter senare, och den enda kommentaren till det är från samma konto: den hänvisar till säkerhetspolicyens instruktion att rapporter ska gå via privata sårbarhetsrapporter i stället för offentliga ärenden, ber om ursäkt för att ha rapporterat offentligt och säger att den fullständiga rapporten i stället lämnades in via rådgivningsvägen. Inget svar från en underhållare finns i tråden, så protokollet visar att rapportören drog tillbaka den offentliga rapporten snarare än att projektet svarade på den. Inget offentligt dokumenterar vad som hände med den privata inlämningen.

Inget offentligt uttalande från BerriAI som försvarar eller reviderar den ståndpunkten om septemberrapporten kunde hittas för den här artikeln. Företagets synliga svar finns i dess versionsinformation och konfigurationsfiler snarare än i löpande text.

Verkställigheten kom den 3 oktober, tjugofyra dagar efter rapporten

De två kodfelen åtgärdades långt före rapporten. Wizs tidslinje för offentliggörande anger att guardrail-koden rapporterades den 18 februari 2026 och åtgärdades den 25 februari i v1.82.0, att MCP-kringgåendet åtgärdades den 25 april i v1.84.0, att utnyttjande observerades den 7 juli, att CVE-identifierarna publicerades den 8 juli och att katalogposten publicerades den 2 september. Release-artefakterna har senare datum än åtgärderna: paketindexet visar v1.82.0 den 1 mars 2026 och v1.84.0 den 14 maj, vilket anger när respektive åtgärd blev installerbar snarare än när den landade. Två releaseposter från förstapart daterar samma åtgärder senare än den tidslinjen gör. Utgåvan v1.82.0-stable på GitHub anger 11 mars 2026 och paketet 1.82.0 på PyPI 1 mars; v1.84.0 är daterad 14 maj 2026 på båda. Inget som publicerats förklarar gapet, och det spelar ingen roll för argumentationen, eftersom vart och ett av dessa datum infaller månader före septemberrapporten. De två GitHub-aviseringarna tillför ett tredje datum: de publicerades den 30 juni 2026, tre veckor före de CVE-identifierare som Wiz säger gick ut den 8 juli.

Det som ingen av dessa utgåvor åtgärdade var standardvärdet. Wiz rapporterade att master-nyckeln fortfarande var satt till sk-1234 per den 9 september när LiteLLM installerades via Docker Compose eller pip install, och The Hacker News bekräftade att installationsguiden fortfarande använde det värdet den dagen. Ändringen kom med v1.104.0, som laddades upp till Python Package Index den 3 oktober 2026, och vars versionsinformation listar den som en brytande ändring: proxyn vägrar nu att starta med en master-nyckel som inte är angiven, är tom eller är allmänt känd, anger källan till det dåliga värdet i startfelet och skriver ut ett kommando som genererar en säker sådan. En åtföljande post dokumenterar en ändring för att sluta annonsera ett allmänt känt svagt master-nyckelvärde i medföljande konfigurationer och exempel, och docker-compose-filen på projektets huvudgren anger inte längre någon nyckel alls.

Det är den ordningen som är värd att behålla. Koden patchades i våras. Värdet som gjorde att patcharna inte räckte stod kvar i installationsanvisningarna ända till oktober, och först då började programvaran avvisa det. Inget i någon av åtgärderna krävde att den andra väntade.

Det som inte har förändrats är genomströmningsvägen till instansmetadatatjänsten. Den har fortfarande ingen CVE och ingen åtgärd, eftersom projektet behandlar administratörer som betrodda. Wizs åtgärdslista består därför mestadels av operatörsarbete: en stark och unik huvudnyckel, en granskning av registrerade skyddsräcken följt av en omstart av processen för att rensa kod som hålls i minnet, en granskning av genomströmningsslutpunkter med begränsad containerutgång, och IAM-roller med minsta behörighet. Ingen av dessa fyra uppnås enbart genom att uppgradera.

Vad handlingarna inte fastställer

• Ingen oberoende replikering av skanningen av 3 074 värdar kunde hittas. Siffran 9,6 % är Wiz egen mätning, och alla andra redogörelser för den upprepar siffran attributivt.

• Det finns ingen aktuell exponeringssiffra. Uppföljningen i augusti hittade fler än 85 000 instanser, som Wiz säger mestadels är honeypots eller testinstallationer och inte kan jämföras med antalet i februari.

• Inget offer. Inget i registret namnger en gateway, en operatör eller ett molnkonto som komprometterats via standardnyckeln, och det utnyttjande som Wiz dokumenterar avser kringgåendet av MCP snarare än av sk-1234.

• Inga bevis för att de 294 värddatorerna användes. Skanningen testade huruvida de skulle autentisera sig, vilket är ett svagare påstående än att visa att någon gjorde det.

• Ingen fastställd allvarlighetsgrad för guardrail-bristen. Wiz och underhållarna beskriver samma beteende och bedömer det mycket olika, och skillnaden handlar om vilka privilegier respektive part utgår från att angriparen redan har.

Wiz är också en molnsäkerhetsleverantör som säljer detektering för den här typen av exponering, och rapporten avslutas med ett avsnitt om hur dess egna produkter identifierar LiteLLM-distributioner, sårbara versioner och skugginstanser. Det är kontext för att läsa åtgärdsavsnittet, inte ett skäl att bortse från en mätning vars tekniska detaljer underhållarnas egna säkerhetsråd styrker.

Den del av posten som går utanför LiteLLM är mellanrummet mellan två datum. Sårbarheten stängdes under våren. Standardvärdet som gjorde sårbarheten relevant för en utomstående trycktes fortfarande i installationsanvisningarna i september, och programvaran började först i oktober avvisa det. Operatörerna som ändrade strängen behövde aldrig vänta på något av detta.