Intel e AMD patchano 70 falle: due criticità nei data center

Intel e AMD hanno diffuso advisory per circa 70 falle. Due criticità con CVSS oltre 9 in ROCm e driver ESXi rischiano data center: servono patch.

Contenuto

Intel e AMD patchano 70 falle: due criticità nei data center
Intel e AMD patchano 70 falle: due criticità nei data center

Secondo SecurityWeek, Intel e AMD hanno pubblicato advisory il 12 e il 13 maggio 2026 per correggere circa 70 vulnerabilità complessive. Tra queste, due criticità con punteggi CVSS superiori a 9 colpiscono il ROCm Device Metrics Exporter di AMD e il driver Intel Data Center Graphics per VMware ESXi. La combinazione di un errore di design nel binding di rete e di un buffer overflow in infrastrutture virtualizzate richiede interventi immediati nelle operations dei data center.

Punti chiave
  • Secondo SecurityWeek, Intel e AMD avrebbero corretto complessivamente circa 70 falle: circa 24 attribuite a Intel e quasi 45 ad AMD, distribuite rispettivamente in circa 13 e 15 advisory.
  • CVE-2026-0481 ha un punteggio CVSS di circa 9.2: il ROCm Device Metrics Exporter espone di default la porta 50061 su tutte le interfacce di rete, permettendo accesso remoto non autenticato al server gRPC.
  • CVE-2026-20794 è valutata circa 9.3: un buffer overflow nel driver Intel Data Center Graphics per VMware ESXi potrebbe portare a privilege escalation ed esecuzione di codice.
  • La pagina Product Security di AMD conferma la pubblicazione di almeno 15 advisory il 12 maggio 2026, ma i dettagli tecnici specifici di CVE-2026-0481 restano per ora riportati esclusivamente da SecurityWeek.

ROCm e la porta 50061: quando il default espone il data center

Il ROCm Device Metrics Exporter è un componente dell’ecosistema open source di AMD per il monitoraggio delle GPU in cluster HPC e AI. Secondo SecurityWeek, CVE-2026-0481 ha un punteggio CVSS di circa 9.2. La vulnerabilità deriva dalla scelta di binding dell’applicazione sull’indirizzo 0.0.0.0 con la porta 50061: in pratica, il servizio gRPC è raggiungibile su ogni interfaccia di rete attiva senza autenticazione predefinita. Nei data center moderni questa architettura cancella il confine tra rete di management e rete di produzione.

Questa configurazione bypassa la segmentazione di rete tipica dei data center. Un attaccante con accesso alla rete interna può interagire direttamente con il server di gestione GPU, alterando la configurazione o causando denial of service. AMD, via SecurityWeek, ha riconosciuto che il binding non restrittivo permette modifiche non autorizzate.

"Unrestricted IP address binding in the AMD Device Metrics Exporter (ROCm ecosystem) could allow a remote attacker to perform unauthorized changes to the GPU configuration, potentially resulting in loss of availability" — AMD (via SecurityWeek)

Il problema non è solo un bug di implementazione, ma un errore di design nel modello di threat assumption: il software presume che l’ambiente circostante sia fidato, ipotesi che nei moderni data center multi-tenant non regge. Esporre un canale di management GPU su 0.0.0.0 equivale a collocare un terminale di controllo sulla soglia della rete, rendendo vano ogni firewall downstream.

Driver Intel per VMware ESXi: il pericolo del buffer overflow in hosts virtualizzati

SecurityWeek attribuisce a Intel una criticità con punteggio CVSS di circa 9.3 nel driver Data Center Graphics per VMware ESXi. La falla è descritta come un buffer overflow. L’impatto potenziale include privilege escalation ed esecuzione di codice arbitrario. In un ambiente ESXi, un difetto nel driver grafico che collega guest e host rappresenta un vettore ad alto impatto perché tocca l’hypervisor alla base del consolidamento server.

ESXi è tra gli hypervisor più diffusi nelle infrastrutture enterprise. Tuttavia, i dettagli tecnici specifici del buffer overflow e le condizioni di sfruttabilità non sono verificabili indipendentemente dalle fonti disponibili: l’advisory Intel non è stato fornito nel dossier redazionale. Non è noto se la falla richieda accesso locale alla VM o possa essere innescata da remoto, né è possibile quantificare il rischio reale senza il bollettino ufficiale.

Ciò che rende la segnalazione degna di attenzione è la combinazione tra un punteggio superiore a 9 e la natura del target. I driver per virtualizzazione sono spesso aggiornati con cicli più lenti rispetto al sistema operativo, il che allarga la finestra di esposizione. Finché Intel non pubblicherà il testo completo dell’advisory, gli amministratori dovranno agire per eccesso di prudenza.

Advisory AMD del 12 maggio: conferme ufficiali e numeri ancora da verificare

La pagina Product Security di AMD elenca advisory pubblicati il 12 maggio 2026, confermando che il vendor ha effettivamente rilasciato correzioni in quel giorno. Si tratta di almeno 15 bollettini, un volume significativo che copre diversi componenti dello stack software e hardware. La data coincide con l’articolo di SecurityWeek, ma la corrispondenza esatta tra i 15 advisory e il numero complessivo di falle non è verificabile pubblicamente.

SecurityWeek parla di circa 70 vulnerabilità totali, suddivise in circa 24 per Intel e quasi 45 per AMD. Questi numeri, però, non sono corroborati da fonti primarie indipendenti. AMD non riporta il totale di quasi 45 vulnerabilità né i dettagli di CVE-2026-0481 nella sua pagina di sicurezza consultata. La stessa fonte menziona circa 13 advisory Intel, ma la data di pubblicazione esatta degli advisory Intel non è disponibile direttamente nelle fonti a disposizione.

L’assenza di advisory primari dettagliati per entrambe le criticità costituisce un limite informativo concreto. Gli amministratori devono agire sulla base delle informazioni disponibili, ma attendere il rilascio completo dei bollettini per la valutazione del rischio esatto. Finché Intel e AMD non renderanno pubbliche le descrizioni tecniche complete, ogni prioritizzazione rimane una stima fondata sulle sole rilevazioni di SecurityWeek.

Cosa fare adesso

  • Isolare il binding di rete del ROCm Device Metrics Exporter. Nei cluster GPU, verificare se il servizio è attivo e forzarne l’ascolto esclusivamente sull’interfaccia di management o su una VLAN dedicata, eliminando l’esposizione su 0.0.0.0 fino all’arrivo della patch AMD.
  • Audire i driver Intel ESXi. Per le infrastrutture virtualizzate, identificare le versioni del driver Data Center Graphics installate sugli host e pianificare l’aggiornamento attraverso il vendor o il canale VMware come priorità per gli ambienti multi-tenant.
  • Monitorare i portali ufficiali. Tenere sotto osservamento la pagina Product Security di AMD e il portale Intel Security Center per il rilascio degli advisory completi: senza i dettagli tecnici ufficiali non è possibile stabilire se le condizioni di attacco si applichino al proprio ambiente.
  • Rafforzare la segmentazione di rete. Entrambe le falle descritte da SecurityWeek amplificano il rischio in ambienti dove la flat network permette la reachability tra workload e controllori. Separare fisicamente o logicamente la rete di management GPU da quella degli host ESXi riduce la superficie d’attacco esposta.

La sequenza di maggio conferma che la superficie di attacco dei data center non si misura più solo nei core della CPU, ma nei servizi di supporto attorno alle GPU e all’hypervisor. Il caso del ROCm exporter mostra come una scelta di default possa neutralizzare interi layer di difesa perimetrale. Finché i vendor non pubblicheranno i dettagli completi, la sicurezza di questi ambienti dipenderà dalla velocità con cui i team di operations restringono l’esposizione senza attendere la patch definitiva.

Domande frequenti

Il ROCm Device Metrics Exporter è installato di default in tutti i server AI/HPC?

Non è chiaro dalle fonti se il pacchetto sia incluso in tutte le distribuzioni ROCm o solo in specifiche configurazioni di monitoraggio. Senza un inventario preciso dei nodi risulta impossibile quantificare l’esposizione reale dell’intero parco macchine.

Perché CVE-2026-20794 Intel ha un punteggio CVSS più alto del ROCm exporter?

Secondo SecurityWeek il valore di circa 9.3 riflette la potenziale escalation di privilegi e l’esecuzione di codice in un hypervisor, ma senza l’analisi del vector string non è possibile stabilire se la differenza rispetto al circa 9.2 di AMD derivi dalla complessità dell’attacco o dall’impatto sull’infrastruttura host.

Le patch rilasciate da Intel e AMD sono sufficienti a mitigare entrambe le criticità?

Non è possibile verificare indipendentemente l’efficacia o la completezza delle correzioni finché i bollettini tecnici ufficiali non saranno disponibili per la revisione della community.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Link utili

Apri l'articolo su DeafNews