CVE-2026-7482: memoria Ollama in fuga per un GGUF maligno

CVE-2026-7482: memoria Ollama in fuga per un GGUF maligno

Cyera ha divulgato il 10 maggio una vulnerabilità critica in Ollama, identificata come CVE-2026-7482, che consente a un attaccante remoto non autenticato di provocare un heap out-of-bounds read durante la quantizzazione di un file GGUF maligno. La lettura oltre i limiti del buffer heap, innescata dalla funzione WriteTo() che si avvale del pacchetto unsafe di Go, espone l'intera memoria del processo inference. L'esfiltrazione avviene poi tramite l'endpoint /api/push, trasformando ogni istanza esposta in una fonte di dati potenzialmente aperta.

Il meccanismo del GGUF maligno: come si innesca la fuga di memoria

Il loader GGUF di Ollama si ferma alla lettura dei metadati del tensore senza validare che la lunghezza effettiva del file sostenga i valori di shape dichiarati dall'header. L'attaccante confeziona un archivio dove il campo shape indica un numero di elementi superiore alla porzione dati realmente allocata.

Quando il motore di quantizzazione avvia la conversione, la funzione WriteTo() chiama ggml.ConvertToF32 con q.from.Elements() derivato direttamente da quel campo. Il buffer heap destinato a contenere il flusso di dati non viene dimensionato per resistere a una richiesta così ampia, generando un out-of-bounds read che travalica i confini del segmento assegnato. La specifica GGUF come formato non è intaccata: il difetto risiede esclusivamente nel percorso di parsing e conversione del software, che dà per scontato la corrispondenza tra metadato e payload.

Il ruolo del pacchetto unsafe di Go nel crollo del sandbox

Go garantisce memory safety nativa, ma offre il pacchetto unsafe come via di fuga per operazioni a basso livello su puntatori e indirizzi di memoria. Ollama ricorre a questo pacchetto esattamente nel punto in cui avviene la conversione dei tensori GGUF, abbandonando le protezioni del runtime.

Come spiegano i ricercatori di Cyera, "The answer is the unsafe package. Go gives developers an escape hatch for low-level memory operations, and as the name suggests, all the usual safety guarantees go out the window. Unsurprisingly, the one place Ollama uses unsafe is exactly where this vulnerability lives." L'invocazione permette a WriteTo() di trattare i puntatori senza i controlli del garbage collector, trasformando un errore di validazione dell'input in una lettura arbitraria oltre i confini del buffer.

La scelta architetturale, probabilmente motivata da esigenze di performance nella gestione dei tensori numerici ad alta dimensionalità, ha aperto una breccia esattamente dove il formato GGUF incontra l'elaborazione in linguaggio nativo.

Da /api/create a /api/push: la catena di esfiltrazione senza autenticazione

La catena d'attacco parte da /api/create, endpoint che accetta l'upload di un modello personalizzato fornito dall'utente. L'attaccante carica il GGUF manipolato e attende che Ollama esegua la routine di quantizzazione per preparare il tensore all'inferenza. A quel punto il processo legge memoria al di fuori del segmento assegnato, catturando frammenti di heap adiacenti.

I dati così leakati viaggiano verso /api/push, dove il server inoltra il payload verso un registro remoto senza richiedere credenziali nelle impostazioni upstream di default. Qualys descrive la sequenza in tre passaggi distinti e conferma che le distribuzioni standard lasciano entrambi gli endpoint aperti. La presenza di OLLAMA_HOST=0.0.0.0 su installazioni esposte a Internet trasforma la procedura in un rubinetto di dati accessibile da qualsiasi origine remota.

Chi è esposto: stima di oltre 300.000 server e dati nel mirino

Cyera stima che siano potenzialmente esposti oltre 300.000 server Ollama a livello globale. La cifra non è stata verificata indipendentemente via scansione nelle fonti disponibili, ma fotografa l'ampiezza della superficie d'attacco. Molte di queste istanze appartengono a sviluppatori o aziende che hanno abilitato l'host pubblico per comodità, senza aggiungere strati di autenticazione o firewall applicativo.

Il rischio non riguarda solo il modello caricato: la memoria del processo inference conserva tracce di tutto ciò che transita durante l'operatività. Tra i dati leakabili figurano variabili d'ambiente, API key, system prompt e conversazioni di utenti concorrenti. Per le organizzazioni che integrano strumenti di coding agentic o pipeline automatizzate, la memoria di Ollama diventa un involucro che racchiude segreti aziendali, codice proprietario e output di processi interni.

"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

1. Aggiornare a Ollama 0.17.1. Qualys conferma che questa release corregge la vulnerabilità. Chi gestisce infrastrutture containerizzate o multi-istanza deve verificare che non persistano immagini legacy.
2. Smontare l'esposizione pubblica. Evitare OLLAMA_HOST=0.0.0.0 su Internet. L'ascolto deve essere limitato a interfacce locali, reti private o VPN aziendali, riducendo la superficie raggiungibile dall'esterno.
3. Imporre autenticazione. Gli endpoint /api/create e /api/push sono aperti di default upstream. È necessario interporre reverse proxy con autenticazione obbligatoria o firewall applicativo che blocchi richieste anonime.
4. Ruotare i segreti e monitorare. Ispezionare i log per richieste anomale a /api/create con file GGUF non noti. Ruotare API key e credenziali che potrebbero essere state residenti nella memoria del processo durante il periodo di esposizione.

La falla ricorda che il confine tra inference locale e infrastruttura esposta è più sottile di quanto si assuma. L'adozione diffusa di OLLAMA_HOST=0.0.0.0 per comodità, combinata con una singola chiamata unsafe in Go, ha abbattuto la barriera tra un modello scaricato e l'intero spazio di memoria del server. Chi tratta l'AI on-premise come zona franca ha ora un motivo concreto per ripensare perimeter, autenticazione e segmentazione della rete inference.

Domande frequenti

La versione 0.17.1 risolve completamente il problema?

Qualys indica la release 0.17.1 come correttiva della falla. Tuttavia, chi gestisce infrastrutture inference dovrebbe verificare l'effettiva versione installata su ogni nodo, controllare che non persistano distribuzioni containerizzate legacy e, soprattutto, non limitarsi all'aggiornamento ma abilitare autenticazione e restrizioni di rete come misura difensiva complementare.

OLLAMA_HOST=0.0.0.0 è l'unico scenario di rischio?

L'impostazione 0.0.0.0 amplifica il pericolo rendendo gli endpoint raggiungibili da Internet, ma la vulnerabilità risiede nel codice, non nella configurazione di rete. Qualsiasi ambiente in cui un attaccante possa interagire con /api/create e /api/push, anche internamente, è potenzialmente compromissibile. La segmentazione riduce la probabilità di attacco, ma non elimina il difetto di sicurezza.

È possibile rilevare se il server è stato già compromesso?

Le fonti disponibili non menzionano exploit attivi in-the-wild, rendendo difficile fornire indicatori di compromissione certi. Il leak avviene in memoria e l'esfiltrazione via /api/push può assomigliare a una normale operazione di pubblicazione modello. L'unica contromisura affidabile resta il patching immediato, affiancato dalla rotazione preventiva di API key e credenziali presenti nella memoria del processo durante il periodo di esposizione.

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://news.fyself.com/ollama-out-of-bounds-read-vulnerability-causes-remote-process-memory-leak/
• https://geekfence.com/ollama-out-of-bounds-read-vulnerability-allows-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