Ricevi DeafLetter
Una selezione settimanale di segnali, vulnerabilità e guide. Gli avvisi critici restano facoltativi.
Puoi cancellarti in ogni momento. Privacy policy.
Il 29 ottobre 2026 il programma Zero Day Initiative di TrendAI ha pubblicato l'advisory ZDI-26-847, che documenta una vulnerabilità di Server-Side Request Forgery nel MLflow AI Gateway. La falla, identificata come CVE-2026-71211, consente a utenti già autenticati di forzare il gateway a inoltrare richieste verso endpoint interni e servizi cloud, con un impatto valutato CVSS 7.7. Il caso mette in luce come le piattaforme MLOps stiano ereditando problematiche di sicurezza consolidate nel mondo dei tradizionali API gateway.
- La vulnerabilità CVE-2026-71211 interessa il MLflow AI Gateway e richiede autenticazione per essere sfruttata.
- Il flaw risiede nella mancata validazione del campo api_base, che il raw proxy route concatena a path controllati dall'utente.
- Il CVSS è 7.7 secondo la lista ZDI pubblicata sul sito dell'iniziativa.
- La patch introduce validazione a due livelli e blocca di default gli IP privati, richiedendo override esplicito per deployment interni.
Come funziona l'attacco: dal campo api_base al SSRF
Il MLflow AI Gateway permette agli utenti di configurare endpoint AI personalizzati specificando un URL base nel campo api_base. Secondo l'advisory ZDI, "the specific flaw exists within the processing of the api_base field. The issue results from the lack of proper validation of a URI prior to accessing resources." La descrizione della pull request ufficiale #25761 aggiunge un dettaglio tecnico preciso: "A gateway secret's auth_config.api_base was stored verbatim, and the raw proxy route sends caller-supplied paths to it and returns the response body, so any user who could create a secret could reach internal services and cloud metadata endpoints."
La concatenazione diretta tra l'URL base memorizzato e i path forniti dall'utente crea una condizione classica di SSRF. Un attaccante autenticato poteva configurare api_base verso un servizio interno e poi utilizzare il raw proxy route per estrarre informazioni sensibili. La risposta del server veniva restituita integralmente al chiamante, completando il ciclo di information disclosure.
La timeline: da giugno all'embargo coordinato di ottobre
La vulnerabilità è stata segnalata al vendor il 30 giugno 2026. Il rilascio coordinato dell'advisory è avvenuto il 29 ottobre 2026, dopo un periodo di embargo di quasi quattro mesi che ha permesso lo sviluppo della patch. Questo ritmo riflette la complessità del fix: la pull request #25761 ha aggiunto 1.522 linee di codice e rimosso 22, indicando una revisione architetturale sostanziale piuttosto che una semplice correzione puntiforme.
Il nucleo della modifica è una doppia validazione. In fase di scrittura, il sistema verifica che api_base usi solo scheme HTTPS, indirizzi IP pubblici e nessuna credenziale embedded. In fase di connessione, un resolver dedicato filtra gli indirizzi privati, blocca i redirect e protegge contro il DNS rebinding. L'implementazione copre esplicitamente questo ultimo vettore, come documentato nel codice della PR: "resolver that only returns public addresses, rejects non-canonical literals... covers DNS rebinding."
Il cambio di default che rompe i deployment on-premise
La patch introduce due variabili d'ambiente che modificano il comportamento operativo del gateway. MLFLOW_GATEWAY_API_BASE_ALLOW_PRIVATE_IPS e MLFLOW_GATEWAY_API_BASE_ALLOWED_SCHEMES permettono agli amministratori di derogare ai vincoli di default, ma richiedono configurazione esplicita. Questo cambiamento ha un impatto immediato sui deployment che utilizzavano Ollama in localhost o servizi interni non esposti a internet: dopo l'aggiornamento, questi endpoint smettono di funzionare fino a che non viene attivato l'override.
Il trade-off è evidente. La flessibilità che rendeva MLflow attraente — la possibilità di puntare a qualsiasi servizio AI, inclusi quelli in esecuzione locale — era la stessa caratteristica che apriva la superficie di attacco SSRF. Le piattaforme MLOps si trovano ora a replicare le stesse gerarchie di controlli che i gateway API enterprise hanno consolidato da anni: default sicuri, eccezioni configurate, validazione su più strati.
"This vulnerability allows remote attackers to initiate arbitrary server-side requests on affected installations of MLflow. Authentication is required to exploit this vulnerability." — ZDI Advisory ZDI-26-847
Cosa fare adesso
Le organizzazioni che impiegano MLflow AI Gateway in configurazioni multi-utente devono verificare la presenza della PR #25761 nel proprio deployment. L'aggiornamento richiede attenzione alle variabili d'ambiente, in particolare per gli ambienti on-premise che utilizzano servizi AI interni.
- Verificare se il gateway è esposto a utenti non completamente fidati: l'autenticazione richiesta dall'exploit non equivale a autorizzazione.
- Rivedere le configurazioni api_base esistenti: qualsiasi endpoint interno o locale configurato prima della patch è potenzialmente indicativo di esposizione passata.
- Valutare l'attivazione di MLFLOW_GATEWAY_API_BASE_ALLOW_PRIVATE_IPS solo dopo mappatura esplicita dei servizi legittimi che necessitano accesso.
- Monitorare i log per richieste anomale verso endpoint metadata cloud o servizi interni precedentemente raggiungibili tramite il raw proxy route.
Perché questa vulnerabilità segnala una tendenza più ampia
Il caso CVE-2026-71211 si inserisce in un pattern ricorrente: le infrastrutture AI stanno replicando, a velocità compressa, l'evoluzione della sicurezza dei servizi web tradizionali. I gateway AI nascono come componenti di orchestrazione tra modelli e applicazioni; la necessità di autenticazione, autorizzazione e validazione dell'input emerge solo quando la superficie di attacco diventa evidente. MLflow non è un'eccezione, ma un campione di una categoria in rapida maturazione.
Il dato che resta non quantificato è l'estensione del rischio: le fonti non specificano quante installazioni eseguano il componente AI Gateway, né documentano exploit in-the-wild. La natura autenticata della vulnerabilità riduce la superficie rispetto a un attacco anonimo, ma in ambienti enterprise con molti utenti del gateway il profilo di rischio cambia significativamente. L'assenza di attribuzione del ricercatore e di dettagli sulle versioni specificamente affette lascia margini di incertezza sui sistemi legacy.
Domande frequenti
La vulnerabilità permette esecuzione di codice remoto?
No. L'advisory ZDI classifica esplicitamente la vulnerabilità come SSRF con information disclosure. Non emerge alcuna evidenza di remote code execution nel materiale disponibile.
Posso essere colpito se non uso il componente AI Gateway?
Le fonti non documentano impatti sulle installazioni MLflow che non attivino il gateway AI. La vulnerabilità è specifica del percorso di proxy raw gestito da quel componente.
Fonti
Ricevi DeafLetter
Una selezione settimanale di segnali, vulnerabilità e guide. Gli avvisi critici restano facoltativi.
Puoi cancellarti in ogni momento. Privacy policy.