Pothuajse një në dhjetë portale LiteLLM të ekspozuara pranonin çelësin e paracaktuar të administratorit

Pothuajse një në dhjetë portale LiteLLM të ekspozuara në internet pranonin çelësin shembull sk-1234 të administratorit në një skanim nga Wiz Research, dhe ai kredencial i vetëm i paracaktuar hap aksesin ndaj çelësave API të ofruesve të ruajtur dhe, në testet e Wiz, ndaj kredencialeve të identitetit cloud të makinës që ekzekuton portalin. LiteLLM është një portal AI me burim të hapur, softueri që një kompani vendos midis aplikacioneve të saj dhe ofruesve të modeleve që paguan. Çelësi master është kredenciali i administratorit të portalit, dhe kushdo që e mban atë mund të lexojë çdo çelës API të ofruesit të modelit të ruajtur në server.

Wiz Research kreu një skanim dhe gjeti 3,074 portale LiteLLM në Shodan, një motor kërkimi për sisteme të ekspozuara në internet, në shkurt. Nga ata, 294 pranonin sk-1234. Në 191 prej tyre, asnjë çelës nuk ishte vendosur fare, kështu që ata do të kishin pranuar çdo vlerë, ndërsa pjesa tjetër kishte vlerën shembull të udhëzuesit të konfigurimit të mbetur në vend. Një skanim i dytë në gusht lokalizoi më shumë se 85,000 instanca, por Wiz thotë se shumica duken si honeypot ose sisteme testimi, kështu që të dy numërimet nuk mund të krahasohen dhe nuk ka një shifër aktuale. Që nga 9 shtatori, udhëzuesi i konfigurimit të LiteLLM ende përdor sk-1234 mbi një koment që u thotë operatorëve ta zëvendësojnë atë me një vlerë të gjatë të rastësishme përpara përdorimit real.

Arsyeja pse një çelës ka kaq shumë rëndësi është se çelësi master kryen dy detyra njëkohësisht. Ai është njëkohësisht kredenciali i administratorit dhe çelësi që aktivizon vërtetimin. Përpara versionit 1.82.0-stable, një portal që fillonte pa një çelës master u jepte çdo kërkese hyrëse të drejta të plota administratori. Një administrator në një nga këta serverë ka shumë në dispozicion: portali mund të mbajë një çelës API për çdo ofrues që drejton, mund të shohë çdo kërkesë dhe përgjigje që kalon, dhe mund të lidhet me mjete të brendshme përmes Model Context Protocol (MCP), ndërfaqja që lejon portalin të komunikojë me shërbimet e brendshme. Ai gjithashtu zakonisht ekzekutohet me lejet cloud të ngarkesës së punës në të cilën është vendosur. Vetëm çelësat e ofruesve të vjedhur lejojnë një sulmues të ekzekutojë ngarkesa pune modeli në faturën e viktimës, një abuzim i njohur si LLMjacking.

Wiz gjithashtu tregoi se si çelësi mund të arrijë llogarinë cloud. LiteLLM lejon një administrator të krijojë një pikë fundore pass-through, një rrugë që përçon kërkesat në çdo URL që zgjedh administratori. URL-ja e synuar nuk kontrollohet kundër diapazoneve të adresave private, localhost, ose adresave të metadatave cloud. Një administrator mund për këtë arsye të drejtojë një rrugë drejt shërbimit të metadatave të instancës dhe të lexojë kredencialet IAM që ai kthen. Kalimi në IMDSv2, një mënyrë më e re për të kërkuar metadata, nuk e ndalon këtë. LiteLLM dokumenton se çdo header i dërguar me një prefiks x-pass- kalon te objektivi me prefiksin e hequr, dhe Wiz përdori atë sjellje për të dërguar header-at që kërkon IMDSv2. Asnjë burim nuk raporton se dikush e ka bërë këtë kundër një vendosjeje reale. Është një demonstrim dhe kërkon fillimisht akses administratori. Wiz thotë se veçoria në thelb funksionon siç synohet sepse modeli i kërcënimit i LiteLLM i trajton administratorët si të besuar, kështu që nuk ka CVE dhe as rregullim. Politika e sigurisë e publikuar e LiteLLM thotë se sulmet që kërkojnë një gabim konfigurimi, si mosvendosja e një çelësi master, nuk janë në fushëveprim dhe nuk trajtohen si dobësi.

E vetmja dobësi e ekzekutimit të kodit në raportin e Wiz është CVE-2026-59821, dhe studiuesit dhe mirëmbajtësit e përshkruajnë atë shumë ndryshe. Wiz e quan atë ekzekutim kodi pas vërtetimit në nivel root dhe tregon një test që kthen uid=0(root) brenda kontejnerit të portalit. Këshilla e LiteLLM për të njëjtin CVE e vlerëson atë të Ulët në 2.1 në shkallën CVSS, duke përshkruar një dobësi që kërkon një llogari me privilegje të larta. Të dy përshkruajnë të njëjtën sjellje. Përpara 1.82.0-stable, pikat fundore që krijojnë dhe përditësojnë guardrails me kod të personalizuar anashkaluan kontrollet e sandbox-it dhe modeleve që aplikonte pika fundore e testimit, kështu që kushdo që mund t'i arrinte ato mund të dërgonte Python që ekzekutohej brenda kontejnerit. Këshilla shton se një vendosje pa çelës master i trajtonte thirrësit si administratorë proxy, gjë që i vinte ato pika fundore brenda arritjes. Raporti i Wiz deklaron se pas 1.82.0, një sulmues me çelësin e paracaktuar mund të ekzekutonte kod vetëm brenda një sandbox-i, por regjistri i vetë LiteLLM nuk e mbështet këtë për çdo version. Një këshillë e veçantë e publikuar në maj, CVE-2026-40217, thotë se sandbox-i mund të shpëtohej duke përdorur teknika bytecode duke ekzekutuar kod në procesin proxy, programi kryesor që trajton trafikun, i cili sipas këshillës ekzekutohet si root në imazhin e paracaktuar Docker. Ajo mbulon versionet nga 1.81.8 deri në, por pa përfshirë, 1.83.10, dhe arritja e pikës fundore kërkon një kredencial proxy-admin, të cilin çelësi master e është. Të dy dobësitë që raportoi Wiz u rregulluan muaj përpara raportit të tij të 9 shtatorit, në shkurt dhe prill, dhe CVE-të e tyre u publikuan në korrik.

Veçmas, çështjet më të vjetra të LiteLLM tashmë po shfrytëzohen. CISA shtoi CVE-2026-59822 në katalogun e saj të Dobësive të Njohura të Shfrytëzuara më 2 shtator. Dobësia, e gjetur gjithashtu nga Wiz, ka një rezultat CVSS prej 8.8 dhe lejon një sulmues të pavërtetuar të hapë një sesion të vlefshëm MCP duke përdorur çdo Bearer token, përfshirë një me një karakter të vetëm. Agjencitë civile federale kanë deri më 16 shtator ta adresojnë atë. Wiz e pa atë të përdoret kundër honeypot-eve të vetë tyre duke filluar nga 7 korriku, në kërkesa që mbanin token-a me një karakter të vetëm për të provuar pikat fundore të listimit të modeleve, dhe nuk përshkroi asnjë përdorim tjetër. Ajo dobësi nuk arrin rrugët e ekzekutimit të kodit ose të kredencialeve më sipër. Wiz deklaron se lejon vetëm akses në serverin MCP, dhe çfarë mund të arrijë varet nga cilat serverë mjetesh ka lidhur një organizatë.

Dobësia e LiteLLM që sulmuesit kanë përdorur për të ekzekutuar kod është një tjetër. CVE-2026-42271 ka një rezultat CVSS prej 8.7 dhe lejonte çdo përdorues të vërtetuar të ekzekutojë komanda në host përmes dy pikave fundore testimi MCP. Horizon3.ai raportoi në qershor se mund të zinxhirohej me një dobësi të header-it host të Starlette, CVE-2026-48710, për të bërë të njëjtën gjë pa asnjë kredencial fare. Honeypot-et e Wiz regjistruan atë dobësi duke u përdorur për të instaluar një minator kriptovalutash. Microsoft publikoi në gusht një rast në të cilin sulmuesit ekzekutuan komanda brenda një procesi portali LiteLLM, lexuan mjedisin e kontejnerit për çelësin master, çelësat e ofruesve dhe vargun e lidhjes së bazës së të dhënave, dhe më pas përdorën atë varg për të hyrë në serverin e bazës së të dhënave relacionale dhe për të kopjuar regjistrime nga tabelat e modeleve dhe çelësave virtualë të LiteLLM. Microsoft vlerëson me besim të lartë se sulmuesit fituan akses përmes portalit të ekspozuar dhe thotë se pika e hyrjes përputhet me zinxhirin CVE-2026-42271 dhe CVE-2026-48710. Kompania shtoi: 'Trajtoni portalet AI si depo sekretesh të Nivelit-0.'

Përditësimi në LiteLLM 1.84.0 ose më vonë mbulon çdo dobësi në tabelë. CVE-2026-59822 rregullohet në 1.84.0. CVE-2026-42271 rregullohet në 1.83.7. CVE-2026-59821 rregullohet në 1.82.0-stable. CVE-2026-40217 rregullohet në 1.83.10, megjithëse teksti i këshillës së LiteLLM tregon 1.83.11. Hapi i parë praktik është të ndryshoni çelësin master nga sk-1234 në një vlerë të gjatë të rastësishme. Kjo nuk kërkon përditësim dhe mbyll çdo rrugë në raportin e Wiz që varet nga mbajtja e çelësit. Përpara rrotullimit të çelësit, kontrolloni nëse është vendosur një çelës salt i veçantë, sepse procedura e rrotullimit ndryshon dhe përdorimi i gabuar mund t'i lërë kredencialet e ruajtura të palexueshme. Nëse nuk mund të përditësoni ende, bllokoni /mcp/ dhe dy pikat fundore testimi MCP, POST /mcp-rest/test/connection dhe POST /mcp-rest/test/tools/list, në proxy-n e kundërt ose portalin API. Bllokoni gjithashtu POST /guardrails/test_custom_code dhe kufizoni POST /guardrails dhe PUT /guardrails/{guardrail_id} vetëm për administratorët. Këto janë zgjidhjet e përkohshme në këshillat e vetë LiteLLM. Rishikoni pikat fundore pass-through në portal, kufizoni aksesin e rrjetit dalës të kontejnerit dhe jepini ngarkesës së punës rolin më të ngushtë cloud IAM me të cilin mund të punojë. Nëse mendoni se një sulmues mund të ketë pasur akses, rishikoni listën e guardrails për hyrje që nuk i keni krijuar ju dhe rinisni procesin për të pastruar kodin e mbajtur në memorie, pastaj rrotulloni çelësat e ofruesve, çelësin master dhe kredencialet e bazës së të dhënave. Përditësimi nuk heq as një guardrail që një sulmues ka regjistruar, as një çelës SSH që ka shtuar.

Nuk ka patch për rrugën pass-through drejt metadatave të instancës sepse LiteLLM nuk e trajton atë si dobësi. Kufizimet e rrjetit dalës dhe rolet e ngushta IAM janë kontrollet e vetme të disponueshme. Asnjë burim nuk përcakton se si të kontrollohet nëse rrugët MCP ose pass-through janë aktivizuar në një portal që keni trashëguar. Pyetësorët e gjuetisë të Microsoft gjejnë shfrytëzim, jo konfigurim. Për pronarët e faqeve të internetit dhe ekipet e IT-së që drejtojnë shërbime si ky në infrastrukturën e tyre, AEU-I ofron IT, infrastrukturë dhe konsulencë të fokusuar në sigurinë për të ndihmuar në rishikimin e portaleve të ekspozuara dhe për t'i mbajtur lejet cloud sa më të ngushta.