Bleeding Llama: la vulnerabilità CVE-2026-7482 mette a rischio 300.000 server

Bleeding Llama: la vulnerabilità CVE-2026-7482 mette a rischio 300.000 server

Circa 300.000 server Ollama esposti globalmente sono attualmente vulnerabili a un'esfiltrazione massiva di dati sensibili. Una ricerca condotta dal team di Cyera ha svelato una falla di estrema gravità identificata come CVE-2026-7482 e soprannominata "Bleeding Llama". Con un punteggio CVSS di 9.1, questa vulnerabilità permette a un attaccante remoto non autenticato di accedere alla memoria heap del processo, esponendo l'intera infrastruttura di inferenza AI delle organizzazioni colpite.

L'impatto di questa scoperta è amplificato dalla vasta diffusione del progetto, che conta oltre 171.000 stelle su GitHub e ha superato i 100 milioni di download su Docker Hub. Ollama è diventato uno strumento fondamentale per le aziende che implementano l'IA generativa localmente. Tuttavia, la vulnerabilità evidenzia come strumenti nati per un utilizzo "localhost" siano diventati infrastruttura critica senza aver raggiunto la necessaria maturità di sicurezza per l'esposizione diretta in rete.

Questa crisi rappresenta un mismatch strutturale tra design del software e modalità di adozione. Ollama è stato progettato come strumento locale, privo di autenticazione predefinita, ma viene distribuito in ambienti cloud dove la configurazione errata delle interfacce spalanca le porte a chiunque. Il risultato è una superficie d'attacco globale dove la riservatezza dei dati aziendali dipende esclusivamente dalla versione del software in esecuzione e dalla corretta segregazione della rete.

"Ollama, quando lanciato, ascolta su tutte le interfacce per impostazione predefinita senza alcuna autenticazione. Oggi ci sono circa 300.000 server esposti su Internet. Ciò significa che gli attori delle minacce possono sfruttare questa vulnerabilità senza alcuna credenziale – utilizzando solo tre chiamate API, possono estrarre l'intera memoria heap del processo Ollama."

Analisi tecnica: la vulnerabilità nel formato GGUF

Il cuore della CVE-2026-7482 risiede nel modo in cui Ollama gestisce il caricamento dei file nel formato GGUF (GPT-Generated Unified Format). Questo formato binario contiene sia i metadati del modello che i pesi dei tensori necessari per l'inferenza. La vulnerabilità si manifesta come una lettura out-of-bounds nell'heap, innescata durante il parsing dei tensori quando viene caricato un modello appositamente manipolato da un utente malintenzionato remoto.

I ricercatori hanno scoperto che un attaccante può creare un file GGUF "crafted" con valori arbitrari nei campi relativi alla struttura dei tensori. Manipolando il campo "shape", è possibile indurre il server a credere che un oggetto di dati sia molto più grande della sua dimensione reale. Durante l'elaborazione, il sistema tenta di leggere dati oltre il buffer allocato, scorrendo la memoria heap circostante che ospita informazioni sensibili appartenenti ad altre sessioni attive.

Secondo quanto riportato da Cyera Research, il formato GGUF è un formato binario che permette a chiunque di impostare la forma del tensore a piacimento. Non esiste una convalida che il numero di elementi corrisponda alla dimensione reale dei dati presenti. Se un attaccante inserisce un valore molto grande nel campo shape, il loop di lettura procederà oltre la fine del buffer, realizzando una lettura heap out-of-bounds che espone dati non autorizzati.

L'uso critico del pacchetto unsafe in Go

La radice del problema risiede nell'utilizzo del pacchetto "unsafe" in Go, impiegato per gestire i componenti critici di Ollama. Sebbene Go sia generalmente un linguaggio memory-safe, il pacchetto unsafe permette di bypassare i controlli di sicurezza standard per massimizzare le prestazioni durante l'inferenza. La funzione specifica coinvolta è `WriteTo()`, situata nel codice che gestisce la quantizzazione dei tensori, dove il software elabora i dati binari dei modelli.

Quando il server utilizza la funzione `ConvertToF32`, si affida al numero di elementi derivato direttamente dal file GGUF senza eseguire una validazione preventiva sulla coerenza tra metadati e dati reali. Questa scelta architetturale trasforma un'operazione di caricamento in una primitiva di esfiltrazione di memoria. Poiché l'input non viene validato, l'uso di puntatori tramite il pacchetto "unsafe" impedisce al runtime di Go di rilevare o bloccare l'accesso alla memoria non pertinente.

Questo comportamento consente all'attaccante di raccogliere frammenti di dati che risiedono stabilmente o temporaneamente nella memoria RAM del server. Tra questi segreti figurano informazioni che non dovrebbero mai lasciare il processo dell'applicazione. La mancanza di controlli rigorosi su operazioni di basso livello ha reso possibile l'aggiramento delle protezioni di memoria che solitamente caratterizzano le applicazioni scritte in linguaggio Go moderno, esponendo il server a rischi critici.

Impatto Enterprise: i dati sensibili a nudo

Dor Attias, ricercatore di sicurezza presso Cyera, ha sottolineato come un attaccante possa apprendere praticamente qualsiasi informazione sull'organizzazione partendo dall'inferenza AI. I dati potenzialmente esposti includono chiavi API, codice proprietario, contratti con i clienti e altre informazioni aziendali riservate. Il leak non riguarda esclusivamente l'architettura del modello caricato, ma l'intero contesto operativo del processo Ollama, rendendo la vulnerabilità un obiettivo primario per lo spionaggio industriale.

Il rischio è ulteriormente aggravato dal fatto che Ollama gestisce spesso richieste concorrenti da parte di più utenti. Se diversi dipendenti interagiscono con il server durante un attacco, le loro conversazioni e i prompt di sistema si trovano residenti nell'heap e possono essere catturati dal leak di memoria. La vulnerabilità Bleeding Llama diventa quindi una minaccia dinamica, capace di rubare dati in tempo reale mentre il server viene utilizzato legittimamente.

La pericolosità risiede nella possibilità di estrarre variabili d'ambiente critiche che spesso contengono credenziali di accesso a database o altri servizi cloud integrati. L'esposizione di questi dati permette a un attore malevolo di espandere il proprio raggio d'azione all'interno dell'infrastruttura aziendale, partendo da una singola vulnerabilità nel loader del modello AI. Il tutto avviene senza che vengano lasciate tracce evidenti nei log applicativi standard del server.

La catena d'attacco: esfiltrazione in tre fasi

Lo sfruttamento della CVE-2026-7482 è lineare e non richiede credenziali di accesso. La prima fase prevede l'upload del file GGUF malevolo tramite l'endpoint `/api/blobs`. Questo endpoint accetta dati binari che vengono memorizzati localmente dal server. La seconda fase consiste nell'attivazione della lettura di memoria tramite l'endpoint `/api/create`: l'attaccante istruisce Ollama a creare un nuovo modello usando il blob precedentemente caricato, innescando l'errore di parsing dei tensori.

In questa fase, l'out-of-bounds read "inietta" i segreti estratti dalla memoria heap nel nuovo modello che il server sta tentando di generare. La terza fase completa l'esfiltrazione vera e propria. L'attaccante utilizza l'endpoint `/api/push` per inviare il modello appena creato verso un registro esterno sotto il proprio controllo. Poiché il modello contiene i frammenti della memoria heap rubati, l'operazione di push trasferisce i dati sensibili direttamente al server dell'attaccante.

Tale meccanismo è particolarmente insidioso perché il traffico generato appare come una normale gestione di modelli IA tra server e registri. Questo rende il rilevamento da parte dei sistemi di intrusion detection (IDS) estremamente complesso. L'attaccante sfrutta funzionalità legittime di Ollama per trasportare all'esterno il contenuto della memoria RAM, rendendo la vulnerabilità un'arma potente per l'esfiltrazione silenziosa di segreti aziendali su vasta scala.

Perché è importante

Questo caso evidenzia un problema sistemico nell'attuale ecosistema dell'intelligenza artificiale: l'adozione accelerata di software "localhost-first" in contesti aziendali complessi. La facilità d'uso di Ollama ha spinto migliaia di amministratori di sistema a esporre il servizio su Internet per permettere l'accesso ai team di sviluppo. Tuttavia, è stato ignorato che il software non implementa alcuna logica di autenticazione o autorizzazione nativa, essendo nato per il solo uso locale.

La vulnerabilità Bleeding Llama è la conseguenza di questa fretta tecnologica. Inoltre, l'uso di linguaggi moderni non garantisce l'immunità dai bug di memoria se si scelgono di bypassare le protezioni per ottenere prestazioni superiori. La sicurezza delle applicazioni AI non può prescindere da una validazione rigorosa dei modelli binari, che devono essere trattati come input non attendibili al pari di qualsiasi stringa proveniente da un utente esterno.

Un altro elemento di criticità riguarda la consapevolezza dell'esposizione. Molti utenti potrebbero non essere consapevoli che Ollama, per impostazione predefinita, può ascoltare su tutte le interfacce di rete se configurato impropriamente. La combinazione di una vulnerabilità critica di lettura della memoria e la mancanza di autenticazione crea uno scenario di rischio inaccettabile per le aziende che gestiscono dati sensibili tramite i propri modelli linguistici di grandi dimensioni (LLM).

Responsabilità e gestione della disclosure

Un aspetto rilevante di questa vicenda riguarda la gestione della comunicazione da parte del vendor. Secondo quanto riportato da Cybernews, Ollama ha rilasciato la versione 0.17.1 per correggere la falla, ma lo ha fatto senza pubblicare un advisory di sicurezza chiaro o un annuncio che evidenziasse la gravità del problema. Questa mancanza di trasparenza ha impedito a molti utenti di percepire l'urgenza dell'aggiornamento, lasciando migliaia di server vulnerabili per un periodo prolungato.

La mancata comunicazione esplicita del fix solleva interrogativi sulla maturità dei processi di sicurezza del progetto. In un contesto enterprise, la gestione responsabile delle vulnerabilità (vulnerability disclosure) è fondamentale per permettere ai team di sicurezza di priorizzare gli interventi. Il rilascio "silenzioso" di una patch per una falla con CVSS 9.1 può ritardare la messa in sicurezza delle infrastrutture critiche, aumentando la finestra temporale di esposizione agli attacchi.

La responsabilità della sicurezza deve essere condivisa: i produttori devono integrare la sicurezza fin dalle fasi di design, mentre gli utenti devono sottoporre gli strumenti a audit rigorosi prima della distribuzione. Il caso Ollama dimostra che anche i progetti open source di grande successo devono dotarsi di procedure di sicurezza standardizzate per proteggere la propria vasta base di utenti da minacce che possono compromettere l'intera riservatezza aziendale.

Cosa fare adesso

La mitigazione del rischio richiede un'azione immediata per neutralizzare la vulnerabilità e proteggere i dati sensibili. Le organizzazioni devono seguire una procedura di messa in sicurezza rigorosa:

• Aggiornamento obbligatorio: È necessario passare immediatamente alla versione 0.17.1 di Ollama o superiore. Questa release introduce i controlli di validazione necessari sui tensori GGUF per bloccare la lettura heap out-of-bounds.
• Restrizione delle interfacce: Verificare che Ollama non sia esposto su interfacce di rete pubbliche (0.0.0.0). Il software dovrebbe ascoltare solo su localhost (127.0.0.1) a meno di necessità specifiche protette da altri strati di sicurezza.
• Implementazione dell'autenticazione: Poiché Ollama non dispone di autenticazione nativa, è indispensabile utilizzare un reverse proxy o una VPN per gestire l'accesso al servizio, assicurando che solo utenti autorizzati possano interagire con le API.
• Monitoraggio dei log: Esaminare i log alla ricerca di chiamate sospette agli endpoint `/api/blobs`, `/api/create` e `/api/push` provenienti da indirizzi IP non riconosciuti, che potrebbero indicare tentativi di esfiltrazione.
• Isolamento della rete: Utilizzare firewall per limitare il traffico verso le porte utilizzate dai servizi di inferenza AI, garantendo che il servizio sia accessibile solo all'interno di segmenti di rete protetti.

L'adozione di un approccio di sicurezza proattivo è l'unica difesa efficace contro falle di questo tipo. Anche dopo l'applicazione della patch, è fondamentale mantenere una postura di difesa in profondità per mitigare eventuali future vulnerabilità non ancora scoperte.

Conclusione editoriale

La vulnerabilità Bleeding Llama rappresenta un punto di svolta per la sicurezza delle applicazioni di intelligenza artificiale. La protezione della memoria e la validazione rigorosa degli input devono diventare requisiti non negoziabili nello sviluppo di software AI. Le organizzazioni devono bilanciare l'entusiasmo per l'innovazione tecnologica con la necessità di una governance della sicurezza solida, evitando di esporre dati critici a causa di configurazioni affrettate o software non ancora pronti per l'esposizione pubblica.

In definitiva, la gestione della CVE-2026-7482 insegna che la riservatezza nell'era dell'IA non può essere data per scontata. Solo attraverso una collaborazione trasparente tra ricercatori di sicurezza, vendor e utilizzatori finali sarà possibile costruire un ecosistema AI realmente sicuro e resiliente alle minacce emergenti.

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.reconbee.com/ollama-out-of-bounds-read-vulnerability-allows-remote-process-memory-leak/
• https://news.fyself.com/ollama-out-of-bounds-read-vulnerability-causes-remote-process-memory-leak/
• https://cybernews.com/security/critical-ollama-vulnerability-leaks-user-chats/
• https://www.cyera.com/research/bleeding-llama-critical-unauthenticated-memory-leak-in-ollama