Il bug che AMD non voleva correggere: storia di una vulnerabilità finita sotto i riflettori

Una finestra della console che compariva a intervalli regolari su un nuovo PC da gioco ha dato il via a una scoperta inaspettata.

Un ricercatore indipendente ha identificato una vulnerabilità di esecuzione di codice remoto nel sistema di aggiornamento automatico associato ad alcuni strumenti software di AMD. La vicenda, resa pubblica negli scorsi giorni dopo oltre quattro mesi di embargo, mette in luce quanto una singola debolezza nella catena di aggiornamento possa amplificare il rischio di compromissione su milioni di sistemi.

Come è stata scoperta la falla

L’analisi è partita dal reverse engineering dell’AutoUpdater AMD. Esaminando i file di configurazione, il ricercatore ha rilevato che l’applicazione recuperava un file XML con le informazioni sugli aggiornamenti disponibili tramite HTTPS, ma i riferimenti ai pacchetti eseguibili puntavano a indirizzi HTTP non cifrati.

Questa configurazione apre la strada a un attacco Man-in-the-Middle: un aggressore in grado di intercettare il traffico può modificare il contenuto prima che raggiunga il sistema bersaglio. Il punto critico era che il software eseguiva il file scaricato senza verificare l’autenticità del pacchetto tramite firma digitale, trasformando ogni aggiornamento in un potenziale vettore di compromissione.

Disclosure, embargo e risposta di AMD

La vulnerabilità è stata segnalata ad AMD il 6 febbraio 2026. In una prima fase è stata considerata fuori ambito dal programma bug bounty, poiché richiedeva uno scenario di intercettazione del traffico e coinvolgeva strumenti opzionali.

Il team di sicurezza interno ha poi rivalutato il caso riconoscendone la validità. AMD ha comunicato l’intenzione di assegnare un CVE, sviluppare una correzione e riconoscere il ricercatore, richiedendo nel frattempo la rimozione temporanea dell’articolo tecnico. La trattativa si è protratta per oltre 120 giorni, superando i classici periodi di disclosure coordinata.

Durante l’embargo è emerso anche un difetto secondario: l’AutoUpdater mostrava difficoltà nella gestione di un reindirizzamento tra domini, bloccandosi prima di completare il download. Questo ha ridotto la praticabilità concreta dell’attacco originale, senza però eliminare la debolezza progettuale di fondo.

La correzione e i dubbi che restano

Poco prima della fine dell’embargo AMD ha illustrato la soluzione adottata: la funzionalità di aggiornamento automatico è stata spostata dall’installer all’applicazione principale, con connessioni ora interamente protette e controlli aggiuntivi sull’integrità dei file.

l ricercatore ha confermato il passaggio completo a HTTPS, ma ha contestato un aspetto della soluzione dichiarata: secondo la sua analisi, il controllo applicato ai file scaricati si baserebbe su CRC-32 anziché su una firma digitale crittografica. CRC-32 rileva errori accidentali di trasmissione, ma non garantisce protezione contro manipolazioni intenzionali da parte di un attaccante motivato.

Il caso ricorda a tutta l’industria che la sicurezza degli updater richiede una catena di fiducia completa: HTTPS, firme digitali, validazione dei certificati e algoritmi crittografici moderni. Gli aggiornamenti automatici sono la prima linea di difesa; la fiducia degli utenti dipende dalla solidità dell’intero processo.