L’architettura distribuita di LMCache presenta una vulnerabilità critica che può consentire a un client di rete non autenticato di eseguire codice sfruttando la deserializzazione non sicura di Python. La falla, CVE-2026-105192, ha ottenuto un punteggio CVSS v3.1 di 9.8 CRITICAL.
JFrog, autorità di numerazione CVE per questa vulnerabilità, ha pubblicato e aggiornato la relativa scheda CVE il 7 ottobre 2026. Lo stesso giorno, i ricercatori di sicurezza dell’azienda hanno divulgato la vulnerabilità e attribuito la scoperta a Yuval Moravchick.
Il rischio dipende dalla configurazione. Per impostazione predefinita, LMCache associa il trasporto vulnerabile a localhost, ma gli operatori possono esporlo su un indirizzo raggiungibile in rete per le distribuzioni multi-nodo. Al momento della divulgazione, le fonti non indicavano una versione di LMCache con la correzione né fornivano prove verificate di attacchi contro sistemi in produzione.
Un messaggio di rete raggiunge pickle.loads prima dell’autenticazione
LMCache è un software open source per la gestione della cache, progettato per accelerare sistemi di inferenza basati su modelli linguistici di grandi dimensioni, come vLLM. Il componente vulnerabile è la modalità multiprocesso, detta anche modalità distribuita: LMCache opera come server di cache separato e comunica con i worker tramite ZeroMQ.
Secondo la scheda del programma CVE, il server apre un socket ZeroMQ ROUTER, usato dai worker per registrarsi e scambiare blocchi della cache KV. Il socket non autentica i client.
I messaggi vengono codificati con msgpack. Durante la decodifica, il codice di estensione 1 viene passato a DeviceIPCWrapper.Deserialize, che invoca Python pickle.loads su dati controllati dal mittente. È importante notare che la deserializzazione avviene mentre il server sta ancora elaborando gli argomenti della richiesta, prima dell’esecuzione del relativo gestore dei messaggi.
Un aggressore in grado di raggiungere il trasporto può quindi inviare un singolo messaggio ZeroMQ DEALER appositamente costruito e provocare l’esecuzione di codice con l’account che esegue LMCache. Non sono necessarie credenziali né interazioni da parte dell’utente.
Il vettore assegnato è:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
La vulnerabilità è classificata sia come CWE-306, mancata autenticazione per una funzione critica, sia come CWE-502, deserializzazione di dati non attendibili.
L’esposizione remota dipende da come viene associata la porta 5555
Il trasporto vulnerabile usa per impostazione predefinita la porta 5555. In assenza di un indirizzo raggiungibile in rete specificato dall’operatore tramite --host, resta in ascolto solo su localhost; configurando un indirizzo di questo tipo, i worker di altri nodi possono connettersi.
Di conseguenza, un’installazione che usa l’associazione locale predefinita non è raggiungibile da un altro host tramite questa interfaccia. L’esposizione cambia se il servizio viene associato all’indirizzo del cluster, a tutte le interfacce o a un altro endpoint accessibile in rete.
Secondo la segnalazione originale, l’esempio di distribuzione Kubernetes di LMCache avvia il server su tutte le interfacce di rete. La stessa fonte riferisce che un’istanza di LMCache integrata in un singolo processo vLLM non apre la porta vulnerabile.
Nella descrizione di JFrog si legge che le immagini container ufficiali di LMCache eseguono il processo come root. In queste immagini, un attacco riuscito potrebbe quindi eseguire codice con privilegi di root nell’ambiente in cui opera il processo. Questo non vale automaticamente per le installazioni configurate per eseguire LMCache con un account meno privilegiato e non dimostra quali risorse dell’host siano accessibili da un determinato container.
Nelle fonti citate non risultano attacchi verificati in natura. L’analisi tecnica dimostra che è possibile ottenere l’esecuzione remota di codice se il socket è raggiungibile, ma ciò non costituisce una prova di compromissioni reali.
Le fonti riportano intervalli diversi per le versioni di LMCache
La scheda CVE ufficiale indica come vulnerabile LMCache 0.3.9, senza specificare una versione limite superiore. I riferimenti della scheda rimandano a codice vulnerabile sia in v0.3.9 sia in v0.5.5.
La notizia indica un intervallo più ampio: le versioni dalla 0.3.9 alla 0.5.5, le release candidate 0.5.6 e il ramo di sviluppo. Descrive la 0.5.5 come l’ultima versione stabile e riporta che la versione 0.3.9 è stata rilasciata nell’ottobre 2025.
Le due affermazioni si basano su evidenze di diversa portata. La scheda dell’autorità di numerazione CVE conferma che la 0.3.9 è interessata, mentre le informazioni più ampie sulle versioni e sul ramo di sviluppo provengono dalla notizia e non da una dichiarazione completa dell’intervallo vulnerabile nella scheda CVE fornita.
Al momento della divulgazione non era stata indicata alcuna versione corretta di LMCache. La scheda CVE non riporta una versione con la correzione e, secondo le fonti, il 7 ottobre 2026 non era ancora disponibile una release aggiornata.
La misura difensiva immediata è isolare il servizio dalla rete
Le raccomandazioni provvisorie di JFrog, riportate dalla fonte, puntano a impedire ai sistemi non attendibili di raggiungere il trasporto ZeroMQ:
- Non associare il server multiprocesso a un indirizzo raggiungibile in rete finché non sarà disponibile una versione corretta.
- Se non è necessaria l’esecuzione distribuita, mantenere il servizio su localhost.
- Se i worker remoti devono connettersi, limitare l’accesso a una rete cluster attendibile.
- Applicare regole firewall alla porta 5555 e consentire solo le connessioni dei peer necessari.
Il filtraggio tramite firewall riduce la superficie di attacco raggiungibile, ma non elimina la deserializzazione non sicura. Qualsiasi host autorizzato o compromesso che possa connettersi al socket potrebbe comunque inviare il messaggio malevolo.
Gli operatori dovrebbero inoltre verificare quale account esegue il processo LMCache e ridurne al minimo i privilegi. In questo modo si limitano le possibili conseguenze, ma non si corregge il codice vulnerabile.
La fonte riferisce che l’avviso di JFrog non includeva una procedura per determinare se la vulnerabilità fosse già stata sfruttata. Il materiale citato non fornisce nemmeno indicatori di compromissione né query forensi per CVE-2026-105192; ciò vale per le informazioni disponibili e non dimostra che indicazioni del genere non esistano altrove.
Una vulnerabilità distinta di vLLM può arrestare EngineCore
Un problema correlato ma tecnicamente distinto riguarda le distribuzioni di vLLM che usano il connettore KV integrato LMCache-MP. CVE-2026-105756 consente a un valore cache_salt non valido di causare un’eccezione non gestita e arrestare EngineCore.
La vulnerabilità ha un punteggio CVSS v3.1 di 6.5 ed è classificata come Moderate:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
È classificata come CWE-20, convalida inadeguata dell’input, e CWE-248, eccezione non gestita. A differenza della vulnerabilità RCE di LMCache, il vettore indica che sono richiesti privilegi bassi e che l’impatto riguarda solo la disponibilità.
I modelli compatibili con OpenAI per Completions, Chat Completions e Responses accettano qualsiasi valore cache_salt non vuoto, ma IPCCacheServerKey di LMCache-MP impone ulteriori restrizioni. Rifiuta i salt più lunghi di 128 caratteri o contenenti @, /, \ o NUL.
Questi vincoli non venivano applicati prima che il valore raggiungesse la ricerca della cache nello scheduler. Secondo il Security Advisory di GitHub, un salt rifiutato genera un ValueError che non viene intercettato dal connettore né dallo scheduler. EngineCore considera quindi fatale l’eccezione, interrompendo il servizio per gli utenti con richieste in corso. L’avviso cita cache_salt="/" come esempio.
Il problema è stato confermato in vLLM 0.25.1, commit 752a3a504485, e riguarda solo le installazioni che hanno attivato il connettore LMCache-MP. Questo connettore richiede lmcache >= 0.4.4.
La descrizione NVD e l’intervallo indicato nell’avviso generale considerano vulnerabili le versioni precedenti alla 0.30.0 e indicano la 0.30.0 come versione corretta. Tuttavia, un altro campo dell’avviso riporta come versioni corrette >= 30.0.0. Questo valore incoerente non va considerato automaticamente equivalente: gli operatori dovrebbero verificare la versione del pacchetto che intendono distribuire. L’avviso è stato pubblicato il 23 settembre 2026 e la fonte riferisce che vLLM 0.30.0 è stata rilasciata il 22 settembre.
Altre segnalazioni su LMCache non sono state confermate
La fonte descrive anche sei altre segnalazioni di sicurezza su LMCache, aperte da un account GitHub il 6 ottobre 2026. Le segnalazioni denunciano l’accesso ai dati memorizzati nella cache di altri tenant e l’accesso non autenticato a servizi di rete in grado di eseguire comandi.
Nelle fonti citate, queste segnalazioni non hanno un identificativo CVE, una conferma dei maintainer né una correzione associata. Si basano su affermazioni accompagnate da proof of concept e sono distinte da CVE-2026-105192.
Una segnalazione sostiene che in 0.5.5 un server HTTP amministrativo fosse in ascolto su tutte le interfacce, mentre le release candidate 0.5.6 lo limiterebbero a localhost. Finché i maintainer non convalidano le affermazioni alla base di queste segnalazioni, non andrebbero presentate come vulnerabilità confermate di LMCache.
Lo schema insicuro alla base di CVE-2026-105192 ricorda l’uso di messaggistica non autenticata insieme a Python pickle, discusso dai ricercatori nel novembre 2025 con il nome ShadowMQ. Le fonti non dimostrano che questi risultati precedenti e LMCache condividano codice o abbiano un’origine comune.
