CVE-2026-7482 in Ollama: leak di memoria su 300mila server esposti

CVE-2026-7482 in Ollama: leak di memoria su 300mila server esposti

Il 12 maggio 2026 Cyera ha reso pubblica CVE-2026-7482, una falla critica in Ollama che consente a un attaccante remoto non autenticato di leakare l’intero spazio di memoria tramite un file GGUF manipolato. Ribattezzata Bleeding Llama, la vulnerabilità interessa circa 300.000 server esposti su Internet e molte istanze LAN, trasformando il caricamento di un modello in un veicolo per sottrarre secret e dati proprietari. L’assenza di autenticazione di default e un parser GGUF che non valida le dimensioni reali dei tensor rendono possibile l’esfiltrazione attraverso endpoint legittimi.

Tensor manipolati e lettura oltre i limiti heap

Il bug risiede nel caricatore di modelli GGUF, tra i file fs/ggml/gguf.go e server/quantization.go. Secondo l’analisi di Cyera, la funzione Elements() calcola la dimensione attesa del tensor a partire dalla sua shape. Se l’attaccante dichiara offset e size gonfiati, il ciclo di conversione in ggml_fp16_to_fp32_row — invocato da WriteTo() — procede a leggere oltre il buffer heap allocato, perché il codice non valida le dimensioni reali del file caricato.

Il problema si concentra nelle funzioni di conversione dei tensor quantizzati, dove il calcolo degli elementi attesi non è ancorato alla dimensione effettiva del blob dati nel file. Questo disallineamento permette di spingere il puntatore oltre l’area allocata, sfruttando il package unsafe per accedere a regioni di memoria altrimenti inaccessibili in codice Go puro.

Il percorso di quantizzazione sfrutta il package unsafe di Go per operazioni a basso livello, bypassando le garanzie di memory safety del linguaggio. È proprio in questo passaggio che un errore di parsing diventa una lettura arbitraria della memoria del processo, esponendo variabili d’ambiente, chiavi API e frammenti di conversazioni concorrenti.

La doppia chiamata: /api/create per il leak, /api/push per l'esfiltrazione

L’exploit non richiede credenziali. L’attaccante invia un file GGUF appositamente craftato all’endpoint /api/create, dove Ollama lo accetta e avvia la pipeline di caricamento. Durante la quantizzazione, il tensor con dimensioni falsificate innesca l’out-of-bounds read e riversa blocchi di memoria heap all’interno del nuovo artefatto modello.

A quel punto l’attaccante utilizza l’endpoint /api/push per caricare il modello risultante su un registro esterno sotto il suo controllo. Il file GGUF, ora legittimo agli occhi del sistema, contiene i dati leakati e permette l’esfiltrazione senza bisogno di canali laterali o malware aggiuntivo sul target.

A quel punto l’artefatto modello contenente i dati leakati può essere spinto verso un registro esterno tramite /api/push, sfruttando un endpoint lecito per trasportare informazioni sensibili al di fuori dell’infrastruttura.

Inference locale senza autenticazione: la superficie d'attacco

Ollama è spesso distribuito in ambienti aziendali per eseguire inference locale su modelli open-weights, ma la configurazione di default lo espone più del necessario. Il framework non attiva l’autenticazione out-of-the-box ed è frequentemente configurato per ascoltare su 0.0.0.0 invece che su localhost, aprendo l’interfaccia API alla rete LAN o, in molti casi, a Internet.

Le scansioni della superficie di attacco indicano circa 300.000 server Ollama raggiungibili pubblicamente. Il progetto, che vanta oltre 171.000 stelle su GitHub e quasi 100 milioni di download su Docker Hub, è adottato massivamente da sviluppatori e team DevOps che ora devono verificare la separazione delle istanze dall’infrastruttura core.

La diffusione di Ollama in pipeline CI/CD e in ambienti di sviluppo AI ha spinto molti team a esporre l’API per comodità, spesso dentro container Docker con mappatura diretta delle porte. Questa pratica, combinata con l’assenza di meccanismi nativi di autenticazione, converte l’istanza di inference in un servizio potenzialmente pubblico anche quando l’intento era mantenerlo interno.

Memoria leakata: cosa finisce nelle mani dell'attaccante

Il contenuto della memoria leakata dipende da cosa il processo Ollama stava elaborando al momento dell’attacco. Nei test condotti dai ricercatori, lo spazio di indirizzamento ha rivelato variabili d’ambiente, API key, system prompt, conversazioni di utenti concorrenti e codice proprietario sottoposto a inference. Il punteggio CVSS di 9,1 riflette la capacità di estrarre informazioni ad alta sensibilità senza autenticazione e con interazione minima.

Non è possibile determinare a priori quali specifici byte verranno letti oltre il buffer: l’attaccante può iterare il caricamento con diverse configurazioni di tensor per aumentare la probabilità di catturare segmenti di memoria contenenti informazioni di valore. Ogni tentativo produce un artefatto modello che incapsula i dati leakati, pronto per essere spinto verso l’esterno.

"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 immediatamente a Ollama 0.17.1 o versioni successive che correggono la vulnerabilità.
2. Verificare la binding address dell’istanza, disabilitando l’ascolto su 0.0.0.0 e restringendo l’accesso a localhost o a segmenti di rete fidati.
3. Ruotare API key, token e credenziali presenti in memoria, assumendo che possano essere stati esposti se il server era raggiungibile da Internet.
4. Isolare le istanze di inference dal resto della rete aziendale, applicando firewall e segmentazione per limitare la superficie d’attacco anche in caso di accesso LAN.

Il caso Bleeding Llama non è una vulnerabilità da server web tradizionale: è il punto in cui la supply chain del modello AI incontra la fragilità del codice di parsing. Quando un file di modelli diventa un exploit remoto e l’inference locale manca di autenticazione, il perimetro di sicurezza collassa sul singolo caricamento di un tensor. Per le aziende, questo significa che la governance dei modelli interni e l’hardening delle istanze DevOps vanno trattati con la stessa urgenza riservata agli asset esposti pubblicamente.

Domande frequenti

Se il server Ollama è solo in LAN, è comunque a rischio?

Sì. La mancanza di autenticazione di default permette a qualsiasi attore interno o processo compromesso di invocare /api/create e /api/push. La segmentazione LAN riduce ma non elimina la minaccia.

Il file GGUF deve ricalcare un modello noto per essere accettato?

No. L’endpoint /api/create accetta un GGUF con metadati arbitrari; Ollama processa il tensor dichiarato senza validarne la consistenza con la dimensione reale del file, rendendo l’inganno trasparente al sistema.

I dati leakati sono consultabili in chiaro nel modello esfiltrato?

Sì. La memoria heap letta oltre i limiti viene incapsulata nell’artefatto modello e può essere estratta dall’attaccante dopo il push su un registro esterno, permettendo il recupero dei dati al di fuori dell’infrastruttura compromessa.

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