Il 17 luglio 2025 NVIDIA ha rilasciato patch per CVE-2025-23266, una vulnerabilità critica nel NVIDIA Container Toolkit con punteggio CVSS 9,0 su 10,0. I ricercatori Wiz hanno dimostrato che un attaccante con accesso al container può ottenere privilegi sull'host tramite un Dockerfile di tre righe, compromettendo l'isolamento in servizi cloud AI multi-tenant.
- CVE-2025-23266 (CVSS 9.0/10.0) colpisce NVIDIA Container Toolkit fino alla versione 1.17.7 e GPU Operator fino alla 25.3.0; le versioni corrette sono 1.17.8 e 25.3.1 secondo The Hacker News.
- L'exploit sfrutta l'hook OCI
createContainerche esegue con working directory sul root filesystem del container e rispetta la variabileLD_PRELOADdall'ambiente, caricando librerie malevole in un processo privilegiato sull'host. - Wiz stima che il 37% degli ambienti cloud sia esposto alla vulnerabilità.
- L'advisory del GitHub Advisory Database classifica la falla come CWE-426: Untrusted Search Path con impatto su privilege escalation, data tampering, information disclosure e denial-of-service.
Il meccanismo: quando LD_PRELOAD diventa un'arma
Il nucleo del problema risiede nell'hook createContainer del toolkit NVIDIA. Questo hook, che il framework OCI (Open Container Initiative) invoca per inizializzare il runtime dei container GPU, presenta una configurazione critica: il suo working directory è impostato sul root filesystem del container, non su un percorso controllato dall'host.
Secondo i ricercatori Wiz Nir Ohfeld e Shir Tamari, citati da The Hacker News, "the createContainer hook executes with its working directory set to the container's root filesystem". Questo significa che qualsiasi libreria condivisa (shared object) inserita nell'immagine container è immediatamente referenziabile tramite path relativi.
A ciò si aggiunge il secondo elemento della catena: l'hook riconosce la variabile d'ambiente LD_PRELOAD anche quando proviene da un container non fidato. "By setting LD_PRELOAD in their Dockerfile, an attacker could instruct the nvidia-ctk hook to load a malicious library", spiega la citazione dei ricercatori Wiz. Il processo hook gira con privilegi elevati sull'host; il codice caricato eredita quel contesto. Il risultato è un container escape completo.
La banalità dell'attacco: tre righe per abbattere un mito
La dimensione più inquietante della vulnerabilità è la sua trivialità tecnica. Non servono chain di exploit sofisticate né tecniche di memory corruption: un Dockerfile di tre righe è sufficiente a impostare LD_PRELOAD e posizionare la libreria malevola nel percorso corretto. Questa accessibilità abbassa drasticamente la barriera all'attacco, rendendo la minaccia operativa per un range molto più ampio di threat actor.
"containers are not a strong security barrier and should not be relied upon as the sole means of isolation" — Wiz
L'avvertimento di Wiz non è retorico. Il 37% di esposizione cloud, riportato sempre dalla stessa fonte, indica che la configurazione vulnerabile è diffusa ben oltre i deployment sperimentali. In ambienti multi-tenant — dove provider come AWS, Google Cloud Platform e Microsoft Azure offrono istanze GPU NVIDIA a clienti distinti — la falla trasforma ogni container in un potenziale ponte verso i dati e i modelli dei tenant adiacenti.
La classificazione CWE-426 (Untrusted Search Path) nel GitHub Advisory Database conferma la natura strutturale del difetto: il software cerca risorse critiche usando un percorso di ricerca fornito esternamente, senza validazione. Non è un bug di implementazione marginale, ma una violazione di principio nell'architettura di isolamento.
Il paradosso dell'AI security: futurismo vs. fondamenta
L'industria dell'intelligenza artificiale dedica risorse crescenti a scenari di rischio speculativi: attacchi adversarial ai modelli, jailbreak dei LLM, data poisoning sofisticato. CVE-2025-23266 riporta l'attenzione su un piano più prosaico e più urgente. "While the hype around AI security risks tends to focus on futuristic, AI-based attacks, 'old-school' infrastructure vulnerabilities in the ever-growing AI tech stack remain the immediate threat that security teams should prioritize", osserva Wiz.
La constatazione ha un corollario operativo: gli stack AI crescono più velocemente della loro superficie di attacco documentata. Il NVIDIA Container Toolkit è componente standard in migliaia di pipeline MLOps; la GPU Operator è strumento di deployment Kubernetes onnipresente nei cluster AI enterprise. Una falla in questi strati infrastrutturali ha raggio d'azione molto maggiore di una vulnerabilità applicativa isolata.
Il caso richiama inoltre CVE-2024-0132, precedente vulnerabilità nel medesimo toolkit con identico punteggio CVSS 9.0. La ricorrenza di bug critici con gravità equivalente suggerisce che il modello di threat surface dello stack GPU NVIDIA meriterebbe revisione sistematica, al di là della risposta puntuale ai singoli advisory.
Cosa fare adesso
- Aggiornare NVIDIA Container Toolkit alla versione 1.17.8 o successiva e NVIDIA GPU Operator alla versione 25.3.1 o successiva, come indicato nei rispettivi advisory.
- Verificare la presenza di container non autorizzati nei cluster GPU che eseguono immagini con variabili d'ambiente
LD_PRELOADpopolate; la semplicità dell'exploit rende rilevante anche il rilevamento post-compromissione. - Isolare i workload GPU multi-tenant con boundary di sicurezza aggiuntivi (hypervisor, microVM o nodi dedicati per tenant sensibili), dato che il container alone non garantisce isolamento contro questa classe di vulnerabilità.
- Rivedere le pipeline CI/CD che costruiscono immagini container GPU: la variabile
LD_PRELOADin un Dockerfile deve attivare review obbligatoria e blocchi automatici se non giustificata esplicitamente.
Perché questo caso segna un punto di svolta
CVE-2025-23266 non è una vulnerabilità esotica. È un bug di percorso di ricerca non fidato in un componente di sistema, di quelli che esistono dai tempi di Windows DLL hijacking. La sua criticità deriva dal contesto: è posizionato al cuore dell'infrastruttura cloud che alimenta l'espansione dell'AI generativa.
La combinazione di esposizione massiccia (37% cloud), gravità estrema (CVSS 9.0) e trivialità dell'exploit (tre righe) crea un profilo di rischio che le organizzazioni non possono più gestire con patch management reattivo. Richiede una riprogettazione dei presupposti: nel momento in cui le GPU diventano risorse condivise tra tenant, il confine container-come-sicurezza si rivela insufficiente. Wiz ha ragione nel dire che i container non vanno affidati come unico mezzo di isolamento; la domanda è quanti operatori infrastrutturali abbiano già interiorizzato questa verifica.
Domande frequenti
Quali prodotti NVIDIA sono coinvolti concretamente?
Il GitHub Advisory Database elenca NVIDIA Container Toolkit e NVIDIA GPU Operator come prodotti affetti. Le versioni vulnerabili sono quelle fino alla 1.17.7 e fino alla 25.3.0 rispettivamente; le versioni corrette sono la 1.17.8 e la 25.3.1.
È necessario un accesso privilegiato al container per sfruttare la falla?
Secondo The Hacker News, l'attaccante deve avere la capacità di eseguire un container e di impostare variabili d'ambiente nel Dockerfile. Il container escape avviene successivamente, elevando i privilegi oltre i limiti del container stesso.
La vulnerabilità è attivamente sfruttata?
Il dossier non documenta exploit in-the-wild confermati. Il pericolo rimane elevato per la trivialità della proof-of-concept e l'esposizione cloud misurata da Wiz.
Fonti
- https://thehackernews.com/2025/07/critical-nvidia-container-toolkit-flaw.html
- https://fidelissecurity.com/vulnerabilities/cve-2025-23266/
- https://github.com/advisories/GHSA-vmg3-7v43-9g23
- https://fidelissecurity.com/threatgeek/
- https://fidelissecurity.com/service-support/
- https://fidelissecurity.com/wp-content/uploads/2023/08/Fidelis-Security-White-Alternate-with-Orange-flat-with-3D-dots-01-1.svg
- https://fidelissecurity.com/solutions/
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.