CVE-2026-102895: exploit attivo contro GPUStack, bypass admin totale

Il 12 novembre 2025 il SANS Internet Storm Center ha confermato attacchi attivi contro GPUStack, piattaforma open-source per la gestione di cluster GPU usati in workload di intelligenza artificiale. La vulnerabilità CVE-2026-102895, con CVSS 9.8, consente il bypass completo dell'autenticazione e l'accesso amministrativo non autenticato. Il bug è stato corretto in versione 2.2.0 rilasciata a fine giugno, ma la divulgazione pubblica di fine luglio e l'assegnazione CVE del 4 novembre hanno accelerato l'adozione da parte degli attaccanti.

Il meccanismo: quando il loopback diventa backdoor

Il nucleo della vulnerabilità risiede nella funzione get_current_user di GPUStack, che tratta come fonte attendibile qualsiasi richiesta identificata come proveniente dall'indirizzo di loopback 127.0.0.1. Questa logica, nota come "localhost trust", eleva automaticamente tali richieste al ruolo di amministratore built-in senza ulteriore autenticazione.

Secondo l'advisory di GitHub Security, due vettori permettono di attivare questo comportamento. Il primo sfrutta un header HTTP X-GPUStack-Real-IP con valore 127.0.0.1: il server interpreta l'header come indicazione della sorgente reale e applica il privilegio di auto-admin. Il secondo vettore non richiede alcun header manipolato: quando GPUStack è posizionato dietro un reverse proxy sullo stesso host, ogni richiesta remota arriva al servizio con indirizzo TCP peer 127.0.0.1, attivando automaticamente il ramo di autenticazione privilegiata.

Questa seconda condizione è particolarmente rilevante per i deployment containerizzati e su Kubernetes, dove la presenza di sidecar proxy o ingress controller sullo stesso nodo è configurazione comune. L'advisory conferma la verifica end-to-end di questo scenario.

L'impatto: controllo totale del cluster AI

"Either path yields full, unauthenticated administrative access over the network: enumerate and modify users, models, workers, and configuration; mint persistent admin API keys" — GitHub Security Advisory GHSA-gj9m-f8ph-pmhr

La compromissione di un nodo GPUStack espone funzionalità critiche per l'infrastruttura AI. L'attaccante ottiene la capacità di enumerare e modificare utenti, modelli caricati, worker del cluster e configurazione di sistema. La creazione di API key amministrative persistenti garantisce accesso continuativo anche dopo eventuali remediation parziali.

L'advisory documenta inoltre la lettura delle credenziali dei worker e dei secret relativi a provider cloud, sebbene non specifichi la natura esatta di questi secret. Il takeover completo del cluster permette operazioni successive: secondo la stessa fonte, gli attacchi confermati in-the-wild hanno installato backend personalizzati con reverse shell.

Il campo: exploit attivi dall'IP 144.91.73.103

La conferma di sfruttamento attivo non è teorica. Johannes B. Ullrich del SANS Internet Storm Center ha segnalato richieste di exploit provenienti dall'IP 144.91.73.103, con un meccanismo che sfrutta proprio l'header X-GPUStack-Real-IP:

"If the 'X-Gpustack-Real-IP' identifies loopback (127.0.0.1) as the source of the request, Gpustack bypasses authentication (after all, the request originates from a trusted source)" — Johannes B. Ullrich, SANS.edu

L'advisory GitHub conferma indipendentemente l'exploit in-the-wild contro una specifica installazione GPUStack v2.1.1, con evidenza di backend malevoli e reverse shell. La convergenza tra le due fonti — l'indicatore di rete del SANS e la descrizione tecnica dell'advisory vendor — rende la minaccia immediata e verificata, non ipotetica.

Non emergono nel dossier sovrapposizioni infrastrutturali che colleghino l'attore all'IP 144.91.73.103 a campagne note allo stato attuale. L'estensione completa della campagna di exploit resta non quantificata: il dossier menziona un solo indirizzo IP, senza escludere la presenza di altri attori o infrastrutture.

Cosa fare adesso

Le azioni prioritarie derivano direttamente dalle fonti verificate:

• Aggiornare a GPUStack 2.2.0: il rilascio di fine giugno rimuove il comportamento di auto-admin per richieste loopback e irrigidisce la gestione dell'indirizzo client.
• Impostare force_auth_localhost=true: il parametro di configurazione, indicato dall'advisory come workaround, disabilita il bypass dell'autenticazione per le richieste locali.
• Filtrare l'header X-GPUStack-Real-IP: rimuovere o strip dell'header a livello di reverse proxy o WSD per impedire lo spoofing della sorgente.
• Verificare la presenza di accessi amministrativi anomali: controllare le sessioni esistenti, le API key create e i backend caricati in ambienti con versioni precedenti alla 2.2.0.

Il "localhost trust" come errore ricorrente

La logica di autenticazione basata sull'indirizzo di origine non è nuova: il trattamento di 127.0.0.1 come entità implicitamente attendibile ha generato vulnerabilità simili in protocolli e applicazioni per decenni. Ciò che rende CVE-2026-102895 significativo è il contesto di deployment. Le piattaforme AI infrastructure come GPUStack sono target ad alto valore: gestiscono risorse GPU costose, modelli proprietari e accesso a credenziali di provider cloud. La containerizzazione e l'uso pervasivo di sidecar proxy amplificano la probabilità che la condizione "same-host reverse proxy" — il secondo vettore, senza header — sia attiva in produzione senza che gli operatori ne siano consapevoli.

La ricerca che ha portato alla scoperta è stata condotta indipendentemente da quattro ricercatori: Nikko Enggaliano, Wei Yunzhou, Rui Yang e Haoyu Wang della Johns Hopkins University. La loro segnalazione ha prodotto un advisory con dettagli tecnici completi e verifica end-to-end, un livello di documentazione che ha permesso l'analisi tempestiva del SANS ISC non appena l'exploit è diventato attivo nel campo.

Domande frequenti

L'aggiornamento a 2.2.0 richiede modifiche alla configurazione esistente?

Il fix modifica il comportamento di default rimuovendo l'auto-admin loopback. Gli operatori che facevano affidamento su questa funzionalità per accessi locali devono valutare l'impatto sul proprio workflow e pianificare la transizione.

Il vettore same-host reverse proxy è più pericoloso dell'header spoofing?

Il vettore proxy è più insidioso perché non richiede conoscenza dell'header specifico: qualsiasi deployment con reverse proxy sullo stesso nodo è vulnerabile senza azione dell'attaccante sulla richiesta, se la configurazione di rete produce TCP peer 127.0.0.1.

L'IP 144.91.73.103 è ancora attivo?

Il dossier non contiene informazioni sulla persistenza temporale dell'attività da quell'indirizzo. La raccomandazione di aggiornare resta valida indipendentemente dallo stato attuale di specifici indicatori.

Fonti

• isc.sans.edu
• github.com