LMCache, vulnerabilità critica 9,8 senza patch: a rischio i server vLLM

Se usi LMCache per accelerare i modelli linguistici serviti con vLLM, oggi hai un motivo concreto per controllare come è configurato il tuo cluster. Il 7 ottobre 2026 i ricercatori di JFrog hanno reso pubblica una vulnerabilità critica, tracciata come CVE-2026-105192 e valutata 9,8 su 10, che permette di eseguire codice da remoto senza alcuna autenticazione. Al momento della scrittura non esiste una versione corretta.

Il problema riguarda un componente molto diffuso nell’infrastruttura di inferenza e, come spesso accade con i bug di questo tipo, il rischio dipende quasi interamente da come viene distribuito il servizio.

Che cos’è LMCache e perché conta nell’inferenza

LMCache è un progetto open source che gestisce la cache dei valori chiave e query (la cosiddetta KV cache) usata dai server di inferenza come vLLM. In parole semplici, evita di ricalcolare ciò che il modello ha già elaborato per prompt ripetuti o molto lunghi, riducendo latenza e costo per token. Per questo è entrato nelle architetture di chi serve modelli a scala, soprattutto quando più nodi devono condividere la stessa cache.

È proprio questa condivisione a fare la differenza. Quando LMCache lavora dentro un singolo processo vLLM, non apre alcuna porta di rete. Quando invece viene usato in modalità multiprocesso, i worker comunicano con un server di cache autonomo tramite ZeroMQ, ed è qui che nasce la falla.

Il contesto: più cache, più superficie d’attacco

Negli ultimi mesi la corsa a ridurre i costi dell’inferenza ha spinto molte aziende a spostare la cache fuori dal processo del modello, a condividerla tra GPU e a distribuirla su più macchine. È un’ottimizzazione sensata, ma ogni componente che ascolta su una porta di rete diventa un potenziale bersaglio. Se lavori con hardware locale per far girare modelli, come quello descritto nella nostro articolo sul NVIDIA DGX Spark da 64 GB, vale la pena ricordare che anche un singolo server di test esposto per errore può diventare un punto d’ingresso.

Come funziona la vulnerabilità CVE-2026-105192

Secondo la scheda pubblicata sul registro delle vulnerabilità, in modalità multiprocesso LMCache apre un socket ZeroMQ di tipo ROUTER senza alcuna autenticazione, di default sulla porta 5555. Un messaggio contiene un tipo di estensione msgpack che viene decodificato con pickle prima ancora che venga eseguito qualsiasi controllo sul tipo di messaggio.

Pickle è il formato di serializzazione di Python e, per progetto, può eseguire codice arbitrario durante la deserializzazione. Basta quindi un singolo messaggio costruito ad arte per far girare comandi sul server.

La classificazione tecnica rimanda a due debolezze note: l’assenza di autenticazione per una funzione critica e la deserializzazione di dati non attendibili. Il punteggio 9,8 riflette lo scenario peggiore, cioè un server raggiungibile dalla rete, senza interazione dell’utente e con impatto totale su riservatezza, integrità e disponibilità.

Chi è davvero a rischio

Il server ascolta solo su localhost per impostazione predefinita, quindi una installazione standard non è automaticamente esposta. Il rischio scatta quando un operatore lo collega a un indirizzo raggiungibile dalla rete, cosa che le configurazioni multinodo richiedono. JFrog segnala anche che l’esempio di DaemonSet Kubernetes fornito dal progetto mette il servizio in ascolto su tutte le interfacce, e che le immagini container ufficiali eseguono il processo come utente root.

Il codice arriva quindi con i privilegi più alti disponibili nel container.

Le versioni coinvolte vanno dalla 0.3.9, rilasciata a fine ottobre 2025, fino alla 0.5.5, l’ultima stabile. Risultano interessate anche le release candidate della 0.5.6 e il ramo di sviluppo.

Cosa sappiamo (e cosa no) sulla risposta del progetto

Il dato più delicato è l’assenza di una patch. Stando a quanto riportato da The Hacker News, il progetto non ha pubblicato un avviso di sicurezza e l’indicazione di JFrog non offre un modo per verificare se un server sia già stato attaccato. Per questo motivo la mitigazione oggi è tutta nelle mani di chi gestisce l’infrastruttura.

Il 6 ottobre un account GitHub ha inoltre aperto sei segnalazioni non verificate, che parlano di accesso ai dati tra tenant diversi e di altre esecuzioni di comandi senza autenticazione. Non hanno un CVE, né una conferma dei manutentori, né una correzione, quindi vanno trattate con cautela, ma indicano che il codice potrebbe meritare un audit più ampio.

Un pattern già visto

Lo schema, cioè pickle su un socket non autenticato, richiama le falle del filone ShadowMQ scoperte in altri framework di inferenza nel novembre 2025. Non è confermato che LMCache condivida codice con quei progetti, ma il filo conduttore è chiaro: la fretta di scalare l’inferenza ha portato molti strumenti a trattare la rete interna come un ambiente fidato.

Cosa fare subito se usi LMCache

In attesa di una versione corretta, le indicazioni di JFrog sono pragmatiche e puoi applicarle oggi stesso. Eccole in sintesi:

• verifica se usi la modalità multiprocesso e su quale indirizzo è collegato il server di cache;
• limita l’accesso a localhost o a una rete di cluster realmente fidata, mai a interfacce pubbliche;
• non copiare alla lettera l’esempio di DaemonSet che apre il servizio su tutte le interfacce;
• esegui il processo come utente non privilegiato, invece di affidarti al root dell’immagine ufficiale.

Un firewall riduce il rischio ma non lo elimina, perché qualsiasi host che riesca a connettersi può comunque sfruttare il difetto. Conviene quindi segmentare la rete e controllare quali macchine hanno davvero bisogno di parlare con la cache.

Tieni d’occhio anche il repository del progetto e la scheda CVE: appena arriverà una release corretta, l’aggiornamento diventerà la priorità.

Una questione di sicurezza dell’intera filiera AI

Il caso arriva in una settimana in cui la sicurezza informatica legata all’AI è già al centro dell’attenzione. Abbiamo raccontato, per esempio, il programma Anthropic Cyber Mission, pensato per difendere infrastrutture critiche e progetti open source con l’aiuto di modelli di frontiera. Strumenti di scansione automatica come quelli descritti possono aiutare a scovare proprio questo tipo di errori, ma richiedono comunque processi di sviluppo che trattino ogni porta di rete come potenzialmente ostile.

Il tema tocca anche chi costruisce agenti e flussi automatizzati. Se stai valutando piattaforme come l’agente persistente di Gemini per Google Cloud, ricorda che ogni agente che lavora per giorni poggia su uno strato di inferenza e di cache che va protetto con la stessa cura del resto dello stack.

Perché questa vulnerabilità ci riguarda tutti

La cache dell’inferenza non è un dettaglio da specialisti. Contiene frammenti di prompt, documenti e dati degli utenti, quindi un attaccante che entra nel server può avere accesso a informazioni sensibili oltre che alla capacità di calcolo, spesso costosa, delle GPU. In un’epoca in cui le aziende caricano nei modelli contratti, codice e dati clienti, la protezione di questi componenti non è meno importante di quella del database.

La lezione è semplice: ottimizzare le prestazioni senza ripensare la sicurezza crea debito tecnico. Le configurazioni di esempio vanno lette come punto di partenza, non come ricetta da portare in produzione.

Conclusioni: controlla oggi, aggiorna appena possibile

CVE-2026-105192 è una vulnerabilità seria ma gestibile, a patto di sapere dove gira LMCache e come è esposto. Fai un inventario dei tuoi server di inferenza, verifica gli indirizzi di ascolto, riduci i privilegi dei processi e segui gli aggiornamenti del progetto. Se hai già una configurazione multinodo, intervieni subito.

Vuoi restare al passo con le novità di sicurezza e infrastruttura AI? Continua a seguirci su intelligenzaartificiale.net e condividi questo articolo con chi gestisce i vostri server di inferenza.

Fonti consultate: la scheda CVE-2026-105192 e la cronaca di The Hacker News sull’analisi di JFrog, oltre al repository ufficiale di LMCache.