CVE-2026-90898: il gateway AI Bifrost esegue comandi

CVE-2026-90898 (CVSS 9.8), divulgata il 22 settembre 2026 da JFrog Security Research, converte una singola richiesta HTTP anonima in esecuzione di comandi sul server che ospita il gateway. Non servono credenziali e non serve alcun handshake di protocollo. Non serve alcuna interazione umana.

Bifrost è un gateway AI open source che instrada il traffico verso oltre venti provider LLM. La falla colpisce tutte le versioni del transport HTTP precedenti a 2.1.0 quando l'autenticazione dell'API di management resta spenta, cioè la configurazione di fabbrica, come riporta The Hacker News^[1].

Il meccanismo: una POST, un client stdio, un comando

Yuval Moravchick di JFrog Security Research ha ricostruito il percorso completo. Un attaccante registra un client MCP di tipo stdio con una POST anonima verso l'endpoint di management /api/mcp/client.

Bifrost avvia subito il comando indicato. L'avvio precede qualsiasi handshake del protocollo: il gateway esegue prima e verifica dopo. Il processo parte con l'utente del gateway, che nell'immagine Docker ufficiale si chiama appuser.

Qui arriva la parte che pesa davvero sul profilo di rischio. Il gateway custodisce le API key di ogni provider collegato, quindi chi esegue comandi dentro quel processo legge quelle chiavi e compra token a spese dell'azienda.

Una richiesta basta per passare dalla rete al portafoglio di credenziali dell'intera organizzazione. La superficie di attacco coincide con l'endpoint di amministrazione, esposto con privilegi di esecuzione e privo di un confine fra registrazione del componente e avvio del processo. La cronologia della divulgazione è tracciata anche nel thread pubblico di SecOpsNews^[2].

La falla gemella di inizio settembre

Il 6 settembre 2026 lo stesso gruppo di ricerca ha divulgato CVE-2026-86242 (CVSS 8.1), scoperta da Or Peles. Un attaccante anonimo registra un plugin il cui path è una URL HTTP.

Bifrost scarica il file, lo scrive come shared object temporaneo e lo carica con la funzione plugin.Open di Go. Sulle build collegate dinamicamente, richieste dai plugin Go personalizzati, il codice parte con l'utente del processo gateway.

Sulle build statiche, inclusa l'immagine Docker ufficiale, plugin.Open fallisce e l'impatto scende a una server-side request forgery. La correzione arriva in transports/v2.0.0.

Le due vulnerabilità condividono una radice precisa: l'API di management accetta la registrazione anonima di componenti che portano con sé una capacità di esecuzione. Il resto è dettaglio di implementazione. Una capacità di avvio abilitata in assenza di confini produce sempre questa classe di incidente.

Esposizione: binario su localhost, container su 0.0.0.0

Il binario Bifrost standard lega l'API di management a localhost. L'esposizione resta confinata alla macchina locale, e questo abbassa il rischio per chi installa a mano.

L'immagine Docker ufficiale lega invece a 0.0.0.0. Quando la porta viene pubblicata, l'API di amministrazione diventa raggiungibile da fuori dal container.

La divergenza fra i due default merita attenzione, perché il percorso Docker è quello che quasi tutti scelgono in produzione. Il deploy più comodo risulta anche il più esposto: un classico della supply chain agentica.

Chi orchestra il gateway con Kubernetes deve rileggere i Service e gli Ingress che pubblicano quella porta. Una regola di rete resta la difesa più rapida mentre l'aggiornamento attraversa il ciclo di rilascio, e costa poche ore di lavoro.

Matrice delle versioni: quale patch copre cosa

La sequenza delle correzioni richiede lettura attenta, perché una versione intermedia lascia aperto il buco principale.

• Linea 1.6.x fino a 1.6.11: priva di entrambe le correzioni
• transports/v2.0.0: chiude CVE-2026-86242, resta vulnerabile alla registrazione MCP anonima
• transports/v2.1.0: risponde 403 a chi tenta la registrazione anonima di un client MCP stdio

Chi resta su 2.0.0 si crede coperto e intanto espone ancora l'esecuzione di comandi. È il tipo di falso senso di sicurezza che trasforma una patch parziale in technical debt.

Per chi rinvia l'aggiornamento, JFrog indica tre misure: governance.auth_config.is_enabled impostato su true, credenziali robuste, listener di management fuori dalle reti aperte.

Il consiglio finale dei ricercatori è il più duro da digerire. Ogni istanza che ha girato con autenticazione spenta e API di management raggiungibile va trattata come compromessa, con rotazione delle virtual key e delle API key di tutti i provider collegati. La rotazione costa poche ore rispetto al conto di un provider LLM usato da terzi per settimane.

Il gateway LLM è un piano di controllo

Un componente che concentra le chiavi di venti provider diventa un punto singolo di compromissione. Il diagramma di architettura lo disegna come routing, ma la realtà operativa lo rende un piano di controllo capace di lanciare processi.

La security posture dei sistemi AI viaggia due o tre anni dietro alla maturità del resto dell'infrastruttura. Default permissivi, endpoint di amministrazione aperti, componenti caricati a runtime: lo stesso copione delle web app negli anni 2000 e delle API nel decennio successivo.

Il protocollo MCP amplifica la questione, perché registrare un client equivale ad autorizzare un processo. Chi tratta la registrazione come semplice configurazione ottiene esattamente questo risultato.

La domanda da porre a ogni fornitore di gateway resta una: quale confine separa la registrazione di un componente dalla sua esecuzione?

Tre domande per un team AI enterprise

Un audit serio del layer gateway parte da tre verifiche misurabili, da chiudere entro la settimana.

1. Quale versione del transport Bifrost gira in produzione, e l'API di management risulta raggiungibile da fuori dal cluster?
2. Le API key dei provider LLM sono state ruotate dopo l'ultimo periodo con autenticazione spenta?
3. Quali altri componenti dello stack agentico accettano registrazioni anonime con capacità di esecuzione?

La terza domanda produce le sorprese peggiori. Registry di tool, runner di plugin, sidecar di osservabilità: parecchi espongono superfici di amministrazione con lo stesso modello di fiducia implicita ereditato dal laboratorio.

Chi risponde a tutte e tre con dati verificabili possiede un inventario. Chi risponde a memoria possiede un'ipotesi, e in sicurezza un'ipotesi vale zero. Il risultato va scritto, con versione, data del controllo e nome di chi firma la verifica.

Decisioni per il prossimo ciclo di pianificazione

Per il CTO, il gateway LLM cambia categoria nel registro dei sistemi. Passa da middleware a componente critico, con le regole di accesso, logging e revisione che si applicano a un bastion host.

Per il capo dell'engineering, la versione minima diventa transports/v2.1.0 e la configurazione attesa prevede governance.auth_config.is_enabled su true. Una regola di CI che blocca le immagini con management aperto costa mezza giornata di lavoro.

Per il CFO, il rischio finanziario risulta diretto e misurabile. Le chiavi rubate generano consumo di token fatturabile, e il costo di un incidente supera di molto la spesa per un secret manager e una rotazione automatica.

Per il comitato acquisti, i contratti con i fornitori di gateway vanno rivisti su due punti: tempi di disclosure e default sicuri di fabbrica. Un vendor che consegna l'autenticazione spenta scarica il proprio debito tecnico sul cliente.

Bifrost resta un progetto serio, con un team che corregge e documenta le proprie falle. Il verdetto riguarda la configurazione di fabbrica, e quella va cambiata prima del prossimo deploy.