Dell CSM e AWS EFS: Kubernetes espone storage, secret e nodi root

🛡️ Executive Summary

• Dell corregge vulnerabilità CSM che consentono accesso amministrativo senza autenticazione, token forgiati e root sui nodi Kubernetes.
• La falla più grave rompe il confine tra cluster e storage backend, esponendo credenziali amministrative delle array registrate.
• AWS corregge nel driver EFS CSI una mount option injection sfruttabile da chi possiede privilegi di creazione dei PersistentVolume.

Lo storage di Kubernetes non è più un elemento periferico del cluster. I nuovi bollettini Dell e AWS mostrano come il livello che collega container, orchestratore e sistemi di persistenza possa trasformarsi in un percorso verso credenziali amministrative, Secret, policy RBAC e privilegi root sui nodi. Dell ha corretto una serie di vulnerabilità critiche nei Container Storage Modules, mentre AWS ha chiuso una mount option injection nell’Amazon EFS CSI Driver. Non sono problemi equivalenti e non esiste evidenza pubblica, nei bollettini dei vendor, di exploitation attiva per queste vulnerabilità; condividono però un punto: chi controlla il layer storage può aggirare separazioni che l’architettura Kubernetes presuppone affidabili.

Dell CSM rompe il confine tra Kubernetes e storage enterprise

L’advisory DSA-2026-448 pubblicato da Dell contiene numerose correzioni, ma due vulnerabilità cambiano immediatamente il rischio operativo. CVE-2026-63688, CVSS 10, interessa il server gRPC csm-authorization-storage: un attaccante remoto non autenticato può ottenere accesso alle credenziali amministrative dei backend storage registrati, superando completamente il modello di autorizzazione CSM. CVE-2026-63692, anch’essa CVSS 10, colpisce authorization proxy e tenant service e può portare un soggetto senza credenziali a privilegi amministrativi sull’intero servizio di autorizzazione, con possibilità di intervenire sulle risorse storage dei tenant. È un salto rispetto al precedente problema CSM sulle credenziali hardcoded già analizzato da Matrice Digitale: qui l’esposizione non dipende soltanto dalla presenza di un segreto statico, ma da funzioni critiche che non applicano correttamente l’autenticazione.

Leggi anche: TeamPCP e il worm cloud-native che trasforma Docker e Kubernetes in un’arma industriale

Dal singolo Custom Resource al root dei nodi

Il secondo blocco del dossier Dell dimostra perché il rischio non si ferma allo storage. CVE-2026-67269, CVSS 9,9, interessa il reconciler della Custom Resource ContainerStorageModule: un utente remoto con privilegi bassi ma capace di sottoporre la risorsa può arrivare a root sui nodi del cluster e, secondo Dell, compromettere l’intero insieme di nodi attraverso una singola submission. CVE-2026-67273 utilizza invece una debolezza nel template engine per consentire lettura cluster-wide dei Kubernetes Secret e creazione di risorse RBAC a livello di cluster. A queste si aggiungono CVE-2026-54472, legata a credenziali hardcoded nell’Authorization module, e CVE-2026-61421, che riguarda il progetto ormai archiviato karavi-authorization e un JWT signing secret pubblicato nella documentazione. Dell richiede l’aggiornamento a CSM 1.18.0 o successivo e, per il problema dei token, la rotazione immediata dei JWT signing secret. Non sono indicati workaround. La lezione coincide con quella emersa nelle vulnerabilità EKS e nei problemi Kubernetes raccolti nel KEV: il controllo delle Custom Resource e dei componenti operator non è un dettaglio di configurazione, perché questi oggetti possono comandare componenti con privilegi molto più elevati dell’utente che li crea.

AWS EFS CSI: un attributo diventa una mount option

AWS affronta un problema diverso ma nello stesso punto architetturale. La security advisory 2026-120 descrive CVE-2026-103505 nell’Amazon EFS CSI Driver, il componente che consente ai cluster Kubernetes di utilizzare Amazon Elastic File System. Un attore che possiede già privilegi per creare un PersistentVolume può inserire opzioni di mount aggiuntive attraverso l’attributo mounttargetipmap: valori separati da virgole nella mappa JSON vengono interpretati dalla mount utility come parametri distinti. Sono interessate le versioni dalla 3.1.0 alla 3.4.2, mentre la 3.5.0 corregge il problema. Il requisito dei privilegi modifica radicalmente il livello di rischio rispetto alle CVE Dell: non si tratta di un accesso remoto pre-auth, ma di un abuso di una capacità Kubernetes già concessa. È proprio per questo che AWS indica come workaround la restrizione della creazione di PersistentVolume e StorageClass agli amministratori tramite RBAC. Il problema conferma quanto già emerso nelle precedenti correzioni AWS su EFS e altri componenti cloud: la configurazione dichiarativa diventa superficie di attacco quando viene trasformata direttamente in argomenti operativi.

Continua con:
cPanel, un account hosting può diventare root: tre falle rompono l’isolamento
Terraform, 5 provider malevoli eseguono codice già con terraform init

Chi rischia e come cambia la mitigazione

Le due famiglie di vulnerabilità richiedono priorità differenti. Negli ambienti Dell CSM la verifica deve partire dalla presenza delle versioni interessate, dall’esposizione dei servizi Authorization e dalla rotazione dei secret prevista dal vendor, perché le vulnerabilità dominanti comprendono accesso senza autenticazione e percorsi verso privilegi amministrativi o root. Per AWS EFS CSI il controllo principale riguarda invece chi può creare PersistentVolume e StorageClass e quali versioni del driver sono installate: l’upgrade alla 3.5.0 elimina la falla, mentre la riduzione dei privilegi RBAC limita la possibilità che un utente non fidato manipoli gli attributi di mount. In entrambi i casi il messaggio operativo è identico: non basta proteggere l’API server di Kubernetes se operator, CSI driver e proxy di autorizzazione possiedono le chiavi per attraversare i confini del cluster. Lo storage è ormai parte del control plane di sicurezza, perché contiene dati, credenziali e meccanismi attraverso i quali i workload ottengono persistenza; trattarlo come un semplice servizio infrastrutturale significa sottostimare il blast radius di una compromissione.