Lava scopre migliaia di server GPU esposti e una vulnerabilità di monitoraggio NVIDIA ad alta gravità

L’infrastruttura che supporta un modello di IA può rivelare una quantità sorprendente di informazioni prima che qualcuno vi acceda. Un endpoint di monitoraggio pubblico può divulgare le GPU presenti in un server, il loro utilizzo e il software che le circonda. Una falla nello stesso servizio di monitoraggio può trasformare la visibilità in un rischio di disponibilità.

Una nuova ricerca di Lava, pubblicata l’8 ottobre, descrive entrambi i problemi. L’azienda di sicurezza ha identificato circa 2.100 host NVIDIA DCGM Exporter pubblicamente accessibili che segnalavano più di 12.000 GPU uniche senza autenticazione. Durante l’indagine, Lava ha anche scoperto una vulnerabilità ad alta gravità che potrebbe consentire a un aggressore non autenticato di esaurire le risorse e far crashare il monitoraggio delle GPU.

NVIDIA ha assegnato al problema CVE-2026-47483, lo ha valutato 8.2, Elevata e ha rilasciato un aggiornamento. I risultati mettono sotto i riflettori una parte meno appariscente dell’infrastruttura IA: i servizi utilizzati per osservare il calcolo costoso necessitano di una protezione propria.

Cosa hanno scoperto i ricercatori — e cosa significano i numeri

La ricerca originale di Michael Katchinskiy di Lava descrive quattro scansioni effettuate tra marzo e maggio 2026. I totali rappresentano quindi osservazioni durante quel periodo di ricerca, piuttosto che un conteggio in tempo reale dei sistemi ancora esposti oggi.

Gli host hanno restituito telemetria GPU senza autenticazione. Lava ha osservato acceleratori dei data center, tra cui H100, H200 e Blackwell Ultra B300, oltre a sistemi RTX 4090 e 5090. L’azienda ha stimato che le GPU osservate rappresentassero più di 100 milioni di dollari in hardware, basandosi su valori di mercato approssimativi. Tale cifra indica il valore dell’hardware, non le perdite derivanti da un attacco.

Circa un quarto degli host DCGM esposti ha inoltre reso accessibili endpoint interni di profilazione Go. Questo sottoinsieme è importante: un endpoint di metriche esposto e un’interfaccia di profilazione vulnerabile e raggiungibile sono risultati correlati ma distinti. Sarebbe fuorviante descrivere tutte le oltre 12.000 GPU come vittime confermate di questa vulnerabilità.

Lava afferma di aver riprodotto l’esaurimento delle risorse in un ambiente controllato, anziché attaccare le distribuzioni pubbliche. La ricerca dimostra un potenziale percorso di attacco; non dimostra che le organizzazioni osservate siano state sfruttate o che i dati dei loro modelli siano stati rubati.

Perché il monitoraggio GPU rivela più di una semplice spia di stato

DCGM sta per Data Center GPU Manager. La documentazione del DCGM Exporter di NVIDIA spiega che l’esportatore raccoglie campi di telemetria GPU selezionati e li fornisce in un formato consumabile da Prometheus. Il suo endpoint di metriche è tipicamente utilizzato dai sistemi di monitoraggio per tenere traccia delle condizioni e dell’attività dei nodi GPU.

Temperatura, utilizzo, consumo di memoria, consumo energetico ed eventi di errore sono utili agli operatori perché descrivono il comportamento del calcolo. Quando le stesse informazioni sono accessibili a estranei, diventano una fonte di inventario e ricognizione.

Le risposte esposte possono rivelare i modelli hardware e dettagli operativi. Letture ripetute possono fornire indizi sui periodi di maggiore attività e sulle operazioni ricorrenti. Quegli indizi non provano che un modello specifico sia in fase di addestramento o in servizio, ma possono aiutare un esterno a restringere ciò che un ambiente contiene e quando è attivo.

Questa distinzione vale la pena di preservare. Leggere la telemetria GPU non è lo stesso che leggere i pesi, i dati di addestramento o i prompt di un modello. Tuttavia le informazioni sull’infrastruttura possono comunque essere preziose: un aggressore che apprende quali componenti e versioni sono presenti ha un punto di partenza più specifico rispetto a chi si confronta con un server opaco.

La vulnerabilità prende di mira il servizio di monitoraggio

Il bollettino di sicurezza di NVIDIA individua la falla negli endpoint del DCGM Exporter /debug/pprof endpoint. Richieste di profilazione non autenticate concorrenti possono causare un consumo incontrollato di risorse, con potenziali denial of service e divulgazione di informazioni. L’avviso accredita Michael Katchinskiy di Lava per averla segnalata.

La profilazione è una capacità diagnostica legittima. Aiuta gli sviluppatori a investigare il comportamento della CPU e della memoria all’interno di un’applicazione. Il problema di sicurezza sorge quando una funzione interna potenzialmente costosa diventa raggiungibile da un chiamante non attendibile senza controlli adeguati.

Secondo Lava, i ricercatori inizialmente sospettavano un errore di configurazione dell’operatore, per poi riprodurre il comportamento con il container ufficiale di NVIDIA. Hanno dimostrato che l’esaurimento delle risorse potrebbe far crashare l’esportatore, rimuovendo la visibilità sullo stato della GPU. La pressione su CPU e memoria potrebbe anche influire sui carichi di lavoro di addestramento o inferenza che condividono il server.

Il crash di un esportatore non interrompe necessariamente il carico di lavoro GPU stesso. L’effetto immediato è la perdita del monitoraggio; l’interferenza con i carichi di lavoro vicini dipende dall’isolamento delle risorse e dal deployment. Si tratta di una vulnerabilità del servizio software legata all’infrastruttura GPU, piuttosto che di una prova di un difetto nel silicio della GPU.

La distinzione è importante a livello operativo. Se il monitoraggio scompare durante un rallentamento del carico di lavoro, gli operatori devono indagare se il sistema di osservazione stesso sta fallendo. Considerare ogni metrica mancante come un semplice inconveniente di strumentazione potrebbe ritardare il riconoscimento di un incidente di consumo delle risorse.

L’esposizione si estende oltre lo strato GPU

L’annuncio di Lava descrive anche 12,096 host Node Exporter accessibili pubblicamente. Node Exporter riporta informazioni sul server e sul sistema operativo, piuttosto che svolgere lo stesso ruolo del DCGM Exporter. I dati esposti includevano dettagli hardware e software che potrebbero aiutare gli esterni a comprendere i sistemi che circondano i carichi di lavoro GPU.

Questi conteggi dovrebbero rimanere separati. Le osservazioni di Node Exporter rappresentano una scoperta di esposizione più ampia dell’infrastruttura, non un ulteriore conteggio di host confermati vulnerabili a CVE-2026-47483. Combinare le cifre offuscherebbe quale servizio e rischio ciascun numero rappresenta.

L’implicazione più ampia è che la sicurezza dell’IA deve includere il livello di monitoraggio e gestione. I controlli di accesso al modello non proteggono automaticamente un servizio di metriche distribuito accanto al modello. Un’organizzazione può mettere in sicurezza la propria API di inferenza lasciando un altro servizio sulla stessa infrastruttura aperto a Internet.

L’applicazione delle patch e la restrizione dell’accesso affrontano problemi diversi

L’aggiornamento di sicurezza è già disponibile. Il bollettino di NVIDIA identifica DCGM Exporter 4.8.2 come versione aggiornata e elenca anche DCGM 4.5.3. Gli operatori dovrebbero consultare l’avviso corrente e l’accoppiamento di versioni supportate per il loro deployment, invece di trattare quei due numeri di versione dei componenti come intercambiabili.

L’aggiornamento risolve la vulnerabilità divulgata. Tuttavia, da solo non garantisce che il punto finale delle metriche sia adeguatamente limitato. Un esportatore aggiornato può comunque divulgare telemetria se rimane raggiungibile pubblicamente senza controlli di accesso.

Il modello di sicurezza di Prometheus avverte esplicitamente contro l’esposizione di endpoint HTTP dei componenti a reti pubbliche senza misure appropriate. Le sue linee guida coprono metriche, API e interfacce di profiling Go, e riconoscono la possibilità di sovraccaricare questi servizi.

Per i team che esaminano la loro infrastruttura IA, ciò suggerisce una sequenza pratica:

• Inventario dei servizi di monitoraggio distribuiti. Stabilire quali esportatori, server Prometheus e interfacce diagnostiche sono in esecuzione, chi ne è proprietario e come sono raggiungibili.
• Applicare gli aggiornamenti di sicurezza del fornitore. Verificare la versione effettiva del software o del container distribuito, non solo un file di configurazione non ancora implementato.
• Limitare l’accesso al monitoraggio. Utilizzare reti private e firewall, gruppi di sicurezza e controlli di accesso appropriati affinché la telemetria sia disponibile all’infrastruttura di monitoraggio che ne ha bisogno.
• Rivedere i requisiti di profiling. Lava consiglia di lasciare --enable-pprof disabilitato a meno che il profiling non sia esplicitamente necessario; nelle versioni attuali, è opzionale.
• Verificare la visibilità dopo la rimessione in sicurezza. Confermare che la raccolta autorizzata funzioni ancora e che i fallimenti inaspettati dell’esportatore vengano notati.

Questi passaggi affrontano domande separate: se il software contiene la vulnerabilità, se una parte non affidabile può raggiungerlo e se un guasto di monitoraggio verrà rilevato. Risolverne uno non risolve gli altri.

L’infrastruttura IA necessita di un responsabile della sicurezza esplicito

La capacità GPU spesso si estende su infrastrutture gestite dal provider e servizi distribuiti dal cliente. Una revisione di sicurezza utile identifica chi mantiene ogni componente, chi controlla l’esposizione di rete e chi risponde quando viene segnalato un endpoint pubblico. Senza tali assegnazioni, un servizio di monitoraggio può trovarsi tra due team che si aspettano reciprocamente che l’altro lo metta in sicurezza.

La lezione centrale della ricerca di Lava è pratica: proteggere il calcolo IA include proteggere i sistemi che lo misurano e lo gestiscono. I nuovi risultati documentano un’esposizione storica significativa, mentre l’avviso di NVIDIA fornisce un percorso di rimedio per la vulnerabilità divulgata. Per gli operatori, la priorità è verificare il proprio deployment attuale, applicare la correzione e mantenere i servizi di osservazione interni entro il loro confine di fiducia previsto.