Bleeding Llama: memory leak critico in Ollama, 300.000 server in pericolo

Chi utilizza Ollama per eseguire modelli linguistici in locale - magari per evitare i costi delle API cloud o per tenere i propri dati lontani dai server di OpenAI e Anthropic - farebbe bene a controllare con urgenza come è configurato il proprio sistema. Una vulnerabilità critica nel popolare server di inferenza per LLM, battezzata "Bleeding Llama" dai ricercatori che l'hanno scoperta, consente a un attaccante remoto e non autenticato di leggere porzioni di memoria heap dal server, con il rischio concreto di esporre chiavi API, prompt degli utenti, variabili d'ambiente e configurazioni interne. Un exploit Proof-of-Concept è già pubblico, la patch ufficiale non è ancora disponibile, e si stima che circa 300.000 deployment nel mondo siano potenzialmente esposti.

Cos'è Ollama e perché ci interessa

Ollama è una piattaforma open source che permette di eseguire localmente grandi modelli linguistici come Llama e Mistral senza dipendere da servizi cloud. Con circa 170.000 stelle su GitHub e oltre 100 milioni di download su Docker Hub, il progetto ha conquistato una base di utenti enorme, che spazia dalle aziende agli appassionati di intelligenza artificiale che preferiscono mantenere il controllo completo sui propri dati. L'idea di fondo è semplice e attraente: niente abbonamenti, niente limiti di utilizzo, niente dipendenza dalla rete.

Ma proprio la facilità di installazione ha portato molti utenti a esporre le proprie istanze su endpoint raggiungibili dalla rete pubblica, spesso senza alcuna forma di autenticazione - ed è qui che Bleeding Llama colpisce.

Il meccanismo tecnico: fidarsi del file sbagliato

La falla risiede nel motore di quantizzazione di Ollama e nella gestione dei file GGUF (GPT-Generated Unified Format), il formato usato per rappresentare i pesi dei modelli. Un file GGUF contiene tensor - array multidimensionali che descrivono i parametri del modello - accompagnati da un'intestazione con metadati che ne specificano dimensione e struttura.

Il problema nasce dalla convergenza di tre errori concatenati. Il motore si fida ciecamente dei metadati dei tensor forniti nel file GGUF, senza verificarli. Usa poi la funzione unsafe.Slice() di Go per creare slice di memoria basate su quei metadati non validati, il che può portare a una lettura oltre i limiti del buffer allocato (out-of-bounds read). Infine, l'endpoint api/push di Ollama - quello che consente di inviare modelli a registry esterni - permette all'attaccante di esfiltrare il contenuto della slice risultante, che a quel punto include dati adiacenti sulla heap.

L'attacco è concretamente semplice da orchestrare: l'aggressore carica un singolo file di modello malevolo attraverso l'endpoint /api/blobs/sha256:[digest], poi usa /api/create per costruire un'istanza del modello a partire da quel file. I metadati manipolati nel GGUF fanno sì che Ollama legga più memoria di quanta ne dovrebbe, e il contenuto extra - che può includere chiavi API, indirizzi IP interni, prompt di sistema, messaggi degli utenti e variabili d'ambiente - viene reso disponibile per l'esfiltrazione.

La classificazione della vulnerabilità copre tre categorie: divulgazione di informazioni, lettura fuori dai limiti e corruzione della memoria. Un identificativo CVE è stato assegnato, ma le fonti disponibili riportano numeri in conflitto tra loro, il che impedisce di indicarne uno con certezza fino a conferma da parte di NVD o MITRE. Anche il punteggio CVSS varia tra le fonti, oscillando tra 8.0 e 9.1 - comunque nell'area della severità alta o critica.

La scoperta e lo stato della patch

La vulnerabilità è stata individuata e denominata dai ricercatori di Cyera. Al momento della divulgazione, nessuna patch ufficiale è stata rilasciata dal team di Ollama. A peggiorare la situazione, un Proof-of-Concept funzionante è già di dominio pubblico, il che abbassa drasticamente la soglia di competenza necessaria per sfruttare la falla. La vulnerabilità non risulta ancora inserita nel catalogo KEV (Known Exploited Vulnerabilities) di CISA, ma con un exploit pubblico in circolazione si tratta di un dettaglio più burocratico che rassicurante.

La stima di 300.000 server potenzialmente esposti a livello globale - basata su scansioni di tipo Shodan - dà un'idea della superficie d'attacco. Non tutti questi deployment saranno necessariamente vulnerabili nella pratica, ma il numero suggerisce che molti utenti hanno messo in rete le proprie istanze senza adeguati controlli di accesso.

Non solo Bleeding Llama: guai anche per l'aggiornamento automatico su Windows

Come se non bastasse, un gruppo di ricercatori di Striga ha divulgato separatamente due ulteriori vulnerabilità che colpiscono specificamente il client Windows di Ollama, entrambe legate al meccanismo di aggiornamento automatico.

La prima riguarda la verifica della firma digitale: la funzione esiste ed è invocata nel codice, ma non fa assolutamente nulla. Qualunque file scaricato come aggiornamento viene eseguito senza controlli. La versione macOS, per contro, esegue correttamente la verifica del code signing. Un'asimmetria che ha il sapore della svista imperdonabile.

La seconda è una vulnerabilità di path traversal: il sistema di aggiornamento costruisce il percorso locale del file scaricato direttamente dagli header della risposta HTTP, senza alcuna sanitizzazione. Un attaccante che controlli la risposta di aggiornamento può inserire sequenze ../ nell'header ETag per scrivere un eseguibile arbitrario nella cartella di avvio automatico di Windows.

Concatenate, le due falle consentono di piazzare un eseguibile persistente che si avvia a ogni accesso dell'utente, senza alcun avviso e senza il tag Mark-of-the-Web che normalmente attiverebbe gli avvisi di sicurezza. «Lo stesso binario depositato si avvia a ogni accesso successivo, fino a quando il file non viene rimosso manualmente», ha spiegato Bartłomiej Dmitruk, co-fondatore di Striga.

I prerequisiti per sfruttare queste falle non sono banali - richiedono il controllo della risposta di aggiornamento, ottenibile compromettendo l'infrastruttura di distribuzione, manipolando la variabile OLLAMA_UPDATE_URL, il file hosts o un certificato root, oppure tramite attacco man-in-the-middle a livello di rete. Detto questo, il fatto che l'aggiornamento automatico sia attivo per impostazione predefinita e che il client si avvii al login amplia la finestra di esposizione. Anche queste vulnerabilità risultavano prive di patch al 5 maggio 2026.

Cosa fare adesso

In attesa di una correzione ufficiale, le contromisure sono essenzialmente di buon senso - ma vale la pena ribadirle, perché la cronaca dimostra che il buon senso in materia di sicurezza non è mai così comune come si vorrebbe.

• Non esporre Ollama su Internet senza una ragione precisa e senza protezioni adeguate. Se lo state usando per sperimentare in locale, deve restare in locale.
• Implementare autenticazione e controlli di accesso davanti a qualsiasi endpoint Ollama raggiungibile dalla rete.
• Monitorare i log di accesso per individuare pattern anomali, in particolare richieste verso gli endpoint /api/blobs, /api/create e /api/push.
• Su Windows, valutare la disattivazione dell'aggiornamento automatico fino al rilascio di una correzione, e verificare che nella cartella di avvio automatico non siano comparsi file sospetti.
• Eseguire un controllo di sicurezza del proprio ambiente di deployment, specialmente se Ollama gira su una macchina che gestisce anche altri servizi.

La popolarità di Ollama è meritata: poter eseguire modelli potenti sulla propria macchina, senza intermediari, è una libertà che ha un valore reale. Ma quella stessa libertà comporta la responsabilità di gestire correttamente l'esposizione del servizio. Bleeding Llama è un promemoria piuttosto brutale: un server locale smette di essere "locale" nel momento in cui risponde a richieste provenienti da tutta la rete. A quel punto, la memoria del vostro sistema diventa un libro aperto.

Fonti: cyera.com, coesecurity.com