Un Ingegnere Mette in Piedi una Dashboard, Solo Per il Team

Un ingegnere di un'azienda di medie dimensioni mette in piedi un server di tracciamento MLflow su una VM interna perché il team di data science possa registrare esperimenti e confrontare le esecuzioni dei modelli. MLflow non chiede un nome utente o una password durante l'installazione, quindi non ne viene configurato nessuno, e il server va online dietro quella che tutti presumono sia una rete privata. In una fabbrica a qualche centinaio di chilometri di distanza, un ingegnere operativo fa qualcosa di simile: mette in piedi FUXA, una piattaforma open source SCADA e HMI, per dare al team una vista via browser dei tag della linea di produzione. Nessuno dei due sistemi è stato costruito per essere raggiungibile dall'internet aperto, e nessun team lo ha verificato.

Nella settimana del 18 agosto 2026, entrambe le ipotesi si sono rivelate sbagliate contemporaneamente. MLflow, una piattaforma di tracciamento degli esperimenti ospitata sotto LF Projects presso la Linux Foundation, e FUXA, uno strumento per sistemi di controllo industriale del tutto scorrelato, hanno divulgato ciascuno una vulnerabilità critica, non autenticata di default - e in entrambi i casi gli attaccanti avevano exploit funzionanti entro poche ore dalla divulgazione pubblica, non settimane. Due codebase diverse, due settori diversi, due team che non si sono mai coordinati tra loro. Ciò che condividono è un'unica scelta progettuale, presa indipendentemente, a distanza di anni, per lo stesso motivo: è più veloce rilasciare uno strumento con l'autenticazione spenta piuttosto che accesa.

La Falla di MLflow Trasforma un Redirect in un Furto di Credenziali

La vulnerabilità di MLflow, classificata come CVE-2026-64849, ha un punteggio CVSS di 9,3. È un bypass della validazione dell'URL dei webhook: MLflow permette di registrare webhook che si attivano in occasione di eventi come il completamento di un training, e controlla l'indirizzo di destinazione prima di consentirlo, per impedire che il server punti verso indirizzi interni. Gli attaccanti hanno scoperto di poter aggirare quel controllo combinando un redirect HTTP con il DNS rebinding - registrano un webhook verso un indirizzo che supera la validazione, per poi farlo risolvere, al momento della richiesta, verso un IP interno che il validatore non ha mai visto. GitLab ha pubblicato un avviso di sicurezza sulla falla, e l'exploit è stato confermato in modo indipendente da testate di cybersecurity come cybersecuritynews, cyberpress e GBHackers.

Il guadagno per un attaccante è la server-side request forgery: il server MLflow stesso diventa colui che effettua la richiesta, dall'interno della rete in cui si trova. Questo permette a un attaccante di raggiungere servizi interni che non erano mai destinati a guardare verso l'esterno, e in modo determinante gli endpoint di metadati delle istanze cloud su AWS, Azure e GCP - gli indirizzi interni che consegnano credenziali temporanee alla macchina che le richiede. Poiché i server di tracciamento MLflow spesso funzionano senza autenticazione negli ambienti reali, nulla impedisce a un attaccante esterno di effettuare quella prima richiesta. The Hacker News ha riportato il 18 agosto 2026 che lo sfruttamento attivo è iniziato entro poche ore dalla divulgazione.

La Falla di FUXA Permette a Estranei di Scrivere File sui Sistemi di Impianto

FUXA è una piattaforma open source SCADA e HMI - il tipo di software che offre agli operatori di impianto una finestra via browser sulle apparecchiature che effettivamente controllano una linea di produzione. La sua vulnerabilità, CVE-2026-25895, ottiene un punteggio ancora più alto di quello di MLflow, pari a 9,5, e il meccanismo è più diretto: autenticazione mancante combinata con una falla di path traversal. Un attaccante non autenticato può inviare una richiesta che sfugge dalla directory in cui FUXA prevede di scrivere e posizionare un file in qualsiasi punto del filesystem sottostante a sua scelta.

La scrittura arbitraria di file non è un semplice bug di esposizione dei dati, è un punto d'appoggio. Un attaccante che può scrivere file dove vuole su un sistema che comunica con impianti industriali può collocare codice eseguibile e ottenere l'esecuzione di codice remoto, il che significa il controllo completo dell'host che esegue l'HMI - e, a seconda di come quell'host è collegato all'impianto di produzione, un percorso verso i sistemi di controllo stessi. Come per MLflow, The Hacker News e le stesse testate che lo hanno confermato hanno riportato che lo sfruttamento attivo è iniziato entro poche ore dalla divulgazione pubblica, nella stessa settimana dell'avviso su MLflow.

Il Filo Comune Non è il Codice, è l'Impostazione Predefinita

MLflow e FUXA non condividono codice, né maintainer, né mercato. Uno traccia esperimenti di machine learning, l'altro visualizza sistemi di controllo industriale, e sono stati divulgati indipendentemente nella stessa settimana per pura coincidenza di tempistica. Ciò che condividono è un'impostazione predefinita: rilasciare senza autenticazione, perché è il modo più veloce per far funzionare uno strumento per un piccolo team interno, e perché il team presume che la rete circostante sia privata. Quella presunzione è l'intera superficie d'attacco.

La stessa impostazione predefinita si nasconde dietro una larga fetta degli strumenti interni che i titolari d'azienda non ispezionano mai personalmente: dashboard MLOps, stack di monitoraggio, pannelli di amministrazione interni, e sistemi SCADA/HMI in tutto il settore manifatturiero. Ognuno è stato probabilmente messo in piedi rapidamente, da qualcuno competente, per risolvere un problema reale, che non è mai tornato ad attivare l'autenticazione perché nulla lo ha costretto a farlo. Il divario tra ciò che si presume privato e ciò che è realmente raggiungibile - sia tramite esposizione diretta a internet, sia, come con MLflow, tramite un pivot SSRF da un sistema che è raggiungibile - è esattamente dove sono atterrati entrambi gli exploit, ed è dove atterrerà anche il prossimo.

Le Ore Fino allo Sfruttamento Sono Ormai la Vera Finestra di Patch

Per qualsiasi azienda nell'UE o nel Regno Unito che gestisce pipeline MLOps - sempre più comuni man mano che le aziende distribuiscono la propria infrastruttura ML e IA - o per qualsiasi azienda industriale o manifatturiera che gestisce sistemi SCADA o HMI, la risposta pratica è un audit, non una nota di policy. Ogni strumento interno ha bisogno di una risposta diretta a una domanda: l'autenticazione è davvero attiva, non solo presunta, e lo strumento è davvero irraggiungibile dall'esterno della rete in cui dovrebbe vivere? MLflow e FUXA mostrano entrambi che la risposta onesta è spesso no, e che nessuno lo scopre finché non viene sfruttato.

L'altro aggiustamento riguarda l'orologio. Entrambe le falle sono passate dalla divulgazione pubblica allo sfruttamento attivo in poche ore, non nelle settimane che i cicli di patch hanno tradizionalmente presunto. Per gli operatori industriali con sede nell'UE in particolare, questo non è solo un problema tecnico: gli obblighi NIS2 si applicano ai fornitori di infrastrutture digitali e, in modo significativo, agli operatori manifatturieri e industriali che gestiscono sistemi OT e SCADA, il che rende un'HMI non aggiornata e non autenticata un fallimento di conformità oltre che di sicurezza. La soluzione non è esotica - attivare l'autenticazione, applicare la patch il giorno della divulgazione, presumere che nulla dietro il firewall sia davvero privato - ma deve avvenire prima dell'exploit, e questa settimana quel divario si è misurato in ore.

Da leggere ora: Una violazione che il registro DORA non spiega  |  Shell e Philips hanno perso disegni tecnici, non password