NVIDIA e AWS correggono quattro falle tra GPU, agenti e tool cloud

🛡️ Executive Summary

• NVIDIA corregge CVE-2026-47483 in DCGM Exporter, dove richieste di profiling non autenticate possono esaurire risorse e interrompere il monitoraggio delle GPU.
• AWS chiude una command injection nel plugin databases-on-aws che può trasformare contenuti ingeriti da un agente in comandi locali quando viene invocato l’helper vulnerabile.
• Altre due falle AWS espongono bearer token CodeCatalyst tramite permessi locali errati e file del build host attraverso symlink nel processo di bundling CDK.

Quattro vulnerabilità diverse mostrano lo stesso problema nell’infrastruttura AI e cloud: componenti apparentemente ausiliari stanno acquisendo privilegi e visibilità sufficienti per diventare veri confini di sicurezza. NVIDIA corregge un problema nel monitoraggio DCGM utilizzato nei cluster GPU, mentre AWS interviene su un plugin per agenti AI, sull’estensione Visual Studio Code e sul processo di bundling del Cloud Development Kit. Nessuno degli advisory documenta una campagna di exploitation attiva, ma gli impatti attraversano livelli sensibili: indisponibilità della telemetria GPU, esecuzione di comandi, furto di token e pubblicazione involontaria di file provenienti dalla macchina di build.

DCGM Exporter può essere mandato in crash senza autenticazione

CVE-2026-47483 interessa gli endpoint /debug/pprof di NVIDIA DCGM Exporter. Secondo il security bulletin pubblicato da NVIDIA, richieste di profiling concorrenti e non autenticate possono provocare un consumo incontrollato delle risorse, con conseguenze valutate fino a denial of service e information disclosure. La falla ha CVSS 8,2 e interessa sia DCGM sia il relativo exporter; NVIDIA indica rispettivamente DCGM 4.5.3 e DCGM Exporter 4.8.2 come versioni aggiornate. Il rischio operativo è diventato più concreto quando Lava Security ha misurato l’esposizione reale del servizio, individuando circa 2.100 server che pubblicavano telemetria DCGM su Internet e oltre 12.000 GPU identificabili. Non significa che tutti questi sistemi fossero vulnerabili alla CVE, ma dimostra che un servizio pensato per l’osservabilità di cluster costosi può diventare simultaneamente fonte di reconnaissance e superficie DoS. È un problema particolarmente sensibile mentre le AI factory NVIDIA concentrano acceleratori, networking, energia e raffreddamento in infrastrutture sempre più dense.

Leggi anche: LMCache espone server AI a RCE attraverso ZeroMQ e pickle

AWS Agent Plugins trasforma input dell’agente in una command injection

La vulnerabilità più interessante sul piano agentico è CVE-2026-107322, corretta nel plugin databases-on-aws della raccolta Amazon Agent Plugins for AWS. Il bollettino AWS 2026-130 precisa un elemento essenziale: il codice vulnerabile non è un servizio di rete in ascolto. Un soggetto remoto non autenticato può però fornire contenuto costruito ad hoc che venga successivamente ingerito dall’agente; l’esecuzione di un comando sul sistema operativo diventa possibile se l’agente invoca l’helper locale con il valore manipolato. Il comando gira con i privilegi del processo che esegue l’helper e la falla non compromette direttamente Aurora DSQL né aggira i privilegi del database. Sono vulnerabili le versioni da 1.0.0 a 1.7.0 e la correzione arriva con databases-on-aws 1.7.1. La dinamica approfondisce il problema già osservato con AgentCore e Strands, dove dati controllabili potevano attraversare il confine tra decisione dell’agente ed esecuzione degli strumenti: quando un LLM governa helper locali, la validazione deve avvenire nel punto in cui l’input diventa comando, non soltanto nel prompt.

AWS Toolkit lasciava il bearer token CodeCatalyst leggibile localmente

CVE-2026-107332 riguarda invece AWS Toolkit for Visual Studio Code prima della versione 4.10.0. Durante la connessione a un CodeCatalyst Dev Environment, il componente salvava il bearer token dell’utente in un file con permessi world-readable e non eliminava la cache al termine della sessione. Il bollettino AWS 2026-129 chiarisce quindi che il vettore è locale: un altro utente o processo capace di accedere al filesystem della stessa macchina poteva leggere il file e recuperare il token. La versione 4.10.0, distribuita il 9 luglio, limita i permessi al proprietario e rimuove la cache quando il Dev Environment viene fermato. Non è una RCE remota, ma in una workstation di sviluppo un bearer token rappresenta un oggetto particolarmente sensibile perché può trasferire a un processo diverso la sessione e le autorizzazioni associate all’utente. Il caso ricorda perché tool di sviluppo, server MCP e componenti cloud devono essere trattati come parte della superficie delle credenziali e non come semplici estensioni dell’IDE.

AWS CDK poteva incorporare file esterni alla build attraverso symlink

Il quarto problema, CVE-2026-107608, colpisce aws-cdk-lib prima della versione 2.267.0. Durante l’asset bundling eseguito attraverso Docker, un Dockerfile poteva introdurre nell’output file o directory raggiunti mediante symbolic link anche quando quel contenuto non era stato fornito come input previsto al processo. Nel bollettino AWS 2026-131 la mitigazione per chi non può aggiornare immediatamente consiste nel verificare container e dipendenze utilizzati per il bundling, evitando esecuzione di codice non attendibile nell’ambiente. Il rischio principale è la confidenzialità della macchina di build: contenuti presenti sull’host possono finire nell’asset che viene successivamente pubblicato o distribuito. È una superficie affine ai problemi già osservati quando workflow, pacchetti e tool AWS trasformano la pipeline CI/CD nel punto in cui un input non fidato raggiunge file e credenziali del sistema. La correzione non richiede modifiche a CloudFormation: interessa la libreria che prepara l’asset prima del deployment.

Il punto comune è il software che circonda compute e credenziali

Le quattro falle non appartengono alla stessa catena d’attacco e non devono essere presentate come una campagna coordinata. Condividono però una caratteristica architetturale: colpiscono il software posto intorno alle risorse più preziose. DCGM Exporter osserva le GPU; l’Agent Plugin collega un agente a strumenti database; AWS Toolkit gestisce una sessione di sviluppo; CDK prepara gli artefatti da distribuire. Nessuno di questi componenti è il workload finale, ma ciascuno dispone di accesso sufficiente a produrre conseguenze concrete quando il trust boundary è disegnato male. L’evoluzione segue quella emersa nelle precedenti vulnerabilità AWS su SSM Agent e strumenti di automazione, dove il rischio cresceva proprio perché software amministrativo e pipeline lavoravano con privilegi superiori a quelli di una normale applicazione.

Continua con:

AWS e Cisco correggono vulnerabilità in AgentCore, Strands e jsii

Veeam, Terraform MCP e n8n espongono credenziali e accessi aziendali

Patchare non basta se monitoring, agenti e build restano troppo esposti

Le remediation sono differenti ma indicano una priorità comune. NVIDIA richiede l’aggiornamento di DCGM e DCGM Exporter e l’esposizione pubblica del monitoring dovrebbe essere valutata separatamente dalla sola presenza della CVE. AWS richiede databases-on-aws 1.7.1, Toolkit for Visual Studio Code 4.10.0 e aws-cdk-lib 2.267.0, accompagnando gli update con workaround specifici quando l’upgrade immediato non è possibile. Il dato più importante è che nessuno dei quattro casi giustifica allarmismi su compromissioni già avvenute: vulnerabilità e superficie esposta non equivalgono a exploitation confermata. Impongono però una revisione del modello operativo. In un’infrastruttura moderna telemetria GPU, helper degli agenti, token dell’IDE e host di build devono essere protetti con la stessa attenzione riservata al workload che servono, perché è proprio attraverso questi livelli laterali che un errore apparentemente periferico può raggiungere compute, identità o dati sensibili.