CISA, l’agenzia federale statunitense per la cybersicurezza, ha segnalato il 20 agosto 2026 che una vulnerabilità critica di MLflow è già sfruttata in attacchi reali. Il problema riguarda una piattaforma open source molto usata per sviluppare e gestire applicazioni di intelligenza artificiale e può permettere a un aggressore di raggiungere servizi interni e recuperare credenziali cloud da sistemi non aggiornati.
Per un’azienda il punto non è solo “usiamo MLflow oppure no”. La notizia riguarda chiunque stia portando l’AI in produzione, direttamente o tramite fornitori, consulenti e software house: una piattaforma esposta male può trasformarsi in una porta d’ingresso verso dati, infrastruttura e segreti operativi.
Che cosa è successo
La vulnerabilità è tracciata come CVE-2026-64849 e interessa MLflow, piattaforma open source sostenuta dalla Linux Foundation e utilizzata, secondo la fonte, da migliaia di organizzazioni, con oltre 30 milioni di download mensili. MLflow viene impiegata per attività come debug, valutazione, ottimizzazione e monitoraggio di applicazioni AI, inclusi sistemi basati su modelli linguistici e agenti.
Il 20 agosto 2026 CISA ha inserito il difetto nel proprio catalogo delle vulnerabilità note come attivamente sfruttate. Questo passaggio è importante: non si tratta più di un rischio teorico o di una semplice possibilità di abuso, ma di un problema osservato in campagne reali.
La falla era stata corretta in MLflow 3.15.0, ma i sistemi non aggiornati restano esposti. Secondo l’avviso di sicurezza del progetto, il server di tracking predefinito di MLflow può esporre senza autenticazione alcune funzioni legate ai webhook del model registry. In questo scenario un attaccante, se riesce a raggiungere il server vulnerabile, può indurlo a effettuare richieste HTTP verso destinazioni interne o verso servizi di metadata cloud e poi leggerne la risposta.
In pratica, il server diventa un “tramite” per interrogare risorse che dall’esterno dovrebbero rimanere irraggiungibili.
Perché questa vulnerabilità è così pericolosa
Il difetto è descritto come un bypass SSRF tramite DNS rebinding nei webhook in uscita. Il linguaggio tecnico può sembrare distante dalla realtà aziendale, ma l’impatto è molto concreto.
Un attacco di questo tipo può consentire di:
- raggiungere servizi interni visibili solo dalla rete aziendale o dal cloud privato;
- interrogare endpoint locali o di loopback normalmente non accessibili dall’esterno;
- leggere configurazioni e metadata del cloud;
- rubare credenziali, incluse credenziali di accesso a risorse cloud;
- eseguire una ricognizione interna su host e porte disponibili.
La fonte cita in particolare il rischio di esposizione di credenziali AWS IAM attraverso i servizi di metadata dell’istanza cloud. Se un aggressore ottiene questo tipo di segreti, il problema può allargarsi rapidamente: da una singola applicazione AI si può passare all’accesso a storage, database, funzioni serverless o altri componenti dell’infrastruttura.
Non serve immaginare scenari estremi per capire la gravità. In molte aziende le iniziative AI nascono come progetto pilota, vengono pubblicate velocemente per test interni o per un partner e rimangono con configurazioni di default, autenticazione incompleta o controlli di rete non adeguati. È proprio questo mix di velocità e scarsa governance a rendere tali piattaforme appetibili.
Cosa sappiamo sugli attacchi in corso
CISA non ha pubblicato, almeno nella fonte citata, dettagli approfonditi sulla catena completa degli attacchi. Tuttavia, la società di sicurezza watchTowr ha riferito che le scansioni alla ricerca di sistemi MLflow sono iniziate nel giro di poche ore dall’assegnazione del CVE.
Secondo watchTowr, gli aggressori stanno sfruttando la vulnerabilità per raggiungere direttamente i servizi di metadata cloud ed esfiltrare credenziali e segreti. Questo dettaglio chiarisce due aspetti:
- gli attaccanti si muovono molto rapidamente dopo la divulgazione di una vulnerabilità;
- il bersaglio non è soltanto l’applicazione vulnerabile, ma il patrimonio di accessi e configurazioni che essa può raggiungere.
CISA ha inoltre imposto alle agenzie federali civili statunitensi di mettere in sicurezza le istanze MLflow entro due settimane, in linea con la direttiva operativa citata nella fonte. Anche se l’obbligo riguarda il settore pubblico USA, il messaggio per le imprese è chiaro: quando una vulnerabilità entra nell’elenco delle falle sfruttate attivamente, i tempi di reazione devono essere molto brevi.
Il vero tema: la sicurezza delle piattaforme AI in produzione
La notizia su MLflow è un campanello d’allarme più ampio. Molte aziende si concentrano sui modelli AI, sui prompt, sulle performance e sui casi d’uso, ma trascurano la superficie tecnica che rende questi progetti operativi: server di tracking, registry dei modelli, webhook, API, storage, chiavi cloud, ambienti di test e monitoraggio.
In altre parole, l’AI non introduce solo nuovi benefici. Introduce anche nuovi punti di esposizione.
Il rischio cresce quando:
- la piattaforma è pubblicata su Internet senza reale necessità;
- si usano configurazioni predefinite;
- l’autenticazione non è abilitata o non è robusta;
- i sistemi AI condividono rete e permessi con altri ambienti sensibili;
- non esiste un inventario chiaro di dove girano questi componenti;
- non ci sono log, alert e verifiche periodiche.
Per una PMI questo è particolarmente importante perché spesso i progetti AI vengono affidati a terzi o integrati in modo rapido, senza la stessa disciplina normalmente applicata a ERP, file server o posta elettronica.
Cosa significa per la tua azienda
Se la tua organizzazione usa MLflow, oppure collabora con partner che sviluppano soluzioni AI per tuo conto, conviene agire subito con un approccio pratico.
1. Verifica se MLflow è presente da qualche parte
Non limitarti ai server “ufficiali”. Controlla ambienti di laboratorio, macchine cloud temporanee, progetti di data science, demo interne e installazioni gestite da consulenti esterni. Spesso il rischio nasce proprio da sistemi dimenticati.
2. Aggiorna alla versione corretta
La vulnerabilità è stata corretta in MLflow 3.15.0. Se esistono istanze precedenti, vanno trattate come priorità alta, soprattutto se raggiungibili dall’esterno.
3. Riduci l’esposizione Internet
Un server di tracking AI non dovrebbe essere pubblico per impostazione predefinita. Se può rimanere accessibile solo via VPN, rete privata o accesso filtrato, il rischio si riduce sensibilmente.
4. Controlla autenticazione e permessi
La fonte richiama proprio l’assenza di autenticazione in alcune configurazioni. Verifica che l’accesso non sia anonimo e che webhook, API e pannelli di gestione siano protetti.
5. Rivedi log e segnali di compromissione
Controlla richieste anomale, test di webhook, connessioni verso endpoint interni o metadata cloud, attività insolite su account e chiavi d’accesso. Se hai dubbi, considera l’ipotesi che credenziali e segreti possano essere già stati esposti.
6. Ruota le credenziali sensibili
Se MLflow gira in cloud e aveva accesso a ruoli o chiavi importanti, la sola patch potrebbe non bastare. Potrebbe essere necessario ruotare credenziali, token e segreti, soprattutto in ambienti AWS.
7. Segmenta meglio gli ambienti AI
Le piattaforme di sperimentazione non dovrebbero avere visibilità ampia sulla rete interna né accessi eccessivi alle risorse cloud. La segmentazione riduce l’impatto di eventuali SSRF o movimenti laterali.
8. Inserisci i sistemi AI nel ciclo di gestione IT e sicurezza
Le applicazioni AI vanno trattate come qualsiasi altro servizio critico: aggiornamenti, hardening, monitoraggio, backup, controllo degli accessi e piano di continuità. Se oggi questi progetti sono “fuori radar”, è il momento di riportarli sotto governo IT, ad esempio con servizi di gestione centralizzata dei client e dei sistemi e con un rafforzamento della sicurezza informatica aziendale.
9. Proteggi dati e configurazioni
Se i sistemi AI conservano artefatti, configurazioni o registri importanti, è utile verificare anche le strategie di copia e ripristino, soprattutto in ambienti cloud o ibridi, con soluzioni di backup remoto.
Un promemoria utile anche per chi non usa direttamente MLflow
Molte aziende scopriranno di non avere installato MLflow internamente. Questo non chiude il tema.
Vale la pena chiedere ai propri fornitori:
- quale piattaforma usano per sviluppare o tracciare modelli AI;
- se i loro sistemi sono esposti su Internet;
- come gestiscono patch, autenticazione e logging;
- se le credenziali cloud sono separate e a privilegio minimo;
- se esiste un processo di risposta agli incidenti.
Quando una soluzione AI tratta dati aziendali, documenti, listini, contenuti riservati o flussi operativi, la sicurezza del fornitore diventa una parte diretta del tuo rischio.
La lezione manageriale: l’AI va governata come infrastruttura critica
La corsa all’adozione dell’intelligenza artificiale ha spostato l’attenzione verso produttività e innovazione, ma i casi come questo ricordano un punto essenziale: una piattaforma AI non è solo un progetto software, è un componente infrastrutturale con accessi, dati e integrazioni.
Per questo serve una regola semplice: tutto ciò che mette in produzione l’AI deve rispettare gli stessi standard richiesti per gli altri sistemi strategici dell’azienda. Inventario, aggiornamenti, protezione degli accessi, segmentazione, monitoraggio e verifica dei fornitori non sono burocrazia; sono il modo concreto per evitare che un progetto promettente diventi un problema operativo o reputazionale.
Domande frequenti
Se non usiamo MLflow, possiamo ignorare la notizia?
No. Anche se non lo usi direttamente, un partner o un fornitore potrebbe impiegarlo nei servizi AI che ti eroga. Vale la pena fare una verifica.
Aggiornare MLflow basta a risolvere tutto?
Non sempre. Se il sistema è già stato esposto e sfruttato, oltre alla patch bisogna controllare i log e valutare la rotazione di credenziali e segreti.
Questa falla riguarda solo grandi aziende o enti pubblici?
No. Le PMI sono spesso più esposte perché i progetti AI nascono velocemente, con configurazioni temporanee o affidati a terzi, e quindi possono sfuggire ai controlli ordinari.