Bleeding Llama: bug Ollama leak memoria su 300mila server

Bleeding Llama: bug Ollama leak memoria su 300mila server

Il 12 maggio 2026 Cyera ha reso pubblica CVE-2026-7482, una vulnerabilità critica nel caricatore GGUF di Ollama che permette a un attaccante remoto non autenticato di leggere l'intera memoria del processo. Con un punteggio CVSS di 9,1 e una stima di oltre 300.000 server potenzialmente esposti, il bug ribalta il paradosso della AI self-hosted: l'infrastruttura locale scelta per privacy e compliance si trasforma in una superficie di attacco remota capace di spillare API key, variabili d'ambiente e conversazioni utente.

Come funziona l'attacco: dal modello GGUF craftato al leak di memoria heap

Il cuore della falla risiede nel parser GGUF, il formato binario standard per i modelli Llama e compatibili. Ollama utilizza il package unsafe di Go per operazioni di quantizzazione nel percorso che va da fs/ggml/gguf.go a server/quantization.go, in particolare nella funzione WriteTo(). Questo bypass dei controlli di memory safety permette di leggere e scrivere direttamente su aree di memoria senza i vincoli usuali del runtime Go.

Quando un utente — o in questo caso un attaccante — carica un modello file tramite l'endpoint /api/create, il parser legge i metadati dei tensori senza validare le dimensioni dichiarate rispetto alla lunghezza effettiva del buffer allocato. Un file GGUF creato ad arte con offset o dimensioni gonfiate induce il ciclo di quantizzazione a leggere oltre i confini del buffer heap. Il risultato è un out-of-bounds read che espone blocchi arbitrari della memoria del processo Ollama, potenzialmente contenenti dati sensibili gestiti in precedenza.

Dalla /api/create alla /api/push: la catena di esfiltrazione remota

La criticità non si ferma al leak. L'attaccante può trasformare la memoria rubata in un artefatto esfiltrabile. Dopo aver triggerato l'out-of-bounds read, i dati leaked vengono incorporati nel nuovo modello quantizzato, che l'attaccante può caricare verso un registry esterno controllato tramite l'endpoint /api/push. In questo modo, ciò che resta invisibile sul server compromesso diventa disponibile a chi controlla la destinazione del push.

Secondo l'analisi di Cyera, i dati recuperabili includono variabili d'ambiente, API key, frammenti di codice proprietario, system prompt e persino conversazioni di utenti concorrenti. La catena è completamente remota e non richiede autenticazione, sfruttando la configurazione comune OLLAMA_HOST=0.0.0.0 che espone l'interfaccia REST su interfacce pubbliche.

Il paradosso della AI self-hosted: quando il locale diventa più pericoloso del cloud

La disclosure colpisce un presupposto diffuso tra le aziende che migrano modelli LLM on-premise: che il self-hosted impliciti maggiore sicurezza e controllo dei dati. Ollama, con oltre 170.000 stelle su GitHub, è diventato lo strumento standard per eseguire modelli locali senza dipendere da API cloud. Proprio questa adozione massifica la superficie di attacco: oltre 300.000 server stimati esposti globalmente, spesso senza autenticazione di default sugli endpoint REST.

L'assenza di un meccanismo nativo di autenticazione su /api/create e /api/push significa che chiunque raggiunga la porta del servizio può interagire con il motore di inference. Per le organizzazioni che collegano Ollama a strumenti di sviluppo come Claude Code, l'impatto si estende a tutti gli output degli strumenti che transitano per il server, accumulandosi nell'heap e rendendo il leak potenzialmente più ricco di informazioni.

"An attacker can learn basically anything about the organization from your AI inference — API keys, proprietary code, customer contracts, and much more" — Dor Attias, ricercatore Cyera

Chi è a rischio: oltre 300.000 server e l'assenza di autenticazione di default

Non esiste al momento una conferma di exploitation attiva in-the-wild, ma la combinazione di un exploit remoto non autenticato e di una popolazione di server ampia e spesso esposta rende il rischio immediatamente operativo. Le aziende che hanno distribuito Ollama su istanze cloud o server edge con binding su 0.0.0.0 si trovano nella condizione di offrire un accesso diretto al motore di parsing dei modelli senza barriere di accesso.

Il numero di 300.000 server è una stima basata sull'adozione globale del progetto e sulle configurazioni osservate, non il resoconto di un audit indipendente di endpoint scansionati. Ciò non diminuisce la gravità della minaccia, ma impone di trattare la cifra come indicatore di esposizione piuttosto che di breach avvenuti. Le versioni affette includono tutte le release di Ollama precedenti alla 0.17.1.

Cosa fare adesso

• Aggiornare immediatamente Ollama alla versione 0.17.1 o successiva, che contiene la patch per la vulnerabilità.
• Rimuovere o limitare la variabile OLLAMA_HOST=0.0.0.0, restringendo l'accesso alla rete locale o a segmenti protetti da VPN e firewall, evitando l'esposizione diretta su Internet.
• Imporre autenticazione e autorizzazione sugli endpoint REST, in particolare /api/create e /api/push, tramite reverse proxy con mTLS, API key o altro meccanismo, dato che Ollama non prevede auth nativa di default.
• Monitorare i log per richieste anomale a /api/create con file GGUF da fonti non trusted e verificare la presenza di push verso registry esterni non autorizzati.

Perché il formato modello è diventato un vettore d'attacco

La lezione di Bleeding Llama va oltre il singolo bug. In un ecosistema dove i file di modello sono binari eseguiti dal server di inference, il confine tra dato e codice si assottiglia. Il parser GGUF non è un semplice lettore di metadati, ma un motore che esegue trasformazioni matematiche su tensori con privilegi elevati. Quando quel motore utilizza primitive unsafe e salta i controlli di boundary, il formato stesso diventa un payload.

Per le aziende che hanno investito su Ollama per mantenere i dati in casa, la rivelazione di CVE-2026-7482 è un avvertimento strategico: il self-hosted è una scelta architetturale, non una garanzia di privacy. Senza hardening di rete, autenticazione e validazione rigorosa degli input, il server locale resta una miniera di segreti accessibile a chiunque sappia costruire il modello giusto.

Domande frequenti

Perché il package unsafe di Go ha reso possibile questo leak?

Ollama impiega il package unsafe nel percorso di quantizzazione per accedere direttamente ai tensori del file GGUF, bypassando i controlli di memory safety del runtime Go. Quando il parser non valida le dimensioni dichiarate dei tensori rispetto alla lunghezza reale del buffer, la funzione WriteTo() legge oltre i limiti del buffer heap, esponendo memoria arbitraria del processo.

L'aggiornamento a Ollama 0.17.1 basta a chiudere completamente la falla?

La versione 0.17.1 include la patch per CVE-2026-7482, ma non è verificato al momento se esistano varianti o bypass noti. Le fonti originali raccomandano di abbinare l'update a misure aggiuntive come segmentazione di rete e autenticazione degli endpoint, trattando l'aggiornamento come tassello necessario ma non sufficiente da solo.

L'esfiltrazione dipende necessariamente dall'endpoint /api/push?

La catena di exploit documentata da Cyera e The Hacker News prevede l'esfiltrazione dei dati leaked proprio tramite /api/push verso un registry controllato dall'attaccante. Non è tuttavia verificato se questo endpoint sia abilitato di default su tutte le distribuzioni; in ogni caso, limitarne l'uso e monitorarne le chiamate rappresenta una contromisura prioritaria.

Fonti

• https://thehackernews.com/2026/05/ollama-out-of-bounds-read-vulnerability.html
• https://letsdatascience.com/news/ollama-vulnerability-exposes-remote-process-memory-caf67e65
• https://www.reconbee.com/ollama-out-of-bounds-read-vulnerability-allows-remote-process-memory-leak/
• https://news.fyself.com/ollama-out-of-bounds-read-vulnerability-causes-remote-process-memory-leak/
• https://www.cyera.com/research/bleeding-llama-critical-unauthenticated-memory-leak-in-ollama

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

Fonti

• https://thehackernews.com/2026/05/ollama-out-of-bounds-read-vulnerability.html
• https://letsdatascience.com/news/ollama-vulnerability-exposes-remote-process-memory-caf67e65
• https://www.reconbee.com/ollama-out-of-bounds-read-vulnerability-allows-remote-process-memory-leak/
• https://news.fyself.com/ollama-out-of-bounds-read-vulnerability-causes-remote-process-memory-leak/
• https://www.cyera.com/research/bleeding-llama-critical-unauthenticated-memory-leak-in-ollama