Bleeding Llama: Ollama leak di memoria su 300.000 server AI

Bleeding Llama: Ollama leak di memoria su 300.000 server AI

Il 2026-05-08 Cyera ha reso pubblica CVE-2026-7482, una vulnerabilità critica nel framework Ollama per l’inferenza locale di LLM che permette a un attaccante remoto non autenticato di leakare l’intera memoria del processo. Il difetto, soprannominato Bleeding Llama e valutato CVSS 9.1, si attiva caricando un file modello GGUF appositamente malformato su server spesso esposti su Internet senza autenticazione. L’incidente mette a dura prova l’idea che eseguire modelli AI on-premise implicitamente protegga dati e secret aziendali.

Come funziona l'exploit dal file GGUF alla memoria leakata

Il cuore del difetto risiede nel parser Go che Ollama utilizza per caricare i modelli nel formato GGUF, in particolare nei file fs/ggml/gguf.go e server/quantization.go. Durante la pipeline di quantizzazione, le funzioni WriteTo e ConvertToF32 impiegano il package unsafe per accedere direttamente ai buffer di memoria. Il loader si fida ciecamente del metadato interno del file che descrive l’offset, la shape e la dimensione del tensore. Se un attaccante confeziona un GGUF in cui tale valore è gonfiato oltre la lunghezza reale del buffer dati presente nel file, il server legge oltre i limiti allocati sulla heap. L’impiego del package unsafe, combinato con l’assenza di un sanity check tra il tensore dichiarato e la dimensione effettiva del buffer, elimina le garanzie di memory safety offerte da Go e apre la porta alla lettura arbitraria.

La catena di attacco è lineare e non richiede autenticazione. L’attaccante carica il file malformato con una semplice richiesta HTTP POST. La chiamata all’endpoint /api/create innesca la creazione del modello e quindi l’elaborazione del tensore, attivando l’out-of-bounds read. La memoria leakata viene incorporata nell’artefatto modello risultante, che può essere spinto tramite l’endpoint /api/push verso un registro controllato dall’attaccante, completando l’esfiltrazione.

Cosa finisce nella heap e perché basta un POST remoto

La memoria heap del processo Ollama non è isolata per sessione utente né bonificata tra le richieste. Al suo interno possono risiedere variabili d’ambiente, chiavi API, system prompt, frammenti di conversazioni concorrenti, codice proprietario e contratti cliente. Poiché il runtime Go gestisce la heap a livello di processo, i dati sensibili persistono per l’intera durata dell’esecuzione e non vengono isolati tra richieste successive. Un singolo caricamento remoto di un file modello “avvelenato” consente di riversare tutto questo materiale sensibile nelle mani di un attaccante senza che la vittima debba interagire attivamente.

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

Il ricercatore aggiunge che gli ingegneri spesso collegano Ollama a tool come Claude Code: "On top of that, engineers often connect Ollama to tools like Claude Code. In those cases, the impact is even higher -- all tool outputs flow to the Ollama server, get saved in the heap, and potentially end up in an attacker's hands." Quando un tool esterno streamma il proprio output verso il server locale, quel contenuto si deposita direttamente in memoria, espandendo la superficie di dati potenzialmente leakabili ben oltre i confini del singolo chatbot.

Perché Ollama finisce spesso esposto su Internet senza autenticazione

Ollama è diventato il riferimento de facto per chi vuole eseguire LLM on-premise, superando le 171.000 stelle su GitHub e registrando oltre 100 milioni di download su Docker Hub. Nonostante sia pensato per un uso locale, il framework non fornisce autenticazione out-of-the-box per la REST API ed è spesso configurato per ascoltare su 0.0.0.0 invece che su localhost. La facilità di installazione tramite Docker o script di automazione spinge spesso gli utenti a ignorare il parametro di binding di rete, lasciando il servizio accessibile da qualsiasi indirizzo IP raggiunga la macchina. Questa combinazione trasforma installazioni aziendali in endpoint pubblici non protetti, specialmente quando il container o il servizio viene spostato su una LAN interna priva di segmentazione.

Cyera stima che oltre 300.000 server Ollama siano esposti globalmente, ma resta un limite della ricerca non sapere quanti di questi siano effettivamente raggiungibili e sfruttabili in modo affidabile, né è quantificato il rischio specifico su reti interne non segmentate rispetto a quello di istanze direttamente visibili su Internet. Ciò non diminuisce la gravità del difetto, ma conferma che la stima rappresenta una potenziale superficie di attacco piuttosto che un conteggio di sistemi già compromessi.

Cosa fare adesso

• Aggiornare a Ollama 0.17.1. La release include la correzione per la lettura out-of-bounds nel loader GGUF. Chiunque gestisca un'istanza, anche interna, deve pianificare l'upgrade immediato.
• Limitare il binding di rete. Configurare il servizio in modo che ascolti esclusivamente su localhost o su interfacce interne strettamente segmentate, evitando il default su 0.0.0.0 a meno che un reverse proxy autenticato non filtri le richieste.
• Ruotare credenziali e secret. Se il server Ollama è stato esposto a Internet o a una LAN estesa, va dato per scontato che variabili d’ambiente e secret in memoria possano essere stati compromessi. La rotazione immediata di API key, token e credenziali è necessaria.
• Implementare autenticazione perimetrale. Poiché Ollama non offre autenticazione nativa, è indispensabile collocare un reverse proxy con autenticazione forte o una VPN davanti agli endpoint esposti, monitorando nel contempo i log per upload anomali di file GGUF verso /api/create.

L'illusione della sicurezza on-premise

La scoperta di Bleeding Llama smonta la convinzione diffusa che togliere i dati dal cloud e portarli in un server locale implicitamente li protegga. Quando il framework locale più popolare per l’inferenza AI viene svuotato della propria memoria da un semplice file modello “avvelenato”, il problema non è più dove risiedono i dati, ma come è scritto il software che li elabora. La mancanza di autenticazione di default e l’abitudine a espandere il binding su tutte le interfacce trasformano l’on-premise in un data breach in attesa di accadere, a meno che patch, segmentazione e hardening non diventino parte integrante dello stack AI.

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://www.cyera.com/research/bleeding-llama-critical-unauthenticated-memory-leak-in-ollama
• https://news.fyself.com/ollama-out-of-bounds-read-vulnerability-causes-remote-process-memory-leak/
• https://www.csoonline.com/article/4168584/ollama-vulnerability-highlights-danger-of-ai-frameworks-with-unrestricted-access.html