Il 2026-07-08 Trend Research ha reso pubblica una vulnerabilità zero-day nel runtime Ollama, uno degli strumenti più diffusi per l'esecuzione locale di modelli di linguaggio. La falla risiede nella funzione downloadBlob e consente a un attaccante remoto di causare denial of service senza alcuna forma di autenticazione. Nessuna patch è disponibile al momento della disclosure, rendendo la restrizione dell'accesso di rete l'unica contromisura documentata dalla fonte.
- La vulnerabilità ZDI-26-403 interessa la funzione
downloadBlobdi Ollama, con impatto denial-of-service confermato dall'advisory. - L'attacco è remoto e non richiede autenticazione: chiunque possa raggiungere l'istanza può innescare il crash.
- Il bug è classificato come "Improper Validation of Array Index": dati controllati dall'attaccante generano accesso a memoria oltre i limiti dell'array allocato.
- La disclosure coordinata si è conclusa senza patch disponibile dopo circa quattordici mesi dal report iniziale al vendor (maggio 2025).
La meccanica del crash: cosa succede in downloadBlob
Secondo l'advisory ZDI-26-403, la funzione downloadBlob non convalida correttamente i dati forniti dall'utente. Questa mancanza determina un accesso a memoria che supera i confini dell'array allocato, con conseguente violazione di memoria e terminazione del processo. Il risultato è una condizione di denial-of-service sul sistema target.
La funzione downloadBlob è presumibilmente coinvolta nel download di blob binari, ossia i pesi dei modelli LLM che Ollama scarica ed esegue. La sua esposizione in rete — tipica delle configurazioni di sviluppo che espongono la porta locale per comodità — trasforma un difetto di memory safety in un vettore di attacco raggiungibile da remoto.
"The specific flaw exists within the downloadBlob function. The issue results from the lack of proper validation of user-supplied data, which can result in a memory access past the end of an allocated array."
L'advisory specifica esplicitamente che "authentication is not required to exploit this vulnerability". Questo dettaglio amplifica la superficie di esposizione: non serve rubare credenziali, aggirare MFA o trovarsi nella stessa rete interna. Basta raggiungere l'endpoint esposto.
Una timeline lunga quattordici mesi: dalla segnalazione alla 0-day
La disclosure segue il canale coordinato della Zero Day Initiative. I dati strutturati dell'advisory tracciano una cronologia che inizia il 28 maggio 2025 con il report al vendor, prosegue il 4 luglio 2025 con un follow-up di ZDI per confermare la ricezione, e culmina nella pubblicazione del 2026-07-08. L'assenza di una patch al termine di questo percorso ha determinato la classificazione come zero-day nella lista ufficiale delle advisory pubblicate da ZDI.
Il ricercatore che ha identificato la vulnerabilità è Nicholas Zubrisky (@NZubrisky), affiliato a Trend Research. Il credit confermato dall'advisory sottolinea la validità del processo di disclosure, anche se non ha prodotto un rilascio correttivo da parte del vendor.
Il dossier non specifica le versioni esatte di Ollama affette dal bug, nè riporta un CVE assegnato o un punteggio CVSS. Questi limiti sono coerenti con una 0-day pubblicata in assenza di patch: l'identificatore ZDI-26-403 resta l'unico riferimento tecnico certo.
Cosa fare adesso
L'advisory ZDI-26-403 indica una sola strategia di mitigazione documentata: "restrict interaction with the product". Su questa base, le azioni prioritarie derivano direttamente dalla natura del bug e dalla sua esposizione di rete.
- Isolare le istanze Ollama dalla rete pubblica: se il servizio è esposto su indirizzi IP raggiungibili da Internet, la restrizione dell'accesso a interfacce locali o VPN riduce la superficie di attacco conformemente alla raccomandazione della fonte.
- Verificare le regole firewall in ingresso: controllare che le porte utilizzate da Ollama non siano aperte verso reti non attendibili, in particolare nelle configurazioni di sviluppo o test dove l'esposizione è spesso accidentale.
- Monitorare i crash del processo Ollama: anomalie di terminazione ripetute della funzione
downloadBlobpossono indicare tentativi di attacco o exploit in corso, anche se l'advisory non documenta exploit in-the-wild. - Attendere il rilascio di patch dal vendor: data la classificazione zero-day, l'applicazione di un aggiornamento correttivo rimane l'unica mitigazione strutturale; il dossier non specifica se il vendor abbia comunicato una roadmap di fix.
Il rischio dell'AI edge: quando la convenienza dello sviluppo incontra la memory safety
Ollama ha democratizzato l'esecuzione locale di modelli di linguaggio, portando i LLM su hardware consumer senza dipendere da API cloud. Questa accessibilità ha però generato una categoria di deployment che eredita i difetti classici del software di sistema — in questo caso, una mancata validazione di indice di array — con l'aggravante di un'architettura spesso esposta per comodità di sviluppo.
La funzione downloadBlob incarna il modello di business del prodotto: scaricare ed eseguire modelli. Che questa stessa funzione ospiti una vulnerabilità di memory safety rivela una tensione strutturale nel settore AI edge, dove la velocità di adozione può precedere la messa in sicurezza delle componenti di infrastruttura.
La fonte non documenta impatti oltre il denial-of-service, né attacchi attivi o exploit pubblici. Il limite dell'analisi è dunque chiaro: si tratta di una condizione di crash, non di una compromissione del sistema. Tuttavia, l'interruzione di un servizio AI locale in produzione — specialmente in ambienti edge dove la ridondanza è scarsa — traduce un difetto tecnico in un problema di continuità operativa concreto.
Perché questa 0-day segnala un problema più ampio
L'advisory ZDI-26-403 si inserisce in un pattern che vede l'infrastruttura AI locale acquisire visibilità come bersaglio. Non si tratta più solo di compromettere grandi API cloud, ma di colpire runtime eseguiti su macchine individuali, workstation di ricerca, server edge aziendali. La mancanza di autenticazione richiesta abbassa ulteriormente la soglia di attacco, rendendo questi sistemi appetibili per operazioni di distruzione di servizio o come primo stadio di catene di attacco più complesse.
Il dossier non specifica se il vendor abbia riconosciuto la vulnerabilità o pianificato un fix. L'assenza di CVE e CVSS, pur non invalidando la gravità della condizione DoS, lascia gap nei sistemi di gestione automatica delle vulnerabilità che dipendono da questi identificatori. Le organizzazioni che usano Ollama dovranno monitorare manualmente il canale del vendor o della Zero Day Initiative per l'eventuale pubblicazione di patch.
Quattordici mesi tra segnalazione e disclosure pubblica rappresentano un intervallo significativo nel ciclo di vita di una vulnerabilità. Che questo arco temporale non abbia prodotto un rilascio correttivo solleva interrogativi sulle priorità di security del progetto, anche se il dossier non documenta le ragioni di questa assenza.
Fonti
- http://www.zerodayinitiative.com/advisories/ZDI-26-403/
- https://www.zerodayinitiative.com/advisories/published/
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.