JFrog paljasti 7. lokakuuta 2026 vakavan haavoittuvuuden LMCachessa, avoimessa lähdekoodissa olevassa ohjelmistossa, joka nopeuttaa LLM-palvelimia kuten vLLM:ää. CVE-2026-105192 -haavoittuvuus saa CVSS-arvon 9.8, kun moniprosessipalvelin on sidottu routattavaan osoitteeseen, ja korjattu versio ei ole vielä saatavilla. Ei-todentunut hyökkääjä, joka pystyy saavuttamaan ZeroMQ-portin, voi suorittaa koodia LMCache-prosessin käyttäjänä – usein rootina virallisissa konteissa.
Moniprosessitilassa LMCache toimii itsenäisenä cache-palvelimena, johon LLM-työntekijät liittyvät ZeroMQ:n kautta. Oletuksena se kuuntelee vain paikallisessa hostissa. Se tulee muiden hostien saavutettavaksi, kun operoijat asettavat routattavan osoitteen – yleistä monisolmuisissa klustereissa. Projektin oma Kubernetes-esimerkki käynnistää palvelimen kuuntelemaan kaikkia interfacejä. LMCache yksittäisessä vLLM-prosessissa ei avaa porttia lainkaan.
ZeroMQ-sokkeli ei sisällä autentikaatiota. Yksi viestityypistä puretaan Pythonin `pickle`-moduulin avulla, joka voi kuljettaa ja suorittaa koodia purkuhetkellä. Palvelin purkaa viestin lukemisen aikana, ennen kuin se tarkistaa viestin tyypin, joten käsitelty viesti suorittaa lähettäjän koodin välittömästi. Vaikuttuneet versiot: 0.3.9 (lokakuu 2025) 0.5.5:een (uusin vakaa versio) sekä 0.5.6:n esivaiheversiot ja kehityskanta.
Korjaus tulee ennen kuin se julkaistaan, JFrog suosittelee, ettei moniprosessipalvelimelle anneta routattavaa osoitetta ja että portti jää paikallisen koneen tai luotettavan verkkoalueen sisään. Tulipalo parantaa riskin, mutta ei poista sitä — mikäli host voi edelleen yhdistää, se voi suorittaa koodia. LMCache ei ole julkaissut omaa turvallisuusvaroitustaan, ja JFrog ei tarjoa keinoa selvittää, onko palvelin jo hyökkäyksen kohteena ollut.
Eri päivää ennen CVE:n julkistamista, kuusi lisää GitHub-raporttia väitti epävarmistetun moniasiakkaan cache-pääsyn ja verkko-palveluiden käytön ilman kirjautumista – ei CVE:itä, ei ylläpitäjän vahvistusta. Siihen liittyvä vLLM:n DoS (CVE-2026-105756, CVSS 6.5) LMCache-moniprosessiyhteyksessä on jo korjattu vLLM 0.30.0:ssa. Malli – epävarmistettu socket pickle-yhteys – muistuttaa ShadowMQ:n löytöjä AI-inferointi-rakenteissa marraskuussa 2025.
Organisaatioille, jotka käyttävät AI-agentteja ja LLM-infrastruktuuria tuotannossa, tämä on välitön altistumisongelma: vahingossa 0.0.0.0:aan sidottu cache-palvelin muuttuu korjattomaksi RCE-pinnaksi. Kartoita kaikki vLLM/LMCache-asennukset, poista routable bindit ja segmentoi klusteriverkkoja.
LLM-varastotason suojaus on usein unohdettu haavoittuvuuksien hallinnassa, koska niitä käsitellään ”sisäisten suorituskyvykysosien” sijasta kuin hyökkäyspinta-alana. Käytännössä ne sijaitsevat GPU-solmujen vieressä, juoksevat usein rootina kontteissa ja voivat saavuttaa mallit, promptit ja joskus ympäristömuuttujien kautta injektoituja salaisuuksia. Siellä oleva pickle-RCE ei ole vain DoS: se voi tarkoittaa mallipainojen varastamista, prompt-injektiota muille työntekijöille ja pääsyä koko klusteriin. Vuonna 2025 opittu ShadowMQ-tunnusopetus säilyy voimassa: suoristusmuodot, jotka suorittavat koodia, eivät kuulu autentikoimattomien sokettien taakse.
Pohjoismaiset AI-laboratoriot, SaaS-yritykset ja julkisen sektorin pilotoinnit, jotka testaavat vLLM:ää, tulisi erityisesti tarkistaa Helm-karttoja ja Terraform-moduuleja, jotka kopioivat LMCache Kubernetes-esimerkin. Kaikkien rajapintojen kuuntelu on helppoa laboratoriossa, mutta vaarallista tuotannossa. Aseta ZeroMQ NetworkPolicyn, mTLS:n tai ainakin hostNetwork=false:n ja tiukan pod-CIDR:n taakse. Dokumentoi, kumpi tiimi vastaa varastosta – muuten päivitykset tulevat ”joku muun ongelmaksi”, kun varoitukset lopulta saapuvat.
Varasto LMCache 0.3.9–0.5.5 (ja RC-versiot). Jos moniprosessitilaa käytetään: varmista, että ZeroMQ kuuntelee vain paikallisella hostilla tai yksityisellä klusteriverkolla; poista routattavat sidotukset. Päivitä vLLM ≥0.30.0 CVE-2026-105756 -vulnerabiliteetin vuoksi. Valvo odottamattomia prosesseja/yhteyksiä LMCache-kontteereista. Aikaisemmin sovelletaan toimittajan korjausta, kun se julkaistaan — ennen sitä verkkoeristys on ainoa tehokas hallintakeino. Lisäksi arvioi, käytetäänkö pickleä muissa sisäisissä AI-palveluissa, ja korvaa mahdollisuuksien mukaan turvallisemmilla protokollilla.