Ollama: bug in GGUF loader leak memoria da 300mila server
CVE-2026-7482 in Ollama: out-of-bounds read nel loader GGUF consente a un attaccante di esfiltrare l’intero heap, con API key, da oltre 300.000 server.
Contenuto
10 maggio 2026. Il team di ricerca Cyera ha reso pubblica la disclosure di CVE-2026-7482, una vulnerabilità con punteggio CVSS 9.1 nel framework open-source Ollama che consente a un attaccante remoto non autenticato di leakare l’intero heap di memoria del processo. La falla, denominata Bleeding Llama, si annida nel loader del formato GGUF e sfrutta il package unsafe di Go per leggere oltre i limiti del buffer allocato.
Con oltre 300.000 server stimati esposti su Internet, il rischio non è un semplice information disclosure, ma una compromissione totale del contesto operativo delle aziende che ospitano modelli AI on-premise o su cloud accessibile.
- La vulnerabilità è una heap out-of-bounds read (CVE-2026-7482, CVSS 9.1) nel GGUF model loader di Ollama, funzione WriteTo().
- L’exploit richiede l’upload di un file GGUF craftato all’endpoint
/api/createe l’esfiltrazione via/api/pushverso un registry controllato dall’attaccante. - I dati leakati possono includere variabili d’ambiente, API key, system prompt e conversazioni degli utenti attivi nel processo.
- Ollama ha corretto la falla nella versione 0.17.1; non è chiaro quante istanze siano state effettivamente compromesse prima del rilascio della patch.
Il meccanismo del GGUF loader e il percorso di exploit
Nel dettaglio tecnico pubblicato da Cyera, la vulnerabilità risiede nella funzione WriteTo() del percorso di quantizzazione di Ollama, che gestisce il caricamento dei modelli GGUF. Quando il server elabora un file fornito dall’utente, il codice chiama ggml.ConvertToF32 passando il numero di elementi derivato dal tensor shape dichiarato nel GGUF, senza verificare che tale conteggio corrisponda alla dimensione effettiva del buffer allocato. Il processo accede così a byte oltre il limite del buffer, trascinando nella risposta frammenti arbitrari dell’intero spazio di memoria del server.
L’attacco pratico non richiede autenticazione. L’attaccante carica un file GGUF craftato tramite l’endpoint /api/create esposto in rete e successivamente lo spinge verso un registry remoto controllato tramite /api/push, riversando nella risposta i dati letti oltre i confini del buffer. Poiché l’API REST di Ollama non prevede nativamente un layer di autenticazione obbligatorio, la superficie di attacco risulta ampia e immediata per qualsiasi istanza raggiungibile via Internet.
Perché il package unsafe di Go amplifica la falla
La scelta architetturale che rende possibile l’exploit è l’impiego del package unsafe di Go, il quale fornisce agli sviluppatori un accesso diretto alle operazioni di memory management bypassando le garanzie del linguaggio. Come rileva Cyera, Ollama utilizza unsafe in punti critici del caricamento tensore, proprio dove la validazione dei limiti di memoria viene meno.
La combinazione di un calcolo del tensor shape derivato da un input utente non sanificato e di primitive di accesso a basso livello elimina ogni barriera tra il modello caricato e l’heap del processo. Un errore di parsing diventa così una finestra aperta sulla memoria sensibile, dove API key e secret risiedono in chiaro durante l’inference.
Dati a rischio: dalla API key al contenuto delle conversazioni
La memoria leakata non contiene solo metadati di servizio, ma informazioni ad alta densità di valore: variabili d’ambiente, chiavi API, system prompt e conversazioni degli utenti attivi nel momento dell’attacco. Il ricercatore Dor Attias di Cyera ha sottolineato che la compromissione del processo di inference espone il cuore operativo delle aziende.
"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
In un contesto enterprise dove Ollama viene distribuito per isolare dati proprietari e workflow interni, la possibilità di estrarre customer contract, codice proprietario e credenziali di accesso al cloud tramite un singolo file modello alterato equivale a un breach strutturale. Non è necessario malware persistente o privilege escalation: la lettura diretta dell’heap è sufficiente a compromettere compliance, segretezza commerciale e affidabilità dell’infrastruttura AI self-hosted.
Cosa fare adesso
Le aziende che eseguono Ollama su server raggiungibili da Internet devono agire con priorità su quattro fronti. Il primo è l’aggiornamento immediato alla versione 0.17.1, che contiene il fix per la vulnerabilità principale. Il secondo è la verifica che gli endpoint /api/create e /api/push non siano esposti pubblicamente senza un firewall, VPN aziendale o autenticazione perimetrale aggiuntiva, dato che l’API nativa non richiede credenziali.
Il terzo fronte riguarda la rotazione di API key, secret e credenziali presenti nelle variabili d’ambiente delle istanze Ollama che erano esposte durante il periodo di rischio, indipendentemente dall’installazione della patch. Quarto, i team di sicurezza devono analizzare i log di accesso ai registry e alle API per rilevare upload di file GGUF non autorizzati o connessioni sospette verso endpoint /api/push, segnale potenziale di tentativi di esfiltrazione già avvenuti.
Domande frequenti
È possibile sfruttare la vulnerabilità senza azioni manuali della vittima?
Sì. L’attacco è remoto e non richiede autenticazione. L’attaccante invia un file GGUF craftato all’endpoint /api/create e recupera i dati leakati tramite /api/push verso un registry sotto il suo controllo.
La patch 0.17.1 risolve completamente il rischio di data leakage?
La versione 0.17.1 corregge la vulnerabilità CVE-2026-7482, ma non è confermato se il fix introduca regressioni o copra scenari di exploit alternativi. Le aziende dovrebbero comunque ruotare i secret potenzialmente esposti.
Perché la falla è classificata come out-of-bounds read e non come remote code execution?
CVE-2026-7482 consente la lettura arbitraria della memoria di processo, classificandola come information disclosure, ma non permette di iniettare o eseguire codice arbitrario sul server. L’impatto è l’esfiltrazione di dati sensibili, non il controllo del sistema.
La scoperta di Cyera conferma che l’infrastruttura AI self-hosted non è un refugio offline: un file modello modificato basta a trasformare un server locale in una fonte di dati aperta. Il problema non è la popolarità del progetto, ma l’assenza di validazione dei tensor shape in un percorso critico che tocca il memory management. Per le organizzazioni che hanno spostato LLM on-premise per ragioni di privacy, questo è un monito concreto: la sicurezza del model loader è la sicurezza del dato.
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://www.reconbee.com/ollama-out-of-bounds-read-vulnerability-allows-remote-process-memory-leak/
- https://thomasharris6.wordpress.com/2026/05/10/ollama-out-of-bounds-read-vulnerability-allows-remote-process-memory-leak/
- http://blog.fisa.pro/2026/05/bleeding-llama-critical-ollama.html
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://www.reconbee.com/ollama-out-of-bounds-read-vulnerability-allows-remote-process-memory-leak/
- https://thomasharris6.wordpress.com/2026/05/10/ollama-out-of-bounds-read-vulnerability-allows-remote-process-memory-leak/
- http://blog.fisa.pro/2026/05/bleeding-llama-critical-ollama.html