Kritisk LMCache-hull (CVSS 9,8) gir kodekjøring uten innlogging, og ingen rettelse finnes

En kritisk sårbarhet i LMCache, programvaren som mellomlagrer KV-cache for LLM-servere som vLLM, lar en angriper uten innlogging kjøre kode på cache-serveren. JFrog offentliggjorde feilen 7. oktober med alvorlighetsgrad 9,8 av 10, skriver The Hacker News, og den spores som CVE-2026-105192. Rammet er alle versjoner fra 0.3.9, sluppet i oktober 2025, til 0.5.5, som er siste stabile utgave på PyPI. Release-kandidatene for 0.5.6 til og med rc3 og dev-grenen har samme feil.

Feilen ligger i multiprosess-modusen, der cachen kjører som en frittstående server som LLM-workerne når via meldingsbiblioteket ZeroMQ. Socketen har verken CURVE, ZAP, passord eller meldingsautentisering. Én meldingstype pakkes ut med pickle mens serveren fortsatt leser argumentene, før noen typesjekk, så én enkelt melding til port 5555 kjører avsenderens kode. I prosjektets offisielle container-images kjører prosessen som root, ifølge JFrog.

«Stop passing network bytes to pickle.» — JFrog, i sikkerhetsvarselet for CVE-2026-105192

Om du er utsatt, avgjøres av én innstilling. Som standard lytter serveren bare på localhost, og LMCache brukt inne i én enkelt vLLM-prosess åpner ikke porten i det hele tatt. Den blir nåbar når du starter den med --host satt til en rutbar adresse, slik flernode-oppsett gjør for å dele cache mellom maskiner. LMCaches eget eksempel på Kubernetes-utrulling starter serveren nettopp slik, og lytter på alle nettverksgrensesnitt.

«A firewall that limits who can reach the port lowers the risk but does not remove it, because any host that can still open a connection can run code.» — The Hacker News

LMCache har ikke publisert noe eget sikkerhetsvarsel, og JFrog gir ingen måte å avgjøre om en server allerede er angrepet. Dagen før, 6. oktober, åpnet én GitHub-bruker seks andre sikkerhetsrapporter mot prosjektet om uautentisert tilgang til andre leietakeres cachede data og om nettverkstjenester som kjører kommandoer uten innlogging. De har verken CVE, bekreftelse fra vedlikeholderne eller rettelse. En beslektet feil i vLLM er allerede tettet: CVE-2026-105756 (CVSS 6,5) lot én forespørsel med ugyldig cache_salt krasje motoren på oppsett med LMCaches multiprosess-connector, og er rettet i vLLM 0.30.0.

Bakgrunn

Grunnfeilen, data fra en uautentisert nettverkssocket rett inn i pickle, er den samme som forskere fant i flere andre inferensrammeverk i november 2025 under navnet ShadowMQ. Om LMCache deler kode med dem, er ikke avklart. Prosjektet har nesten 12 000 stjerner på GitHub. Kjører du vLLM med LMCache på én maskin med standardinnstillingene, er porten ikke nåbar fra andre maskiner. Risikoen ligger i klynger og flernode-oppsett der porten står åpen på et delt nettverk.

Hva bør du gjøre?

1. Sjekk om LMCache-serveren lytter på en rutbar adresse, for eksempel med ss -ltnp | grep 5555, og se etter --host 0.0.0.0 i oppstartskommandoen eller Kubernetes-manifestet.
2. Bind multiprosess-serveren til localhost eller et betrodd klyngenettverk til en rettet versjon er sluppet, og stol ikke på brannmuren alene.
3. Oppgrader vLLM til 0.30.0 eller nyere hvis du bruker LMCaches multiprosess-connector.