LMCache CVE-2026-105192: RCE non autenticata nella cache LLM, nessuna patch

Se gestisci inferenza LLM self-hosted su qualsiasi scala, quasi certamente hai davanti un livello di KV-cache, e con buona probabilità è LMCache — la cache open-source che sta tra i worker vLLM e conserva i tensori chiave-valore che rendono sostenibile il serving a contesto lungo e multi-turno. Il 7 ottobre 2026 il team di ricerca di JFrog ha divulgato CVE-2026-105192, un'esecuzione di codice remota non autenticata nel trasporto multiprocesso di LMCache. Un singolo messaggio di rete costruito ad arte verso la porta ZeroMQ della cache esegue il codice dell'attaccante con i privilegi del processo — root, nei container ufficiali. Non esiste una release corretta. L'unica cosa tra quella porta e un attaccante è la rete su cui l'hai messa.

Notizia in evoluzione — pubblicata alle 19:28 (17:28 UTC) del 7 ottobre 2026. Aggiornata man mano che JFrog, i manutentori di LMCache e CISA pubblicano altro.

In breve

CVE	CVE-2026-105192
Prodotto / versioni colpite	LMCache in modalità multiprocesso · da 0.3.9 (ottobre 2025) fino a 0.5.5 · release candidate 0.5.6 · branch di sviluppo
Corretta in	Nessuna release corretta al 2026-10-07
CVSS	9.8 Critica · CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H · assegnato da JFrog; NVD pubblicato 2026-10-07 (CWE-306; CWE-502)
Sfruttata attivamente	Nessuna evidenza al 2026-10-07 (JFrog)
CISA KEV	Non elencata (versione catalogo 2026.10.04)
PoC pubblico	Non rilasciato con l'advisory (JFrog, 2026-10-07)
Advisory ufficiale	JFrog JFSA-2026-001694382

Cos'è davvero CVE-2026-105192

LMCache può eseguire la cache come server autonomo che i worker vLLM raggiungono tramite ZeroMQ — la "modalità multiprocesso" che permette di scalare la capacità della cache indipendentemente dai worker del modello. Il trasporto è un socket ZeroMQ ROUTER non autenticato sulla porta 5555. I worker inviano messaggi tipizzati; il server li decodifica con msgpack.

Il bug è nel modo in cui un tipo di messaggio viene decodificato. Il messaggio REGISTER_KV_CACHE trasporta un'estensione msgpack (codice 1) il cui payload viene passato a pickle.loads dentro DeviceIPCWrapper.Deserialize. Pickle è un formato di serializzazione Python che può trasportare istruzioni eseguibili ed eseguirle mentre lo stream viene decodificato — è il sink canonico della deserializzazione non sicura (CWE-502). Il server estrae l'oggetto pickled mentre sta ancora leggendo gli argomenti del messaggio, prima di qualunque controllo sul tipo del messaggio. Così un messaggio costruito ad arte non deve essere una registrazione valida; deve solo raggiungere il socket. Quando viene decodificato, il codice del mittente va in esecuzione.

Sul socket non c'è autenticazione (CWE-306), quindi "raggiungere il socket" è l'intero exploit. JFrog l'ha valutata CVSS 9.8 per la configurazione esposta in rete.

L'unica buona notizia è il default: LMCache lega il trasporto multiprocesso a localhost a meno che un operatore non imposti un indirizzo instradabile. Il problema è che i deployment multi-nodo — quelli con le cache più grandi e più GPU dietro — fanno esattamente questo.

Chi è esposto

Rientri nel perimetro se sono vere tutte queste condizioni:

• Usi LMCache 0.3.9 o successiva (qualsiasi release fino a 0.5.5 inclusa, le release candidate 0.5.6, o un build dal branch di sviluppo).
• La esegui in modalità multiprocesso (un server di cache autonomo, non la libreria in-process).
• La porta multiprocesso (default 5555) è raggiungibile da una rete di cui non ti fidi del tutto — perché un operatore ha passato --host 0.0.0.0 o un altro indirizzo instradabile, perché un container/orchestratore ha pubblicato la porta, o perché la "rete di cluster fidata" include in realtà una subnet di pod che un attaccante può raggiungere.

Verificalo direttamente. Sull'host della cache, trova a cosa è legato il trasporto e chi può raggiungerlo:

# La porta multiprocesso di LMCache è in ascolto su un indirizzo instradabile?
ss -ltnp | grep -E ':5555|lmcache'

# Cerca nella config di avvio / nei manifest dell'orchestratore un host instradabile
grep -RniE 'lmcache|--host|LMCACHE_.*HOST|5555' /etc/ deploy/ k8s/ 2>/dev/null

# Da un altro host sullo stesso segmento di rete, riesci ad aprire la porta?
nc -vz <host-cache> 5555

Un 0.0.0.0:5555 nel primo comando, o una connessione riuscita dal terzo, significa che la cache è a un pacchetto dall'esecuzione di codice e non c'è una patch da installare.

Remediation

Non esiste una versione corretta, quindi qui la remediation non è "applica la patch e passa oltre". È un insieme di controlli compensativi da applicare subito e da ri-verificare, in ordine di priorità.

1. Sono colpito? Esegui i tre controlli qui sopra. Se la porta è solo su localhost e la modalità multiprocesso non è esposta, non sei raggiungibile dalla rete — resta allo step di monitoraggio e aspetta una release corretta.

2. Togli la porta dalla rete — questa è la fix fino a quando non c'è una patch. Secondo JFrog: non impostare --host su un indirizzo instradabile; tieni la porta multiprocesso su localhost o su una rete di cluster fidata e isolata. Se non ti serve la modalità multiprocesso, disabilitala e usa la cache in-process.

3. Non puoi cambiare la topologia ora? — metti un firewall sul socket. Limita la porta 5555 agli IP esatti dei worker che devono parlare con la cache, sia sul firewall dell'host sia a livello di rete. In Kubernetes, una NetworkPolicy default-deny con un allow esplicito solo dai pod worker di vLLM. Tratta la "rete interna" come non fidata: un sink pickle non autenticato non distingue un worker da qualsiasi altra cosa riesca ad aprire il socket.

4. Caccia la compromissione. JFrog non riporta sfruttamento in the wild al 2026-10-07, e non sono stati pubblicati IOC del vendor — quindi caccia sul comportamento, non sulle firme. Su ogni host di cache che è stato esposto in rete, cerca processi figli generati dal processo LMCache/Python (shell, curl/wget, interpreti), connessioni in uscita da un host che dovrebbe solo servire traffico di cache, e nuovi peer ZeroMQ su 5555 che non sono i tuoi worker noti. Mappalo su MITRE ATT&CK T1190 (sfruttamento di applicazione esposta) e T1059 (interprete di comandi/script). Poiché il codice gira come root nei container ufficiali, un exploit riuscito possiede il container e tutto ciò che il container può raggiungere — inclusi i pesi del modello e qualsiasi credenziale montata al suo interno.

5. Eradica e verifica. Un nodo di cache compromesso va ricostruito, non ripulito — una RCE via pickle dà all'attaccante codice first-stage arbitrario e non puoi enumerare cosa ha fatto. Ruota ogni segreto che risiedeva sul nodo o era raggiungibile da esso: token del registry dei modelli, chiavi dell'object store, token di service account. Poi conferma che la porta non sia più raggiungibile da reti non fidate, e continua a sorvegliare 5555 finché non giri su una release corretta.

Cosa non si sa ancora

• Nessuna release corretta. Al momento in cui scriviamo non esiste una versione patchata; la fix durevole dei manutentori sarà smettere di passare byte di rete a pickle (sostituire il serializzatore dietro l'estensione msgpack codice 1, aggiungere autenticazione CURVE o HMAC sul trasporto). Segui il repository LMCache per la release.
• Nessun inserimento in CISA KEV (catalogo 2026.10.04) e nessuno sfruttamento confermato. Questa è la finestra, non il cessato allarme: il meccanismo è pubblico, il sink è una singola chiamata pickle, e un exploit funzionante non è difficile da costruire dall'advisory.
• L'esposizione reale è sconosciuta. Quanti deployment LMCache girino in modalità multiprocesso su un indirizzo instradabile non è pubblicato. Se ne gestisci uno, conosci la risposta per la tua flotta dopo i controlli qui sopra — la maggior parte dei team non ha mai guardato.

L'asset che nessuno ha inventariato

Il problema onesto che CVE-2026-105192 espone non è pickle. È che lo stack di serving LLM è cresciuto più in fretta dell'inventario asset di chiunque. Un server di cache sulla porta 5555, tirato su per rendere l'inferenza più economica, non è nel CMDB, non è nel perimetro dello scanner, e non è nella lista delle cose che un pentest trimestrale guarda. Uno scanner a firme vede un ROUTER ZeroMQ e una porta in ascolto; non sa che un tipo di messaggio deserializza con pickle prima di controllare il proprio tipo. Il buco non è il bug — è che nessuno stava testando il livello di inferenza come superficie d'attacco.

È esattamente il buco che un red team AI autonomo chiude, ed è la domanda operativa che questa divulgazione solleva: senza patch disponibile, cosa faccio adesso, e in che ordine? L'AI Remediation Advisor di Zero Hunt è costruito per questo momento — classifica i rilievi per sfruttabilità reale (prima CISA KEV, poi ciò che è stato dimostrato raggiungibile sulla tua rete, poi CVSS ed EPSS), e per una falla non patchabile dà il controllo compensativo che rimuove davvero l'esposizione — qui, togliere il socket ZeroMQ da ogni interfaccia instradabile — con le note di rollout e rollback per applicarlo in sicurezza, poi ri-verifica rieseguendo la stessa prova che ha dimostrato il problema. Una stringa di versione è un'affermazione; una riesecuzione è una prova.

A monte, il motivo per cui l'Advisor ha qualcosa da classificare è che lo swarm di 10 agenti trova la cache in primo luogo. Girando in black-box sul tuo stesso perimetro, identifica un servizio di inferenza esposto per cui nessun feed CVE ha un plugin, scrive un proof-of-concept per-target con un modello locale — nessun exploit tirato da un repository pubblico, nessun prompt che lascia l'apparato — e lo ribacktesta nell'AI Gym prima che tocchi la produzione. Gira on-premise su AI privata con un umano nel loop per ogni azione che conta, così l'unica cosa che non farà mai è proprio ciò che questa CVE punisce: fidarsi di un messaggio non autenticato dalla rete. Per un quadro più ampio di come il testing continuo e provato per exploit differisca dal controllo di versione di uno scanner, vedi la nostra guida al penetration testing automatizzato e l'analisi parallela della RCE del gateway AI LiteLLM — l'ultima volta che lo stack di serving AI si è rivelato l'asset che nessuno aveva inventariato.