Bleeding Llama: vuln Ollama svela API key a 300mila server

Bleeding Llama: vuln Ollama svela API key a 300mila server

Il 12 maggio 2026 è emersa CVE-2026-7482, una vulnerabilità out-of-bounds read nel loader GGUF di Ollama che consente a un attaccante remoto non autenticato di leakare l'intera memoria del processo. La falla, soprannominata 'Bleeding Llama' dai ricercatori di Cyera, espone a rischio immediato circa 300.000 server visibili su Internet, molti dei quali operano senza autenticazione di default. Oggi il mito della sicurezza 'locale' cede di fronte a una catena di attacco che richiede solo tre chiamate HTTP per rubare API key, system prompt e conversazioni degli utenti.

Il trucco del tensor shape e l'OOB read nel loader GGUF

GGUF è un formato binario per modelli Llama che chiunque può costruire manualmente. Secondo Cyera, un attaccante può dichiarare un tensor shape arbitrariamente grande senza che il loader verifichi se il numero di elementi corrisponde alla reale dimensione del buffer: «GGUF is just a binary format – anyone can create one manually and set the tensor’s shape to whatever they want. There’s no validation that the number of elements we’re about to read actually matches the real size of the data», spiegano i ricercatori.

Durante la quantizzazione, la funzione WriteTo() in fs/ggml/gguf.go e server/quantization.go elabora il tensor senza controlli adeguati. Ollama utilizza il package unsafe di Go per operazioni a basso livello sui buffer, bypassando le garanzie native di memory safety del linguaggio. Il risultato è una lettura oltre il limite del buffer heap che ingurgita byte adiacenti di memoria arbitraria.

La memoria leakata non è spazzatura: può contenere variabili d'ambiente, API key, system prompt e conversazioni degli utenti in corso. L'attaccante non ha bisogno di reverse engineering sofisticato: una volta fornito il file all'endpoint /api/create, il processo stesso diventa la sorgente del leak.

Da localhost a Internet-wide: la superficie di attacco nascosta

Ollama è diventato il runtime preferito per chi vuole eseguire modelli locali, accumulando circa 170.000 stelle su GitHub e oltre 100 milioni di download su Docker Hub. Il problema è architetturale: all'avvio il software ascolta su tutte le interfacce di default e non impone autenticazione, trasformando una macchina di sviluppo in un nodo pubblico nel momento in cui un amministratore lo espone su Internet.

Secondo le stime riportate, sono visibili a scanner pubblici circa 300.000 server Ollama. Come ricorda Echo, CNA terzo citato da Cybernews, «Ollama, when launched, listens on all interfaces by default with no authentication. Today, there are roughly 300,000 exposed servers on the internet». Non si tratta di ipotesi: è una superficie di attacco misurabile e già mappata.

La combinazione di popolarità e default permissivi rende il tool un bersaglio naturale. Non è richiesto un errore di configurazione grave: la messa in rete di un'istanza aggiornata ma con i setting originali basta per aprire la porta a chiunque abbia un file GGUF pronto.

La catena di esfiltrazione in tre chiamate HTTP

L'attacco è riduttivamente semplice. L'attaccante carica il file GGUF craftato via POST all'endpoint /api/create, forzando Ollama a leggere memoria al di fuori del buffer allocato. I dati leakati restano incapsulati in un artefatto modello che l'attaccante può successivamente spingere verso un registry esterno tramite l'endpoint /api/push, completando l'esfiltrazione senza mai toccare il filesystem della vittima.

La CVE-2026-7482, classificata con punteggio CVSS 9,1 e descritta da CVE.org come «a heap out-of-bounds read vulnerability in the GGUF model loader», non richiede exploit complessi. Basta un file binario valido ma con metadati malevoli per trasformare il server in una fonte di intelligence passiva.

"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 (via The Hacker News)

Nessun breach di massa è stato confermato al momento, ma la semplicità della catena solleva il rischio di compromissioni mirate. Per aziende che usano Ollama per prototipare su VM cloud o container pubblici, il margine di errore si è ridotto a zero.

Cosa fare adesso

Limitare Ollama all'interfaccia di loopback locale e abilitare un layer di autenticazione prima di qualsiasi esposizione di rete è il primo passo. Se il servizio non richiede accesso esterno, il binding deve restare su 127.0.0.1 escludendo 0.0.0.0.

Bloccare l'accesso remoto agli endpoint /api/create e /api/push riduce drasticamente la superficie offensiva nel caso in cui il server debba rimanere raggiungibile per altri servizi. Questi path sono il cuore della catena di attacco e meritano restrizioni a livello di firewall o proxy inversi.

Aggiornare all'ultima versione disponibile è essenziale, anche se solo una fonte indica la release 0.17.1 o successiva come priva della vulnerabilità, senza conferma ufficiale del vendor al momento della stesura.

Infine, ruotare immediatamente API key e segreti presenti nelle variabili d'ambiente delle istanze esposte e monitorare il traffico verso registry esterni sospetti attraverso l'endpoint /api/push, trattando ogni installazione precedentemente accessibile come potenzialmente leakeata.

Il package unsafe di Go e il crollo della memory safety moderna

Go è un linguaggio memory-safe per design, ma il package unsafe consente operazioni a basso livello sui pointer che eludono il type system e il garbage collector. Ollama lo impiega nella pipeline di quantizzazione per manipolare tensor direttamente, una scelta performance-driven che ha aperto una breccia nel muro di contenimento del runtime.

La combinazione di un parser binario non robusto e dell'accesso unsafe alla memoria annulla il vantaggio architetturale del linguaggio. Non è una vulnerabilità di Go stesso, ma la dimostrazione che anche toolchain moderne possono delegare la sicurezza a convenzioni di programmazione facilmente violate da un input esterno controllato dall'attaccante.

In questo scenario, l'adozione di unsafe non è un dettaglio tecnico secondario: è il motivo per cui una discrepanza sui metadati di un file modello si traduce in una lettura arbitraria dell'intero spazio di indirizzamento del processo. Senza quell'aggiramento, il runtime avrebbe probabilmente intercettato l'anomalia prima che diventasse leak.

L'assunto che un modello eseguito in locale o dentro un container privato sia automaticamente protetto si è frantumato contro la realtà di una superficie di attacco globale. La memoria di Ollama non è più un recinto privato: se il processo è raggiungibile da Internet, i dati che vi transitano diventano merce di scambio per chiunque sappia confezionare un file GGUF malformato. Distinguere tra 'locale' e 'sicuro' non è più un lusso analitico, ma un prerequisito per chi gestisce infrastrutture AI.

Domande frequenti

È richiesta l'autenticazione per sfruttare CVE-2026-7482?
No: l'attaccante può agire da remoto e senza credenziali valide, sfruttando endpoint accessibili di default su server esposti.

Quali dati specifici rischiano di essere esfiltrati?
Variabili d'ambiente, API key, system prompt e conversazioni degli utenti attive nella memoria del processo Ollama al momento dell'attacco.

È sufficiente aggiornare Ollama per risolvere il problema?
Una fonte indica che la versione 0.17.1 o successiva elimini la vulnerabilità, ma tale claim non è replicato da advisory ufficiali del vendor al momento della pubblicazione.

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://thomasharris6.wordpress.com/2026/05/10/ollama-out-of-bounds-read-vulnerability-allows-remote-process-memory-leak/
• https://cybernews.com/security/critical-ollama-vulnerability-leaks-user-chats/