GPUStack, la falla critica CVE-2026-102895 finisce nel catalogo CISA: cosa fare subito

Un software pensato per far girare modelli di intelligenza artificiale su cluster di GPU si è trasformato in una porta aperta per chi vuole entrare nell’infrastruttura di un’azienda. La CISA, l’agenzia statunitense per la sicurezza informatica, ha inserito nel catalogo delle vulnerabilità sfruttate attivamente una falla critica di GPUStack, il gestore open source di cluster usato per servire modelli AI. È la notizia di sicurezza AI da seguire oggi, soprattutto se nella tua azienda o nei tuoi progetti usi inferenza self-hosted.

Il dettaglio che rende il caso particolarmente interessante è che non si parla di un attacco contro un modello, ma contro il livello di controllo che sta sotto. Ed è lì che, in questo momento, si concentra il rischio reale.

Cosa è successo: la falla CVE-2026-102895 di GPUStack

Il 9 novembre 2026 la CISA ha aggiunto al catalogo Known Exploited Vulnerabilities la vulnerabilità CVE-2026-102895, con punteggio CVSS 3.1 pari a 9,8, quindi nella fascia critica. Le agenzie federali americane hanno tempo fino al 12 novembre per rimediare, una scadenza molto stretta che dice già molto sull’urgenza.

GPUStack è un gestore di cluster GPU open source, distribuito con licenza Apache 2.0, che permette di servire modelli su nodi worker collocati in sede, su Kubernetes o nel cloud pubblico. Il server centrale fa da piano di controllo: decide dove girano i modelli e con quali permessi. Chi ne prende il controllo, di fatto, comanda l’intero cluster.

Come funziona il bypass di autenticazione

Secondo la nota di ricerca della Cloud Security Alliance, il problema è un errore di fiducia nell’origine della rete. Le richieste non autenticate che sembrano provenire dall’indirizzo di loopback, cioè 127.0.0.1, vengono trattate come se arrivassero dall’amministratore integrato. Questo comportamento è attivo per impostazione predefinita, perché il parametro force_auth_localhost è disattivato di serie.

Il punto debole è che l’origine può essere simulata. Un reverse proxy installato sulla stessa macchina, oppure un’intestazione X-GPUStack-Real-IP costruita ad arte, bastano a far credere al server che la richiesta sia locale. Il risultato è un accesso da amministratore senza alcuna credenziale.

In pratica, un errore di progettazione piccolo e comprensibile apre un varco enorme.

Le versioni coinvolte e la correzione

Sono vulnerabili tutte le versioni precedenti alla 2.2.0, che rimuove il percorso di amministrazione automatica da loopback. La raccomandazione degli analisti è però di passare direttamente alla 2.2.2, che corregge anche CVE-2026-102894, un’altra falla separata da 9,1 di CVSS legata a un bypass dell’autenticazione SAML. Il progetto è consultabile sul repository ufficiale di GPUStack.

Lo sfruttamento reale: reverse shell sui nodi worker

La voce nel catalogo KEV non è teorica. Il database NVD registra uno sfruttamento in the wild contro un’installazione alla versione 2.1.1. Gli attaccanti, una volta ottenuti i privilegi da amministratore, hanno usato l’endpoint POST /v2/inference-backends/from-yaml per registrare backend di inferenza malevoli.

Quei backend hanno lanciato reverse shell sui nodi worker. Tradotto: l’attaccante ha ottenuto esecuzione di comandi sulle macchine che ospitano le GPU, dove spesso girano carichi costosi, dati sensibili e credenziali del cloud.

Va detto con onestà che i resoconti pubblici sono ancora scarni. La stessa nota segnala l’assenza di numeri sulle vittime, di date del primo sfruttamento e di indicatori di compromissione pubblicati. Non sappiamo quindi quanto sia diffusa la campagna, e questo è un motivo in più per non aspettare conferme prima di muoversi.

Chi ha scoperto e segnalato la falla

L’avviso su GitHub attribuisce la scoperta indipendente a un gruppo di ricercatori della Johns Hopkins University, mentre la segnalazione dello sfruttamento attivo viene attribuita a Javier Sixto di ulex.fr. È un ricordo utile di come la ricerca accademica e quella indipendente continuino a fare da primo campanello d’allarme sul software AI open source.

Perché conta per chi lavora con l’AI

Nell’ultimo anno la conversazione sulla sicurezza dell’AI si è concentrata soprattutto sui modelli: jailbreak, prompt injection, capacità offensive. Il caso GPUStack ricorda che l’attacco più semplice passa quasi sempre dagli strumenti di contorno. Un orchestratore con una scorciatoia di fiducia vale più di un modello da miliardi di parametri, perché consegna subito macchine, dati e chiavi.

È un tema che il sito segue da tempo da angolazioni diverse. Se vuoi il quadro sul versante dell’AI usata per trovare falle, leggi l’analisi su GPT-6 Cyber di OpenAI, mentre sul tema dell’affidabilità dei numeri sulle vulnerabilità trovate dall’AI c’è il bilancio di VulnCheck su Project Glasswing. Il filo comune è che trovare e correggere falle è sempre più un lavoro che coinvolge modelli, ma la responsabilità di installare le patch resta umana.

Anche il fronte difensivo si sta muovendo con strumenti nuovi, come mostra la verifica formale del codice di Signal descritta nell’articolo su AlphaProof Code di DeepMind. Ma finché un server di controllo si fida di un indirizzo IP dichiarato dal client, nessuna prova formale ti salva.

Il rischio dell’AI self-hosted

Sempre più aziende, studi professionali e freelance scelgono di far girare modelli aperti sulla propria infrastruttura, per costi, privacy e controllo dei dati. È una scelta sensata, ma sposta su di te la responsabilità che prima era del fornitore cloud. Aggiornamenti, segmentazione di rete, gestione delle chiavi e monitoraggio diventano compiti tuoi.

Un cluster di inferenza esposto, con un pannello di amministrazione raggiungibile da internet, è oggi un bersaglio concreto.

Cosa fare subito se usi GPUStack

Le indicazioni degli analisti sono abbastanza chiare e si possono riassumere in tre mosse, da fare in quest’ordine.

• Aggiorna alla versione 2.2.2 o successiva e ricrea i container, in modo che la nuova immagine sia davvero in uso.
• Se non puoi aggiornare subito, imposta force_auth_localhost su true, elimina l’intestazione X-GPUStack-Real-IP sul proxy di frontiera e limita l’accesso a una VPN o a un gateway che richieda autenticazione.
• Cerca tracce di compromissione, perché l’aggiornamento da solo non pulisce un sistema già violato.

Come cercare una compromissione già avvenuta

L’aggiornamento non rimuove utenti o chiavi API creati dall’attaccante, né ripulisce gli host compromessi. Controlla quindi gli account amministratore e le chiavi API, in particolare quelle con ambito generico, e revoca tutto ciò che non hai creato tu. Verifica poi i backend di inferenza registrati, cercando voci inattese caricate tramite from-yaml.

Esamina i log alla ricerca di chiamate API non autenticate e di richieste POST verso quell’endpoint, e ispeziona i nodi worker per individuare shell inattese. Se trovi qualcosa, ruota i token dei worker e le credenziali del provider cloud, poi controlla l’account cloud per risorse che non riconosci.

Cosa possiamo imparare da questo caso

La lezione generale riguarda il principio della fiducia zero. Un servizio che concede privilegi da amministratore a chiunque sembri locale presume che la rete interna sia sicura, e questa presunzione è sbagliata da anni, soprattutto in ambienti con proxy, container e Kubernetes dove ciò che appare locale spesso non lo è.

Per chi sviluppa strumenti AI open source il messaggio è altrettanto netto: le impostazioni predefinite sono la vera superficie di attacco, perché la maggior parte degli utenti non le cambia mai. Una configurazione sicura di serie vale più di mille pagine di documentazione.

Per chi li usa, invece, vale una regola semplice: tratta ogni componente dell’infrastruttura AI come qualsiasi altro servizio esposto, con inventario, patch regolari e monitoraggio.

Conclusioni

La vulnerabilità di GPUStack è un esempio da manuale di come il rischio dell’AI non stia solo nei modelli, ma negli strumenti che li fanno funzionare. Con uno sfruttamento già confermato e una scadenza federale fissata al 12 novembre, il tempo per agire è adesso.

Se gestisci un cluster di inferenza, controlla oggi stesso la versione installata e, se serve, aggiorna e verifica i log. Se invece lavori con l’AI per clienti o per la tua attività, condividi questa notizia con chi si occupa dell’infrastruttura: può evitare una brutta sorpresa. Per altri aggiornamenti sulla sicurezza dell’intelligenza artificiale continua a seguire il sito.

Fonte primaria di riferimento: nota di ricerca della Cloud Security Alliance.