Ollama: CVE-2026-7482 espone potenzialmente la memoria di 300mila server AI

Rilevata una vulnerabilità critica in Ollama (CVE-2026-7482) che permette il leak di memoria tramite GGUF. Rischi per chiavi API e conversazioni private.

Contenuto

Ollama: CVE-2026-7482 espone potenzialmente la memoria di 300mila server AI
Ollama: CVE-2026-7482 espone potenzialmente la memoria di 300mila server AI

Il 18 maggio 2026 è stata resa pubblica una vulnerabilità di estrema gravità che colpisce Ollama, uno dei framework open source più diffusi per l’esecuzione locale di modelli linguistici. La falla, identificata come CVE-2026-7482 e con un punteggio CVSS di 9.1, consiste in una vulnerabilità di tipo heap out-of-bounds read situata nel loader dei modelli in formato GGUF.

Secondo le analisi tecniche, un attaccante remoto non autenticato può sfruttare questa debolezza per leggere l’intera memoria del processo server. Questo leak avviene tramite il caricamento di un file GGUF malevolo, appositamente configurato, inviato all’endpoint /api/create. La portata del rischio è vasta, poiché permette l'esfiltrazione di dati sensibili come chiavi API, variabili d’ambiente e conversazioni utente in tempo reale.

Oltre alla falla principale, la disclosure ha sollevato preoccupazioni su altri fronti della sicurezza del framework. Sono state infatti segnalate due vulnerabilità nel meccanismo di aggiornamento per sistemi Windows, tracciate come CVE-2026-42248 e CVE-2026-42249. Queste ultime, sebbene con un CVSS inferiore (7.7), rimangono attualmente prive di patch e consentono l'esecuzione di codice remoto in modo persistente e silenzioso.

Punti chiave della vulnerabilità
  • Falla Critica: La CVE-2026-7482 è una heap out-of-bounds read che affligge le versioni di Ollama precedenti alla 0.17.1 durante il caricamento di file GGUF.
  • Meccanismo di attacco: L'upload di un modello manipolato all'endpoint /api/create innesca una lettura oltre i limiti del buffer allocato sull'heap.
  • Esposizione Globale: Cyera stima che circa 300.000 server Ollama siano potenzialmente esposti a causa della mancanza di autenticazione nativa nelle API REST.
  • Rischi Windows: Le CVE-2026-42248 e CVE-2026-42249 permettono RCE persistente tramite l'updater; la divulgazione coordinata con CERT Polska è iniziata a gennaio 2026, ma le falle sono ancora unpatched.

Il meccanismo del GGUF craftato: l’analisi tecnica del memory leak

Il cuore del problema risiede nella gestione dei file GGUF, un formato binario ottimizzato per i modelli quantizzati. La vulnerabilità è localizzata nel componente server/quantization.go, all'interno della funzione WriteTo(). Durante la fase di caricamento e preparazione di un modello per l'inferenza, il server elabora i tensori contenuti nel file per gestirne la quantizzazione in memoria.

Un attaccante può manipolare gli offset e le dimensioni dei tensori all'interno del file GGUF. Quando Ollama tenta di processare questo file tramite l'endpoint /api/create, il server non convalida correttamente i confini della memoria allocata. Questo porta il processo a leggere dati posizionati oltre il buffer heap stabilito, esponendo byte che appartengono ad altre parti del processo in esecuzione.

Il database CVE.org, integrando le evidenze riportate dai ricercatori di Cyera, chiarisce che il difetto permette una lettura arbitraria dei dati adiacenti. Poiché Ollama gestisce molteplici richieste e configurazioni all'interno dello stesso spazio di memoria, un singolo file malevolo può diventare la chiave per accedere a segmenti di memoria contenenti dati critici di altri utenti o del sistema stesso.

“Un attaccante può imparare praticamente qualsiasi cosa sull'organizzazione dalla vostra inferenza AI: chiavi API, codice proprietario, contratti con i clienti e molto altro.”
— Dor Attias, ricercatore di sicurezza presso Cyera

Dalla memoria all’esfiltrazione: l’abuso degli endpoint API

La vulnerabilità CVE-2026-7482 non si limita a una lettura passiva della memoria, ma può essere inserita in una catena di attacco più complessa. Una volta che i dati sono stati letti oltre i limiti del buffer tramite l'endpoint /api/create, l'attaccante può utilizzare un secondo endpoint legittimo del framework: /api/push.

In condizioni normali, /api/push serve per caricare modelli verso registri remoti. Tuttavia, se configurato per puntare a un registro controllato dall'attaccante, questo endpoint può essere utilizzato per inviare i dati sensibili appena letti fuori dal perimetro aziendale. La combinazione di queste due chiamate API trasforma un errore di gestione della memoria in uno strumento di esfiltrazione attiva e difficile da rilevare.

Il rischio è amplificato dal fatto che le API REST di Ollama, per impostazione predefinita, non prevedono un livello di autenticazione integrato. Se il server è raggiungibile via rete senza protezioni esterne (come reverse proxy o firewall), chiunque può inviare le richieste necessarie per innescare il leak. Questa configurazione aperta è ciò che porta alla stima di 300.000 istanze potenzialmente vulnerabili nel mondo.

Vulnerabilità residue: il rischio persistente su sistemi Windows

Mentre la falla GGUF ha ricevuto una patch correttiva, la situazione rimane critica per gli utenti che utilizzano Ollama su piattaforma Windows. Due distinte vulnerabilità nell'updater, CVE-2026-42248 e CVE-2026-42249, consentono a un attaccante di ottenere l'esecuzione di codice remoto (RCE) con persistenza sul sistema della vittima.

Il problema, identificato dai ricercatori di Striga, riguarda le versioni dalla 0.12.10 alla 0.22.0. Attraverso tecniche di path traversal e sfruttando la mancanza di controlli sulle firme digitali degli aggiornamenti, è possibile forzare il sistema a scrivere file arbitrari nella cartella Startup dell'utente. Al successivo riavvio o accesso, il codice malevolo viene eseguito automaticamente con i privilegi dell'utente corrente.

Bartłomiej Dmitruk, co-fondatore di Striga, ha sottolineato che questa catena d'attacco produce un'esecuzione di codice silenziosa e persistente. Nonostante la divulgazione coordinata con il CERT Polska sia iniziata già a fine gennaio 2026, al momento della pubblicazione non risultano disponibili patch ufficiali per queste falle Windows, lasciando una finestra di esposizione significativa per migliaia di postazioni di lavoro.

Cosa fare adesso

La gestione di queste vulnerabilità richiede un intervento immediato e multilivello, che non si esaurisce con il semplice aggiornamento del software. Di seguito le azioni prioritarie da intraprendere per mitigare i rischi esposti dalla disclosure:

  • Aggiornamento immediato: Installare la versione di Ollama 0.17.1 o superiore. Questo intervento corregge la falla critica CVE-2026-7482 nel loader GGUF, impedendo il leak di memoria tramite modelli manipolati.
  • Implementazione di autenticazione: Poiché l'API di Ollama non è autenticata nativamente, è indispensabile posizionare il server dietro un reverse proxy (come Nginx o Apache) che richieda credenziali forti o token di accesso per ogni richiesta agli endpoint /api.
  • Rotazione dei segreti: Se un server Ollama è stato esposto direttamente su internet o su reti non protette, tutte le chiavi API, le variabili d'ambiente e i segreti gestiti dal framework devono essere considerati compromessi e ruotati immediatamente.
  • Monitoraggio Windows: In assenza di patch per l'updater (fino alla v0.22.0), gli amministratori devono monitorare attivamente le cartelle di Startup e i processi di aggiornamento di Ollama, limitando i privilegi dell'utente che esegue l'applicazione.

L'inferenza locale richiede una nuova postura di sicurezza

La scoperta di CVE-2026-7482 segna un punto di svolta nella percezione della sicurezza dei modelli AI locali. L'idea che eseguire un LLM "in locale" sia intrinsecamente più sicuro rispetto all'uso di servizi cloud viene messa in discussione dalla complessità dei formati di input come GGUF. Un formato binario non è solo un contenitore di pesi neurali, ma un codice che viene interpretato dal server e, come tale, può contenere istruzioni malevole.

La vulnerabilità dimostra che i framework AI devono maturare rapidamente, integrando standard di sicurezza tipici del software enterprise, come l'autenticazione obbligatoria e una gestione più rigorosa della memoria. Il ritardo nel rilascio delle patch per la versione Windows, inoltre, evidenzia la necessità per le organizzazioni di non fare affidamento esclusivamente sulla velocità di risposta dei vendor, ma di implementare difese a profondità variabile.

In conclusione, la protezione delle infrastrutture AI non può prescindere da un controllo granulare degli accessi API e da una validazione costante degli artefatti caricati. Senza queste contromisure, la flessibilità e la potenza dei modelli locali rischiano di trasformarsi in una porta aperta verso il cuore dei dati aziendali.

Le informazioni contenute in questo articolo sono state verificate tramite le analisi tecniche di Cyera, Striga e i report del CERT Polska disponibili al momento della pubblicazione.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Link utili

Apri l'articolo su DeafNews