LMCache espone i server AI a RCE: una porta ZeroMQ può dare root

🛡️ Executive Summary

• CVE-2026-105192 consente remote code execution non autenticata nelle installazioni LMCache che espongono il trasporto multiprocess a una rete raggiungibile.
• Il server decodifica un’estensione msgpack attraverso DeviceIPCWrapper.Deserialize, che utilizza pickle.loads prima dell’elaborazione della richiesta.
• La porta predefinita è 5555 e i container ufficiali eseguono il processo come root: al momento della disclosure il record CVE non indica una versione corretta.

Una funzione costruita per accelerare l’inferenza dei modelli linguistici può trasformarsi in una porta di ingresso al server AI. CVE-2026-105192 colpisce LMCache nel funzionamento multiprocess, utilizzato per condividere blocchi della KV cache tra processi e nodi. La vulnerabilità combina due errori particolarmente pericolosi: il trasporto ZeroMQ non richiede autenticazione e alcuni dati ricevuti vengono deserializzati attraverso pickle.loads, funzione Python che non deve essere utilizzata su input non fidati. In una configurazione raggiungibile dalla rete, un messaggio costruito ad hoc può quindi produrre esecuzione di codice prima ancora che la logica applicativa abbia elaborato la richiesta.

LMCache trasforma la KV cache in una superficie di attacco

LMCache nasce per evitare che i sistemi di inferenza debbano ricostruire continuamente le stesse informazioni intermedie generate dal modello. Nel funzionamento multiprocess o distribuito, worker basati su ecosistemi come vLLM possono registrarsi e condividere blocchi della KV cache attraverso un trasporto dedicato. Il design ufficiale di DeviceIPCWrapper nel repository LMCache mostra che la serializzazione e la deserializzazione dei wrapper utilizzano pickle.dumps e pickle.loads. Questa scelta conserva l’identità delle classi Python attraverso il collegamento IPC, ma introduce una proprietà nota e pericolosa: deserializzare con pickle dati controllabili da un attaccante può provocare esecuzione arbitraria di codice. Nel caso LMCache il problema diventa remoto perché quel meccanismo viene raggiunto attraverso il trasporto ZeroMQ.

Leggi anche: Rischi AI imminenti: agenti, superintelligenza e decentralizzazione

CVE-2026-105192 non richiede autenticazione

Il record CVE assegnato da JFrog identifica due debolezze: deserializzazione di dati non affidabili e assenza di autenticazione per una funzione critica. Il server multiprocess apre un ZeroMQ ROUTER attraverso il quale i worker possono registrarsi e condividere la cache; i messaggi utilizzano msgpack e l’extension code 1 viene inoltrato a DeviceIPCWrapper.Deserialize. La criticità sta nell’ordine delle operazioni: la deserializzazione avviene durante la decodifica degli argomenti e prima che l’handler della richiesta entri effettivamente in funzione. Non serve quindi superare un controllo applicativo successivo. Secondo il record CVE, un singolo client ZeroMQ capace di raggiungere il trasporto può inviare il contenuto malevolo alla porta predefinita 5555 ed eseguire codice con i privilegi del processo LMCache.

Il vero salto di rischio arriva quando il server diventa distribuito

Nella configurazione locale il trasporto è normalmente associato a localhost, condizione che limita fortemente l’esposizione remota. Il problema cambia quando LMCache viene distribuito su più nodi e l’operatore configura --host con un indirizzo raggiungibile dagli altri sistemi. È precisamente ciò che serve per creare un’architettura distribuita, ma significa anche spostare una componente nata con un modello di fiducia IPC dentro un contesto di rete. Una fiducia implicita tra processi diventa così fiducia implicita tra macchine. Se la porta di trasporto è raggiungibile da una rete non sufficientemente segmentata, un attaccante non deve compromettere il modello né manipolare prompt: può aggredire direttamente l’infrastruttura che trasferisce lo stato dell’inferenza.

I container ufficiali aumentano l’impatto perché il processo può essere root

La conseguenza diventa più grave per le installazioni basate sulle immagini container ufficiali indicate nella disclosure. Il processo LMCache può essere eseguito come root, quindi il codice ottenuto attraverso la deserializzazione eredita quei privilegi all’interno dell’ambiente compromesso. Questo non significa automaticamente controllo dell’host fisico o del cluster: isolamento del runtime, capability, mount e configurazione orchestrativa determinano quanto sia possibile proseguire oltre il container. Significa però che l’applicazione vulnerabile non dispone necessariamente di un secondo limite di privilegio capace di contenere l’RCE. Nei cluster AI, dove volumi, credenziali di servizio, socket e risorse GPU possono essere condivisi, la differenza tra un processo applicativo limitato e un processo root è tutt’altro che accademica.

Chi rischia: non ogni LMCache esposto è ugualmente vulnerabile

La condizione prioritaria da verificare è l’utilizzo della modalità multiprocess o distribuita e la raggiungibilità del trasporto ZeroMQ. Una installazione confinata a localhost presenta un’esposizione molto diversa da un cluster nel quale la porta 5555 è raggiungibile attraverso una VLAN ampia, una rete container permissiva o, nel caso peggiore, dall’esterno. Gli amministratori devono quindi cercare la vulnerabilità nell’architettura reale e non soltanto nella distinta software: versione LMCache, modalità di esecuzione, parametro --host, regole firewall, identità del processo e privilegi del container sono gli elementi che determinano il rischio concreto. Il record pubblicato il 7 ottobre considera interessata la linea introdotta con LMCache 0.3.9 e non indica ancora una release corretta, rendendo particolarmente importante il contenimento della superficie.

Continua con:

Claude Code Security usa l’AI per cercare vulnerabilità nel software

Come mitigare LMCache finché non arriva una correzione ufficiale

In assenza di una versione corretta dichiarata nella disclosure iniziale, la risposta più prudente è ridurre la raggiungibilità del componente vulnerabile. La porta 5555 non dovrebbe essere accessibile da reti non fidate, il trasporto va mantenuto su localhost quando l’uso distribuito non è indispensabile e i cluster multi-node devono limitare l’accesso esclusivamente ai peer necessari attraverso firewall o policy di rete. Eseguire LMCache con il minimo privilegio possibile riduce inoltre le conseguenze di un’eventuale RCE, così come il monitoraggio di connessioni inattese verso il trasporto e di processi figli anomali. La vulnerabilità dimostra soprattutto un problema più generale: l’infrastruttura AI non è composta soltanto dal modello. Cache, runtime, sistemi IPC e acceleratori sono diventati software di produzione e devono essere trattati con lo stesso modello di minaccia riservato a database, API gateway e control plane cloud.