MLflow sotto attacco: la SSRF critica espone credenziali cloud e servizi interni

CISA inserisce CVE-2026-64849 nel catalogo KEV

CISA ha segnalato lo sfruttamento attivo di CVE-2026-64849, una vulnerabilità critica in MLflow, piattaforma open source utilizzata per sviluppare, valutare e monitorare modelli di machine learning, applicazioni di intelligenza artificiale e Large Language Models.

Il difetto è una Server-Side Request Forgery (SSRF) classificata CWE-918. Un attaccante remoto non autenticato può indurre il server MLflow a effettuare richieste verso risorse interne non direttamente raggiungibili da Internet.

CVE-2026-64849 è entrata nel catalogo CISA Known Exploited Vulnerabilities (KEV) il 19 agosto 2026. Per le agenzie federali civili statunitensi la scadenza per la remediation è fissata al 2 settembre 2026.

La vulnerabilità ha un punteggio CVSS 3.1 pari a 9.3, con il vettore:

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

Il valore riflette l’assenza di autenticazione richiesta, la possibilità di sfruttamento remoto e l’elevato impatto sulla riservatezza. CISA indica inoltre lo sfruttamento come attivo, automatizzabile e con impatto tecnico totale.

Secondo le informazioni disponibili, gli aggressori hanno iniziato a cercare sistemi MLflow vulnerabili entro poche ore dall’assegnazione del CVE. Non sono stati resi noti ulteriori dettagli da CISA sugli attacchi osservati.

Quali installazioni MLflow sono esposte

Il rischio riguarda soprattutto i tracking server avviati con il comando:

mlflow server

e configurati senza autenticazione, con il database SQLite predefinito:

sqlite:///mlflow.db

La configurazione è rilevante perché le webhook del model registry richiedono uno store SQL. Il server predefinito soddisfa quindi i requisiti per esporre le API coinvolte.

Un’installazione è particolarmente esposta quando il tracking server:

• è raggiungibile da Internet;
• non richiede autenticazione;
• dispone di accesso a reti interne o servizi cloud;
• può comunicare con gli endpoint metadata delle istanze;
• utilizza le funzionalità webhook del model registry.

MLflow registra oltre 30 milioni di download mensili ed è adottato da migliaia di organizzazioni. La vulnerabilità può quindi interessare ambienti di sviluppo, piattaforme MLOps e infrastrutture cloud che ospitano modelli o pipeline di IA.

Le informazioni sulle versioni non sono perfettamente allineate tra gli advisory. NVD considera vulnerabili tutte le versioni precedenti alla 3.15.0. Il GitHub Security Advisory indica invece come interessate le versioni fino alla 3.13.0 inclusa, pur descrivendo la correzione nella release 3.15.0 e nella patch #24258.

L’exploit è stato confermato su MLflow 3.13.0 con database SQLite predefinito. Per prudenza, le installazioni precedenti alla 3.15.0 devono essere trattate come vulnerabili.

Come funziona il bypass SSRF

Il percorso principale coinvolge l’endpoint non autenticato:

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

L’endpoint serve a testare una webhook e restituisce al chiamante lo stato della risposta ricevuta dal servizio remoto, insieme al relativo corpo.

MLflow esegue un controllo iniziale sull’URL della webhook. Verifica lo schema, risolve il nome host e rifiuta indirizzi non pubblici, inclusi quelli privati, di loopback, link-local e destinati ai servizi metadata. Normalmente viene consentito soltanto lo schema https.

Il controllo, tuttavia, non vincola l’indirizzo IP verificato alla connessione successiva. Il componente di delivery:

• segue automaticamente i redirect HTTP;
• non disabilita allow_redirects;
• non rivalida l’URL contenuto nell’header Location;
• può eseguire una nuova risoluzione DNS al momento della connessione.

L’attaccante può così registrare una webhook verso un host HTTPS pubblico apparentemente legittimo. Dopo aver superato la validazione, il proprio server risponde con un redirect 302 verso una risorsa interna, per esempio:

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

Il server MLflow segue il redirect ed esegue la richiesta dal proprio ambiente di rete. L’endpoint /test restituisce poi all’attaccante il codice HTTP e il corpo della risposta upstream.

Il secondo percorso di bypass sfrutta il DNS rebinding. La risoluzione DNS eseguita durante il controllo iniziale può restituire un indirizzo pubblico, mentre quella effettuata dalla libreria HTTP durante la connessione può puntare a un indirizzo interno. Poiché l’IP approvato non viene fissato al momento della validazione, la richiesta può raggiungere una destinazione diversa.

La vulnerabilità consente di contattare:

• endpoint AWS IMDS e altri servizi metadata cloud;
• servizi amministrativi interni;
• indirizzi loopback;
• porte e host appartenenti a reti private;
• sistemi non esposti oltre il perimetro della rete.

L’accesso ai metadata cloud può esporre credenziali temporanee AWS IAM, token e altri segreti. L’SSRF può inoltre essere utilizzata per il port scanning e la scoperta di host interni.

L’advisory distingue una SSRF “blind”, legata al normale percorso di consegna degli eventi, da una SSRF con lettura della risposta, ottenibile attraverso l’endpoint /test.

Il PoC dimostra il recupero dei dati interni

La dimostrazione pubblicata segue tre passaggi.

Prima viene tentata la registrazione di una webhook verso un indirizzo locale, come 127.0.0.1. Il controllo risponde con un errore HTTP 400, perché lo schema o l’indirizzo non sono ammessi.

Successivamente viene registrata una webhook verso un host HTTPS pubblico controllato dall’attaccante. L’URL supera la validazione e viene accettato.

Infine, il server dell’attaccante risponde con un redirect verso un servizio interno. L’attaccante richiama quindi l’endpoint /test, che può restituire una struttura simile:

{
  "result": {
    "success": true,
    "response_status": 200,
    "response_body": "<contenuto del servizio interno>"
  }
}

In un test locale, il ricercatore ha inserito manualmente nel servizio interno valori come:

INTERNAL_SECRET=mlflow_ssrf_proof_7f3a91
role=admin

Non si trattava di credenziali cloud reali. Il test dimostra però che il corpo della risposta interna può essere trasferito all’attaccante.

L’attacco non richiede autenticazione e viene eseguito dal server MLflow, non dal browser o dal computer della vittima. I valori degli eventi devono inoltre utilizzare nomi proto in maiuscolo, come REGISTERED_MODEL e CREATED.

Patch, mitigazioni e attività di risposta

La correzione è disponibile in MLflow 3.15.0 ed è associata alla pull request #24258 e al commit:

ba949522477cbd5915aa55d29b0cfad7d5ddf939

Il progetto ha introdotto SSRFProtectedHTTPAdapter, che controlla l’indirizzo IP del socket remoto subito dopo la connessione e prima dello scambio TLS o HTTP. Il controllo viene applicato anche ai redirect, impedendo di riutilizzare il bypass con risposte 302, 307 e 308.

La misura risolve anche il problema legato al DNS rebinding: l’IP effettivamente raggiunto viene verificato, invece di affidarsi soltanto alla risoluzione iniziale.

Gli amministratori dovrebbero:

1. aggiornare MLflow alla versione 3.15.0 o successiva;
2. dare priorità ai tracking server esposti su Internet e privi di autenticazione;
3. abilitare un’autenticazione effettiva e verificare l’autorizzazione delle webhook;
4. limitare le connessioni in uscita del processo MLflow;
5. bloccare l’accesso a 169.254.169.254, reti private, loopback e servizi amministrativi non necessari;
6. controllare proxy, firewall ed egress filtering per impedire richieste verso destinazioni interne.

I log dovrebbero essere analizzati alla ricerca di richieste verso:

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

Sono sospetti anche la registrazione di webhook verso host esterni inattesi, redirect verso indirizzi privati e accessi a 169.254.169.254.

Se l’istanza potrebbe essere stata sfruttata, è necessario verificare l’eventuale esposizione di credenziali cloud, token e segreti. Le credenziali AWS IAM potenzialmente compromesse devono essere revocate o ruotate, accompagnando l’intervento con l’analisi degli utilizzi successivi.

La vulnerabilità è stata segnalata privatamente il 12 giugno 2026 da @freeman-bb. Una revisione indipendente di @AUTHENSOR è stata resa pubblica il 26 giugno 2026 nell’issue #24179.

CVE-2026-64849 non va confusa con CVE-2025-14279, che riguarda una vulnerabilità CSRF con DNS rebinding e appartiene alla categoria CWE-352, non a una SSRF server-side di questo tipo.