Bleeding Llama: fuga di memoria su 300mila server Ollama esposti

Bleeding Llama: fuga di memoria su 300mila server Ollama esposti

Cyera ha divulgato il 10 maggio CVE-2026-7482, la vulnerabilità soprannominata Bleeding Llama che colpisce il loader GGUF di Ollama. Un file modello apparentemente legittimo, caricato attraverso endpoint REST non autenticati, permette a un attaccante remoto di leakare l’intera memoria del processo, inclusi segreti e dati conversazionali. La gravità della falla, con punteggi CVSS stimati in 9.1 da Cyera e 9.9 da Qualys, rende urgente l’intervento per le migliaia di organizzazioni che utilizzano Ollama per LLM self-hosted.

Dal file GGUF alla memoria leakata: la catena di attacco in tre passaggi

L’attacco inizia con l’upload di un file GGUF appositamente craftato attraverso l’endpoint /api/create. Questo è uno dei due canali REST di Ollama che, nelle distribuzioni upstream predefinite, non richiedono alcun tipo di autenticazione. L’attaccante manipola il campo tensor offset e il relativo size, dichiarandoli deliberatamente superiori alla lunghezza effettiva del file caricato sul server.

Ollama accetta l’artefatto e, durante la fase di quantizzazione, attiva la funzione ConvertToF32 nel file server/quantization.go. Tale funzione legge oltre i limiti del buffer heap assegnato senza alcun controllo di coerenza dimensionale tra il file fisico e i metadati tensoriali. Questa operazione di lettura out-of-bounds incorpora byte arbitrari della memoria del processo all’interno del nuovo modello quantizzato salvato sul disco del server.

L’attaccante può successivamente invocare l’endpoint /api/push per pubblicare il nuovo artefatto verso un registro remoto sotto il proprio controllo. Poiché entrambi gli endpoint sono accessibili senza credenziali nelle configurazioni standard, l’intera catena di esfiltrazione può essere automatizzata. Il file modello risultante non è più solo un insieme di pesi neurali, ma una copia parziale della RAM attiva dell’host.

Il cuore del bug: unsafe.WriteTo e il tensor shape gonfiato

La root cause risiede nell’uso del pacchetto unsafe di Go all’interno delle routine di quantizzazione del loader GGUF. Cyera ha individuato che la funzione WriteTo() in fs/ggml/gguf.go e server/quantization.go gestisce il campo tensor shape senza verificare che il numero di elementi dichiarato corrisponda alla dimensione reale del buffer. Questo disallineamento permette una lettura heap out-of-bounds controllata dall’input esterno.

Il meccanismo è insidioso perché non richiede un payload eseguibile né una compromissione preliminare del server: basta un file modello con metadati alterati. La natura stessa del formato GGUF diventa qui un veicolo di trasporto per dati arbitrari prelevati dalla RAM del processo. L’attaccante non ottiene Remote Code Execution (RCE), ma il leak di memoria è critico in ambienti enterprise che gestiscono segreti sensibili.

Bleeding Llama nel mirino: 300mila server e il disallineamento CVSS

Cyera e The Hacker News citano una stima di circa 300.000 server Ollama esposti su Internet. Sebbene il dato non sia verificabile indipendentemente, riflette la diffusione massiva del progetto, che conta oltre 171.000 stelle su GitHub e 100 milioni di download su Docker Hub. Tale popolarità rende la superficie di attacco globale estremamente vasta per i ricercatori di sicurezza e i potenziali threat actor.

Esiste un disallineamento tecnico tra i punteggi CVSS assegnati. Cyera ha calcolato un valore di 9.1, mentre Qualys ThreatPROTECT riporta un CVSS di 9.9 esatto. Questa differenza non è un semplice dibattito, ma deriva da una diversa valutazione della metrica di scope e del vettore di attacco. Qualys assegna un peso maggiore alla totale assenza di autenticazione negli endpoint upstream, che eleva il potenziale di sfruttamento remoto immediato.

"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

Cosa fare adesso

• Aggiornare immediatamente a Ollama 0.17.1. La patch corregge la mancata validazione del tensor shape nel loader GGUF, interrompendo la possibilità di lettura oltre i limiti del buffer. Verificare manualmente le istanze Docker per assicurarsi che il pull dell'immagine rifletta l'ultima versione stabile e non tag obsoleti.
• Isolare o autenticare /api/create e /api/push. Le distribuzioni upstream espongono questi endpoint senza protezione. È necessario inserire un reverse proxy (come Nginx o Apache) per implementare API key o limitare l'accesso alla sola rete interna segmentata tramite regole di firewalling stringenti.
• Scannerizzare l'infrastruttura con i QID Qualys. Utilizzare i codici di rivelazione 734196 e 5012259 per individuare sistematicamente le istanze vulnerabili nell'inventario aziendale. Priorizzare il patching per i nodi che gestiscono dati sensibili o che risultano esposti direttamente sulla rete pubblica.
• Validare la provenienza dei modelli GGUF. Trattare ogni file modello come un artefatto di supply chain. Caricare solo modelli provenienti da repository pubblici verificati e implementare, dove possibile, una fase di pre-validazione che verifichi la coerenza dei metadati tensoriali prima dell'ingestion nel runtime di Ollama.

La responsabilità del vendor e il rischio dei "default aperti"

Bleeding Llama solleva una critica fondamentale alla scelta architetturale di Ollama: la decisione di mantenere endpoint critici come /api/create e /api/push aperti di default senza alcuna forma di autenticazione upstream. In un ecosistema moderno, la sicurezza "out-of-the-box" dovrebbe essere lo standard, non un'opzione da configurare tramite proxy esterni. Questa negligenza trasforma una vulnerabilità di memoria in un disastro di privacy su scala globale.

Per le aziende che trattano proprietà intellettuale o dati sanitari, questa falla rappresenta una violazione diretta della confidenzialità. Il problema non è più solo tecnico, ma di responsabilità del vendor. L’infrastruttura AI deve essere difesa con la stessa rigidità della pipeline software tradizionale. Un semplice offset gonfiato in un header GGUF non dovrebbe mai poter trasformare un modello scaricato da un repository pubblico in una pompa di estrazione dati.

La memoria di un processo inference è un archivio attivo di segreti e contesto conversazionale. Che la superficie di attacco si sia spostata silenziosamente dal codice al contenitore dei pesi neurali dimostra quanto la supply chain dell'IA sia fragile. Per chi gestisce Ollama in produzione, la domanda non è se patchare, ma quanto velocemente è possibile chiudere quegli endpoint che non avrebbero mai dovuto essere aperti al mondo senza protezione.

Domande frequenti

Se Ollama gira solo in locale, il rischio è comunque reale?

Sì. Anche senza esposizione diretta su Internet, la mancanza di autenticazione significa che qualsiasi processo o container compromesso nella stessa rete locale può innescare il leak di memoria. L'esposizione remota rende la falla sfruttabile su scala globale, ma la vulnerabilità resta un vettore di information disclosure pericoloso anche per le reti interne multi-tenant.

La versione 0.17.1 blocca solo l’esfiltrazione o anche la lettura out-of-bounds?

La patch interviene direttamente sulla root cause tecnica. Corregge la gestione del tensor shape nel loader GGUF, impedendo alla funzione di leggere oltre i limiti del buffer heap. Senza la lettura anomala, l'artefatto generato non contiene dati sensibili estratti dalla RAM, rendendo inutile la successiva fase di esfiltrazione tramite /api/push.

È possibile rilevare se un file GGUF malevolo è già stato caricato?

Sebbene non esistano indicatori di compromissione univoci, le organizzazioni possono monitorare i log per chiamate anomale verso /api/push dirette a registri esterni sconosciuti. Un altro segnale è la discrepanza tra la dimensione dei tensori dichiarati e quella effettiva dei file caricati su /api/create durante le ultime sessioni di lavoro.

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://news.fyself.com/ollama-out-of-bounds-read-vulnerability-causes-remote-process-memory-leak/
• https://threatprotect.qualys.com/2026/05/11/ollama-heap-out-of-bounds-read-vulnerability-leads-to-remote-process-memory-leak-cve-2026-7482/
• https://www.cyera.com/research/bleeding-llama-critical-unauthenticated-memory-leak-in-ollama