Ollama, tre CVE critiche espongono la memoria dei LLM locali

Tre CVE critiche in Ollama: un file GGUF craftato leak l'intera memoria dei processi LLM, mentre l'updater Windows consente persistenza di malware all'avvio.

Contenuto

Ollama, tre CVE critiche espongono la memoria dei LLM locali
Ollama, tre CVE critiche espongono la memoria dei LLM locali

Il 18 maggio 2026 emergono tre vulnerabilità critiche in Ollama, lo strumento open source più diffuso per l'esecuzione locale di modelli linguistici: un file GGUF craftato consente a un attaccante remoto non autenticato di leggere l'intera memoria del processo, mentre due flaw nell'updater Windows aprono la strada a esecuzione persistente di codice. La concomitanza delle due catene di attacco espone a rischio concreto oltre 300.000 server spesso pubblici e privi di autenticazione, trasformando il modello stesso da asset a vettore di esfiltrazione.

Punti chiave
  • CVE-2026-7482 (CVSS 9.1): heap out-of-bounds read nel loader GGUF di Ollama prima della versione 0.17.1, causato da tensor offset e size eccedenti la lunghezza reale del buffer.
  • L'esfiltrazione di chiavi API, variabili d'ambiente e conversazioni avviene tramite l'endpoint /api/push verso un registry controllato dall'attaccante.
  • CVE-2026-42248 e CVE-2026-42249 (CVSS 7.7 ciascuno) colpiscono l'updater di Ollama su Windows dalle versioni 0.12.10 alla 0.17.5.
  • La combinazione di path traversal e mancata verifica della firma digitale permette di scrivere eseguibili arbitrari nella cartella Startup dell'utente, con esecuzione al prossimo login.

Il loader GGUF e l'heap out-of-bounds che spilla la memoria

La vulnerabilità di maggiore impatto è tracciata come CVE-2026-7482 e colpisce tutte le versioni di Ollama precedenti alla 0.17.1. Il difetto risiede nel parser del formato GGUF, il contenitore binario standard per i pesi dei modelli, ed è localizzato nelle funzioni fs/ggml/gguf.go e server/quantization.go, specificatamente nella routine WriteTo(). Quando un file GGUF presenta tensor offset e size eccedenti la lunghezza reale del buffer allocato, il server legge oltre i confini dell'heap, scatenando un out-of-bounds read che espone byte adiacenti della memoria del processo.

La gravità è ribadita dal punteggio CVSS pari a 9.1, che riflette la facilità di exploitation e l'assenza di requisiti di autenticazione. Secondo la descrizione riportata da CVE.org, durante la fase di quantizzazione il server effettua letture oltre il buffer heap allocato, rendendo possibile il dump silenzioso di informazioni sensibili senza crash o anomalie evidenti nel log. I ricercatori di Cyera hanno denominato la catena di attacco Bleeding Llama, evidenziando come il formato stesso del modello diventi un ingresso pericoloso.

Dalla memoria al registry: come /api/push trasporta i dati rubati

I dati spillati dalla memoria non rimangono inerti nel server. L'attaccante può impacchettarli all'interno di un artifact modello e caricarlo verso un registry esterno sfruttando l'endpoint /api/push. Questo meccanismo trasforma una lettura di memoria in un canale di esfiltrazione attiva, dove chiavi API, codice proprietario, prompt di sistema e conversazioni degli utenti lasciano l'infrastruttura sotto forma di peso di un modello apparentemente legittimo.

Il rischio è reso più insidioso dalla natura stessa del traffico: una push di modello verso un registry esterno non desta gli stessi sospetti di una connessione C2 classica, mimetizzandosi nel flusso operativo normale di chi scarica e redistribuisce pesi.

A sottolineare la portata del rischio, il ricercatore Dor Attias di Cyera ha dichiarato che un aggressore può apprendere praticamente ogni elemento sensibile legato all'inferenza AI: «An attacker can learn basically anything about the organization from your AI inference — API keys, proprietary code, customer contracts, and much more». La mancanza di autenticazione di default su molte installazioni esposte a Internet amplifica esponenzialmente la superficie di contatto, rendendo il server un punto di raccolta passivo per chiunque riesca a caricare un GGUF craftato.

L'updater Windows e la persistenza garantita nella Startup folder

"The path traversal writes attacker-chosen executables into the Windows Startup folder. The missing signature verification keeps them there: the post-write cleanup that would remove unsigned files on a working updater is a no-op on Windows. On the next login, Windows runs whatever was left behind." Bartłomiej Dmitruk, co-founder di Striga

In parallelo alla falla del loader, il client Windows di Ollama presenta due vulnerabilità concorrenti tracciate come CVE-2026-42248 e CVE-2026-42249, entrambe con punteggio CVSS pari a 7.7. La disclosure coordinata è stata gestita da CERT Polska. Le falle riguardano l'updater automatico nelle versioni comprese tra la 0.12.10 e la 0.17.5: un path traversal consente di scrivere file eseguibili arbitrari in directory fuori dal percorso previsto, mentre la mancata verifica della firma digitale impedisce al meccanismo di pulizia post-aggiornamento di rimuovere i binari non firmati.

La conseguenza pratica è una compromissione duratura. Come spiegato dal co-founder di Striga Bartłomiej Dmitruk, il path traversal deposita eseguibili scelti dall'attaccante nella cartella Startup dell'utente. La verifica firma assente blocca la pulizia automatica, trasformando l'updater in un veicolo di persistenza. Al successivo login di Windows, il sistema esegue silenziosamente quanto viene lasciato in quella directory, senza richiedere ulteriori interazioni da parte della vittima.

Oltre 300.000 server: quando l'AI locale diventa superficie d'attacco

L'adozione massiccia di Ollama — con oltre 171.000 stelle e più di 16.100 fork su GitHub — ha creato una nuova categoria di infrastruttura che gli esperti definiscono l'IoT dei linguaggi. Server di inferenza sparsi su cloud e uffici, spesso accesi da sviluppatori per test rapidi e poi dimenticati in produzione senza autenticazione, espongono endpoint HTTP a Internet. In questo scenario, la vulnerabilità del parser GGUF non è un bug di nichia: è un accesso diretto alla memoria di processi che trattano dati aziendali sensibili.

Cyera stima che siano oltre 300.000 i server globalmente potenzialmente impattati, una cifra non verificata indipendentemente al momento della pubblicazione e da considerare con cautela. Non è inoltre confermata un'exploitation attiva in the wild per CVE-2026-7482, né è nota una data certa per il rilascio delle patch relative alle vulnerabilità Windows. Questi limiti non attenuano il rischio strutturale: la combinazione di un parser binario non sufficientemente robusto, endpoint pubblici privi di autenticazione e meccanismi di aggiornamento con mancata verifica firma disegna un profilo di minaccia concreto per le aziende.

Cosa fare adesso

  • Aggiornare Ollama alla versione 0.17.1 o successiva per chiudere la falla CVE-2026-7482 nel loader GGUF, l'unica fix disponibile al momento.
  • Isolare le istanze dalla rete pubblica rimuovendo l'esposizione su Internet degli endpoint, in particolare disabilitando l'accesso a /api/push dove non strettamente necessario.
  • Attivare autenticazione e segmentazione di rete per impedire che chiunque possa caricare modelli arbitrari sui server di inferenza, riducendo la superficie di attacco iniziale.
  • Ispezionare la cartella Startup sui client Windows alla ricerca di eseguibili non firmati, monitorando il rilascio di patch per le versioni 0.12.10-0.17.5 dato che non è nota una data certa per la correzione di CVE-2026-42248 e CVE-2026-42249.

L'incidente conferma che l'infrastruttura AI locale non è un'isola sicura: quando il modello stesso diventa input non affidabile, ogni assumzione sulla perimetrazione crolla. Per le aziende che hanno spinto l'adozione di Ollama in produzione senza autenticazione, il conto arriva sotto forma di memoria leaked e persistenza garantita.

Domande frequenti

Come fa un file di modello GGUF a leakare la memoria del server?

Il file GGUF contiene metadati che descrivono offset e dimensioni dei tensor. Se questi valori superano la lunghezza reale del buffer allocato, la routine di quantizzazione in server/quantization.go (WriteTo()) prosegue la lettura oltre i confini dell'heap, spillando byte contigui che possono includere chiavi API, variabili d'ambiente e frammenti di conversazione.

Qual è il rischio concreto per chi usa Ollama su Windows?

Le versioni 0.12.10-0.17.5 sono vulnerabili a path traversal e mancata verifica firma nell'updater. Un attaccante può scrivere eseguibili arbitrari nella cartella Startup dell'utente; al login successivo Windows li esegue automaticamente, garantendo persistenza senza che l'utente debba eseguire un nuovo file a mano.

Perché l'assenza di autenticazione rende tutto più pericoloso?

Molte installazioni di Ollama vengono esposte direttamente su Internet per comodità di accesso. Senza autenticazione di default, chiunque può caricare un modello GGUF craftato e attivare la catena di leak, o interagire con l'updater compromesso, trasformando il server in una sorgente passiva di esfiltrazione dati.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Link utili

Apri l'articolo su DeafNews