Bleeding Llama: leak di memoria su 300.000 server Ollama

Bleeding Llama: leak di memoria su 300.000 server Ollama

Cyera ha reso pubblica il 7 maggio 2026 la vulnerabilità CVE-2026-7482, soprannominata Bleeding Llama, nel framework open-source Ollama: un heap out-of-bounds read nel parser GGUF consente a un attaccante remoto e non autenticato di spillare la memoria di processo da server esposti.

La falla colpisce il caricamento dei modelli di intelligenza artificiale locale e, combinata con la mancanza di autenticazione di default, espone chiavi API, variabili d'ambiente e conversazioni private senza che la vittima rilevi l'intrusione.

L'allarme è immediato: sono oltre 300.000 i server Ollama raggiungibili su Internet, molti in ascolto su tutte le interfacce di rete, e la catena d'attacco richiede in sole tre chiamate API.

Il flaw nel parser GGUF: come un tensore malformato legge oltre il buffer

Il formato GGUF, acronimo di GPT-Generated Unified Format, è lo standard usato da Ollama per ospitare modelli quantizzati in locale. I metadati interni del file descrivono offset, dimensioni e struttura dei tensori: se un attaccante manipola questi valori affinché superino la lunghezza effettiva del file caricato, il server si fida ciecamente dell'header.

Durante la fase di creazione del modello invocata tramite l'endpoint /api/create, il codice in fs/ggml/gguf.go e nella funzione WriteTo() di server/quantization.go alloca un buffer heap basato sui metadati fraudolenti. Il risultato è una lettura oltre i confini del buffer che spilla byte adiacenti: variabili, frammenti di conversazione e altri segreti presenti nella memoria del processo.

L'attaccante non ha bisogno di credenziali. Con una semplice HTTP POST carica il file GGUF craftato, attiva la quantizzazione via /api/create e forza la lettura oltre confine. I dati leakati vengono poi incapsulati nel modello e spinti verso un registry esterno tramite /api/push, dove l'attaccante può estrarli a posteriori.

Dalla memoria heap ai segreti aziendali: cosa trapelia in tre richieste

La memoria heap del processo Ollama non è sterile. Secondo quanto riportato dai ricercatori di Cyera, al suo interno risiedono variabili d'ambiente, chiavi API, system prompt, conversazioni degli utenti, frammenti di codice proprietario e persino contratti cliente. Il memory leak non richiede crash o errori visibili: il server continua a operare normalmente mentre l'attaccante sottrae informazioni.

"An attacker can learn basically anything about the organization from your AI inference — API keys, proprietary code, customer contracts, and much more"

Dor Attias, ricercatore di Cyera, ha sintetizzato l'impatto evidenziando che il leak supera il semplice data breach: l'inferenza diventa vettore di ricognizione aziendale. Non si tratta di furto di database, ma di una finestra aperta sul contesto operativo.

L'esfiltrazione avviene sfruttando la funzione /api/push, normalmente usata per distribuire modelli verso registry compatibili. L'attaccante imposta un repository sotto il proprio controllo e spinge il modello contaminato, trasformando un'operazione lecita in un canale occulto di trasferimento dati. La vittima non rileva anomalie di rete particolari: il traffico sembra legittimo.

Oltre 300.000 server esposti: l'assenza di autenticazione di default amplifica il rischio

Stime convergenti indicano che oltre 300.000 server Ollama sono esposti su Internet, molti configurati in ascolto su 0.0.0.0 senza autenticazione predefinita. Il progetto gode di una massiccia adozione: oltre 171.000 stelle e più di 16.100 fork su GitHub, con una diffusione containerizzata che, secondo CSO Online, ha toccato circa 100 milioni di download su Docker Hub. La popolarità amplifica la superficie d'attacco.

Il paradosso è evidente. Le aziende scelgono Ollama per mantenere i modelli e i dati lontano dai cloud pubblici, puntando su una presunta sovranità computazionale. Tuttavia, la combinazione di interfaccia aperta, mancanza di autenticazione out-of-the-box e vulnerabilità nel parsing dei formati modello trasforma l'installazione self-hosted in un target più pericoloso di un servizio cloud gestito, dove almeno i controlli perimetrali sono standard.

Non è noto al momento quanti server siano già stati effettivamente compromessi o se l'exploit sia già attivo in-the-wild. La mancanza di evidenze primarie dirette, come un report tecnico pubblico di Cyera o un bollettino CVE.org consultabile autonomamente, impedisce di quantificare con precisione il numero di vittime. Le raccomandazioni degli esperti si basano quindi sulla stima della superficie d'attacco e sulla gravità tecnica della falla.

Cosa fare adesso

Applicare immediatamente l'aggiornamento alla release 0.17.1. Gli sviluppatori di Ollama hanno incluso in questa versione la correzione per CVE-2026-7482, eliminando la lettura oltre confine nel parser GGUF. Chi non può aggiornare dovrebbe almeno bloccare l'accesso remoto agli endpoint /api/create e /api/push a livello di firewall.

Ruotare senza indugio chiavi API, token di accesso e credenziali memorizzate nelle variabili d'ambiente dei server esposti. Secondo l'avvertimento diffuso da Cyera, se l'istanza era raggiungibile da Internet va assunto che le credenziali in memoria possano essere già state compromesse. La rotazione deve essere totale e prioritaria.

Riconfigurare il binding di rete per limitare l'ascolto a localhost o a interfacce interne ritenute sicure, abbandonando la modalità 0.0.0.0. Ove necessario, interporre un reverse proxy con autenticazione robusta e limitazione della frequenza di accesso davanti ai servizi di inferenza, trattando Ollama come qualsiasi altro componente critico della produzione.

Attivare il monitoraggio delle chiamate API per rilevare upload di file GGUF anomali verso /api/create e push non autorizzati verso registry esterni tramite /api/push. Un alert tempestivo su queste due primitive può interrompere la catena d'attacco prima che la memoria leakata lasci il perimetro aziendale.

Il caso Bleeding Llama non è una semplice vulnerabilità di parsing, ma il sintomo di un approccio all'AI locale che privilegia la rapidità di deployment rispetto alla security by default. Fino a quando i framework di inferenza non integreranno autenticazione rigida e binding di rete restrittivi fin dall'installazione, la promessa di un'intelligenza artificiale privata e sovrana rischia di diventare un'apertura involontaria sui dati più sensibili dell'impresa.

Domande frequenti

È sufficiente installare la patch per dormire sonni tranquilli?

No. La versione 0.17.1 corregge la falla nel parser GGUF, ma se il server era esposto a Internet occorre ruotare tutte le credenziali e verificare che l'ascolto non avvenga più su interfacce pubbliche. La patch chiude la vulnerabilità tecnica, non rimuove i dati già potenzialmente leakati.

Perché un singolo file GGUF riesce a leggere memoria al di fuori del suo spazio?

Perché il loader si affida ai metadati interni del file per calcolare la dimensione del tensore. Se un attaccante altera questi metadati, la funzione WriteTo() in server/quantization.go legge oltre il buffer heap allocato, spillando byte contigui che possono contenere segreti di processo.

Anche le installazioni Docker sono a rischio?

Sì. La vulnerabilità risiede nel codice di parsing del framework, indipendentemente dal sistema operativo host. I container Ollama esposti su porte pubbliche e privi di autenticazione frontale sono ugualmente vulnerabili alla catena di tre richieste che porta al memory leak.

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