Bifrost AI gateway a rischio RCE: autenticazione spenta di default

Il 22 settembre 2026 la ricerca di JFrog Security Research ha reso pubblica una vulnerabilità critica nel gateway AI open-source Bifrost che consente esecuzione remota di comandi arbitrari senza credenziali. La combinazione di un endpoint di gestione MCP stdio non protetto e di un'autenticazione disabilitata fin dall'installazione trasforma ogni container Docker esposto in un potenziale punto di compromissione totale, con accesso diretto alle chiavi API di oltre 20 provider LLM.

Il meccanismo: MCP stdio come vettore di esecuzione immediata

Bifrost funge da gateway per il routing di richieste AI verso oltre 20 provider LLM. Il protocollo Model Context Protocol (MCP) di Anthropic consente di registrare "client" che espandono le capacità del modello. Tra i tipi di client supportati, quello stdio avvia un processo esterno specificando un comando arbitrario.

La vulnerabilità risiede nel flusso di registrazione via endpoint POST /api/mcp/client. Secondo la documentazione tecnica della scoperta, Bifrost avvia il comando specificato immediatamente, prima di qualsiasi handshake MCP, eseguendolo come utente del processo gateway. Questo meccanismo di "registrazione immediata" bypassa qualsiasi controllo di sicurezza intermedio e consente Remote Code Execution diretto.

Il problema è classificato CWE-306: Missing Authentication for Critical Function. Il record CVE ufficiale riporta il vettore completo CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — attacco remoto, complessità bassa, nessun privilegio richiesto, nessuna interazione utente, impatto massimo su confidenzialità, integrità e disponibilità.

"A critical vulnerability in Bifrost, an open-source AI gateway that routes requests to more than 20 LLM providers, allows an unauthenticated attacker to run arbitrary commands on the gateway server with a single HTTP request." — The Hacker News

Il "default pericoloso": quando il Docker ufficiale amplifica il rischio

La scelta progettuale più problematica non è tecnica ma architetturale: l'autenticazione di gestione è disabilitata di default. Il record CVE ufficiale riporta sinteticamente: "Auth off means every caller is a local admin". Questa configurazione, apparentemente pensata per semplificare il primo avvio, trasforma ogni istanza non riconfigurata in un server con privilegi amministrativi aperti.

La distinzione tra binario stock e containerizzazione è cruciale. Il binario precompilato lega l'API di gestione a localhost, limitando l'esposizione alla macchina locale. L'immagine Docker ufficiale lega invece a 0.0.0.0, rendendo l'API raggiungibile dall'esterno del container se la porta è pubblicata. Considerata la prevalenza dei deployment containerizzati nell'infrastruttura AI moderna, questa discrepanza trasforma una vulnerabilità locale in un vettore di attacco rete-reato.

L'esecuzione avviene come utente appuser nell'immagine Docker ufficiale. Poiché il gateway memorizza le chiavi API per ogni provider connesso, la compromissione del processo gateway concede immediato accesso a tali credenziali — con potenziale abuso di risorse AI a costi potenzialmente elevati per le organizzazioni vittime.

La catena delle versioni: cosa è corretto e cosa no

La gestione delle patch presenta una complicazione che gli operatori devono registrare con precisione. Secondo The Hacker News, che cita direttamente lo stato delle release:

• transports/v2.1.0: corregge entrambe le vulnerabilità. Il record CVE ufficiale conferma che questa versione "refuses an unauthenticated stdio registration with 403"; la PR GitHub #6757 implementa il rifiuto.
• transports/v2.0.0: corregge solo CVE-2026-86242 (caricamento plugin da URL HTTP, CVSS 8.1), ma "still allows it" per quanto riguarda CVE-2026-90898. Gli operatori su 2.0.0 restano esposti.
• linea 1.6.x fino a 1.6.11: priva di entrambe le correzioni. Secondo la fonte primaria, "The 1.6.x line through 1.6.11 contains neither fix".

La seconda vulnerabilità, CVE-2026-86242 con CVSS 8.1 HIGH, è stata scoperta da Or Peles dello stesso team JFrog e riguarda il caricamento di plugin da URL HTTP. Sebbene rilevante, il dossier non documenta impatti quantificati in scenari reali per questa seconda falla.

Cosa fare adesso

Il team JFrog Security Research ha formulato raccomandazioni specifiche che gli operatori possono tradurre in azioni immediate:

1. Aggiornare a transports/v2.1.0 o superiore: è l'unica versione che blocca la registrazione stdio non autenticata con risposta 403.
2. Abilitare esplicitamente l'autenticazione di gestione impostando governance.auth_config.is_enabled=true nella configurazione, anche su versioni che non possono essere aggiornate immediatamente.
3. Considerare compromesse le istanze con autenticazione disabilitata e API di gestione esposta, con conseguente rotazione delle chiavi API memorizzate nel gateway.
4. Verificare la binding address nei deployment containerizzati: se l'API di gestione non deve essere accessibile esternamente, limitare l'esposizione a interfacce interne o al container stesso.

Un pattern sistemico: MCP stdio nel threat landscape AI

La vulnerabilità Bifrost non è isolata. Il pattern di command injection attraverso il tipo di client MCP stdio sta emergendo come vettore sistemico nell'ecosistema AI infrastructure. Precedenti analoghi sono documentati su implementazioni Anthropic e LiteLLM, indicando che i difensori devono monitorare specificamente questo meccanismo di estensione.

La caratteristica distintiva è l'esecuzione "precoce": il comando viene avviato prima di qualsiasi validazione del protocollo MCP stesso. Questo design, apparentemente ottimizzato per la reattività, sacrifica la sicurezza per la latenza. L'assenza di autenticazione di default amplifica il difetto progettuale in una vulnerabilità critica.

Il dossier non specifica il numero esatto di istanze Bifrost esposte su Internet, né documenta exploit attivi in-the-wild. CVE-2026-90898 non è presente nel catalogo KEV di CISA al momento della pubblicazione. Tuttavia, la combinazione di CVSS 9.8, esposizione Docker comune e assenza di autenticazione richiede che gli operatori trattino questa vulnerabilità con priorità massima indipendentemente da conferme di sfruttamento attivo.

Domande frequenti

Perché il binario stock è meno esposto del container Docker?

Il binario precompilato lega l'API di gestione a localhost per default, limitando l'accesso alla macchina locale. L'immagine Docker ufficiale lega a 0.0.0.0, estendendo la superficie di attacco a tutte le interfacce di rete disponibili quando la porta è pubblicata.

Posso mitigare senza aggiornare?

L'abilitazione esplicita dell'autenticazione di gestione riduce la superficie di attacco, ma il dossier non documenta che questa sia una mitigazione completa equivalente al patch. L'aggiornamento a transports/v2.1.0 resta l'azione correttiva definitiva secondo le fonti.

Cosa rischio se ho già esposto l'API di gestione senza autenticazione?

Secondo la fonte primaria, JFrog consiglia di considerare compromesse tali istanze e di procedere alla rotazione delle chiavi API memorizzate. Il gateway conosce le credenziali di ogni provider LLM configurato; la loro esposizione consente abuso diretto delle risorse a costi a carico della vittima.

Fonti

• https://thehackernews.com/2026/09/critical-bifrost-ai-gateway-flaw-lets.html
• https://www.bleepingcomputer.com/news/security/wordpress-click2shell-flaw-lets-hackers-execute-php-on-the-server/
• https://www.bleepingcomputer.com/news/security/check-point-patches-management-server-zero-day-exploited-in-attacks/
• https://blog.netmanageit.com/critical-bifrost-ai-gateway-flaw-lets-attackers-run-commands-without-credentials/
• https://www.guardianmssp.com/2026/09/22/critical-bifrost-ai-gateway-flaw-lets-attackers-run-commands-without-credentials/
• https://www.cve.org/CVERecord?id=CVE-2026-90898
• https://nvd.nist.gov/vuln/detail/cve-2026-93616
• https://support.checkpoint.com/results/download/145601
• https://support.checkpoint.com/results/sk/sk1000171/#:~:text=Indication%20of%20Compromise
• https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2024-24919