MLflow e FUXA sotto attacco: sfruttate falle critiche in AI e automazione industriale

Scansioni attive contro server MLflow e installazioni FUXA

Sono in corso scansioni e tentativi di sfruttamento contro installazioni esposte di MLflow, piattaforma open source per la gestione dei flussi di machine learning, e FUXA, software web SCADA/HMI utilizzato in contesti OT e industriali.

L’attività è stata osservata da watchTowr e VulnCheck. Per MLflow, le scansioni sono iniziate entro poche ore dall’assegnazione di CVE-2026-64849, il 17 agosto 2026. Per FUXA, VulnCheck ha rilevato attività malevola il 18 agosto 2026, con un indirizzo IP impegnato nella ricerca sistematica di installazioni accessibili da Internet.

La stima disponibile indica circa 60 installazioni FUXA pubblicamente esposte. Le richieste osservate tentavano di sovrascrivere il file main.js usando la vulnerabilità CVE-2026-25895. Finora non risultano payload di esecuzione di codice depositati attraverso questa attività, ma la tecnica può preparare un compromesso completo del server.

Le due piattaforme hanno profili di rischio differenti. MLflow può diventare un punto di accesso a credenziali cloud e servizi interni; FUXA può esporre direttamente sistemi di automazione, apparati ICS e processi industriali.

MLflow: una SSRF consente di leggere servizi interni e metadati cloud

La vulnerabilità CVE-2026-64849 è una Server-Side Request Forgery, o SSRF, non autenticata. Colpisce il sistema di consegna dei webhook del Model Registry e può essere sfruttata da chiunque riesca a raggiungere il Tracking Server di MLflow.

L’endpoint coinvolto è:

POST /api/2.0/mlflow/webhooks/{id}/test

Un attaccante può indurre il server a effettuare richieste HTTP verso indirizzi loopback, host interni, interfacce amministrative e servizi di metadati delle infrastrutture cloud. La risposta upstream viene poi restituita dall’endpoint di test, compresi stato HTTP e contenuto.

Non si tratta quindi di una SSRF “cieca”. L’attaccante può leggere direttamente ciò che il server raggiunge, inclusi token IAM, credenziali temporanee e altri segreti presenti nei servizi cloud. Il punteggio indicato nell’archivio è CVSS 9.3, con vettore:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N

Il problema nasce dall’interazione di più difetti nella gestione delle destinazioni. La funzione _validate_webhook_url, introdotta dalla versione 3.10.0, risolve il nome dell’host e blocca indirizzi privati, loopback, link-local e metadata endpoint. Tuttavia, l’indirizzo verificato non viene vincolato alla connessione successiva.

Inoltre, il server segue i redirect perché la sessione HTTP non imposta allow_redirects=False, mentre la destinazione indicata dal redirect non viene sottoposta a una nuova validazione. Questo apre la strada anche a scenari di DNS rebinding, nei quali l’host risolve verso un indirizzo pubblico durante il controllo e verso una risorsa interna al momento della connessione.

Un endpoint HTTPS pubblico può, per esempio, rispondere con un redirect 302 verso:

http://169.254.169.254/latest/meta-data/iam/security-credentials/

Sono possibili anche redirect 307 o 308, che mantengono metodo e corpo della richiesta e possono quindi consentire varianti con scrittura verso la destinazione interna.

La vulnerabilità è stata confermata su mlflow==3.13.0, con il database SQLite predefinito. Non è necessaria l’autenticazione: nel server standard i webhook non sono protetti, mentre i controlli autorizzativi sono disponibili soltanto tramite un plugin opzionale non caricato automaticamente.

Le indicazioni sulle versioni non sono perfettamente allineate. Una soglia operativa indica come vulnerabili le versioni precedenti alla 3.15.0, mentre l’advisory tecnico conferma l’impatto su 3.13.0 e precedenti senza riportare nella scheda una versione corretta. La correzione è associata alla pull request #24258 e al commit ba94952247, che introduce SSRFProtectedHTTPAdapter.

Il nuovo adapter controlla l’IP del socket immediatamente dopo la connessione e prima dello scambio TLS/HTTP. Anche i redirect passano attraverso il meccanismo protetto, impedendo il bypass tramite reindirizzamento e il DNS rebinding.

FUXA: scrittura arbitraria dei file e possibile esecuzione di codice

CVE-2026-25895 riguarda FUXA fino alla versione 1.2.9 inclusa. La correzione è disponibile nella versione 1.2.10.

La falla combina path traversal e assenza di autenticazione per una funzione critica. Un attaccante remoto non autenticato può scrivere file arbitrari in percorsi scelti sul filesystem del server, anche quando runtime.settings.secureEnabled è impostato su true.

Il rischio comprende la sovrascrittura di file applicativi, configurazioni e script di avvio. Se un file modificato viene successivamente caricato o eseguito dal sistema, la scrittura può trasformarsi in esecuzione di codice remoto. La gravità dipende dai privilegi del processo FUXA e dai collegamenti presenti verso reti OT e sistemi SCADA.

La valutazione presente nell’advisory assegna CVSS 4.0 pari a 9.5, con impatto elevato su riservatezza, integrità e disponibilità del sistema vulnerabile e dei sistemi successivi. L’archivio riporta anche una valutazione CVSS 3.1 pari a 9.8:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Durante le scansioni osservate il tentativo consisteva nella sovrascrittura di main.js con dati privi di significato. L’assenza di un payload RCE nella fase rilevata non riduce la priorità: dimostra che gli aggressori stanno già raggiungendo la funzione vulnerabile e ne stanno verificando il comportamento.

Il problema è distinto da CVE-2025-69981, collegata a una funzione di upload non sicura. Quella caratteristica era stata protetta dall’autenticazione; la vulnerabilità attuale è invece il path traversal che consente la scrittura arbitraria.

FUXA: bypass dell’autorizzazione per gli scheduler industriali

FUXA presenta anche CVE-2026-25939, un bypass dell’autorizzazione classificato CWE-862. Le versioni interessate sono quelle precedenti alla 1.2.11; la correzione indicata è FUXA 1.2.11.

La falla permette a un utente remoto non autenticato di creare o modificare scheduler arbitrari. Nelle versioni dalla 1.2.8 alla 1.2.10, questa capacità può essere sfruttata per predisporre azioni successive contro ambienti ICS e SCADA collegati.

Il punteggio è CVSS 9.1:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

La conseguenza principale riguarda integrità e disponibilità: uno scheduler alterato può modificare il comportamento previsto degli impianti o avviare operazioni non autorizzate. Non sono disponibili ulteriori indicatori tecnici sui tentativi osservati contro questa vulnerabilità.

L’attività contro FUXA si inserisce in una serie più ampia. È stato osservato sfruttamento anche di CVE-2023-33831, valutata CVSS 9.8 con vettore:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Secondo le informazioni disponibili, questa attività sarebbe iniziata a novembre 2025 e sarebbe proseguita fino al periodo immediatamente precedente alla rilevazione. Non sono noti ulteriori dettagli sul vettore o sugli indicatori.

Cosa verificare e come ridurre l’esposizione

Gli amministratori dovrebbero aggiornare FUXA almeno alla 1.2.10 per CVE-2026-25895 e alla 1.2.11 per CVE-2026-25939. Per MLflow va applicata la correzione associata alla PR #24258; la soglia di aggiornamento indicata operativamente è la 3.15.0, mentre la conferma tecnica disponibile riguarda la versione 3.13.0.

Quando possibile, MLflow e FUXA non devono essere esposti direttamente su Internet. L’accesso va limitato con segmentazione di rete, autenticazione forte e regole firewall che impediscano al server di raggiungere liberamente servizi interni.

Per MLflow occorre analizzare i log relativi a:

• creazione e modifica dei webhook;
• chiamate a /api/2.0/mlflow/webhooks;
• utilizzo dell’endpoint /test;
• redirect provenienti da host HTTPS pubblici;
• richieste verso 169.254.169.254, 127.0.0.1 e indirizzi RFC1918.

Vanno inoltre verificati eventuali accessi a token IAM, credenziali cloud, segreti applicativi e servizi amministrativi. Qualsiasi credenziale potenzialmente esposta deve essere revocata e sostituita.

Su FUXA è necessario cercare richieste con traversal, modifiche inattese a main.js, scritture anomale sul filesystem e variazioni non autorizzate degli scheduler. I sistemi collegati devono essere controllati per file alterati, nuove attività pianificate e comandi o cambiamenti di processo non previsti.

Per queste vulnerabilità non è indicata una presenza nel catalogo CISA KEV, né una scadenza CISA di remediation. Non è quindi disponibile, allo stato attuale, una deadline KEV specifica.