AMD AutoUpdate: RCE ignorata, milioni di PC a rischio

AMD AutoUpdate vulnerabilità RCE è il software che dovrebbe tenerti al sicuro — eppure può diventare il vettore d’attacco preferito di un aggressore. Il 27 gennaio 2026, il ricercatore di sicurezza noto come mrbruh ha scoperto che AMD AutoUpdate scarica eseguibili tramite connessioni HTTP non cifrate, senza verificare le firme digitali del codice. AMD ha classificato la segnalazione come “out of scope” e ha chiuso il report.

Il giorno dopo, il ricercatore ha reso tutto pubblico.

1. Cosa fa AMD AutoUpdate e perché è installato sul tuo PC
2. La falla tecnica: HTTP + nessuna firma = RCE
3. Come funziona l’attacco man-in-the-middle in questo scenario
4. La risposta di AMD: “out of scope”
5. Divulgazione responsabile: cosa dice l’industria
6. Cosa fare se hai una GPU AMD
7. FAQ

Cosa fa AMD AutoUpdate e perché è installato sul tuo PC

AMD AutoUpdate è il componente del pacchetto AMD Software (Adrenalin Edition) responsabile del download e dell’installazione automatica di aggiornamenti per driver GPU e software correlati. Viene installato di default su qualsiasi sistema Windows che esegua i driver AMD, ed è presente su milioni di macchine consumer e gaming in tutto il mondo.

Il suo funzionamento è semplice in apparenza: contatta periodicamente i server AMD, verifica se esiste una versione più recente del pacchetto software e, se sì, scarica ed esegue l’aggiornamento. Il problema è nel come avviene quel download.

AMD AutoUpdate vulnerabilità RCE: HTTP senza firma = codice eseguibile

Analizzando il traffico di rete generato dal componente di aggiornamento, mrbruh ha identificato due debolezze critiche che si sommano:

• Download tramite HTTP non cifrato: gli eseguibili dell’aggiornamento vengono scaricati su connessioni HTTP in chiaro, non HTTPS. Il traffico è visibile e modificabile da chiunque sia posizionato tra il client e i server AMD.
• Assenza di verifica della firma digitale: prima di eseguire il binario scaricato, AutoUpdate non controlla se l’eseguibile è firmato crittograficamente da AMD. Qualsiasi file ricevuto dal processo di aggiornamento viene eseguito senza validazione.

Il ricercatore ha inoltre notato che AMD utilizza un URL etichettato come “Development” in ambiente di produzione — un segnale di controllo qualità quantomeno discutibile nell’infrastruttura di update.

La combinazione di questi due elementi configura una vulnerabilità di Remote Code Execution (RCE): un attaccante può sostituire l’eseguibile legittimo con codice arbitrario, che verrà eseguito con i privilegi di sistema del software di aggiornamento.

Per fare un paragone riconoscibile nel settore: è lo stesso errore concettuale alla base di molti supply chain attack degli ultimi anni — fidarsi di un canale di distribuzione senza autenticarne il contenuto.

Come funziona l’attacco man-in-the-middle in questo scenario

Un attacco man-in-the-middle (MITM) richiede che l’aggressore si interponga tra il client (il PC con AMD AutoUpdate) e il server di aggiornamento AMD. Esistono diversi scenari concreti in cui questo è fattibile:

• Rete Wi-Fi pubblica: coffee shop, aeroporti, hotel. Un attaccante sulla stessa rete può intercettare e manipolare il traffico HTTP.
• Router domestico compromesso: firmware obsoleto o credenziali di default aprono la porta a chi vuole fare ARP spoofing sulla rete locale.
• Accesso infrastrutturale ISP: attori state-sponsored con accesso a nodi di rete del provider Internet possono operare MITM su scala, colpendo potenzialmente milioni di utenti AMD in simultanea.

Una volta posizionato nel percorso del traffico, l’attaccante sostituisce il file .exe legittimo di AMD con un payload malevolo. AutoUpdate riceve il file, non esegue alcuna verifica crittografica e lo esegue. Il payload parte con i privilegi del processo di aggiornamento — spesso elevati.

Abbiamo già analizzato tecniche simili nell’articolo sul malware mascherato da utility PC, dove DLL sideloading e supply chain attack seguono una logica analoga.

La risposta di AMD: “out of scope”

Il 27 gennaio 2026 mrbruh segnala la vulnerabilità ad AMD tramite il canale ufficiale del programma bug bounty. Il 5 febbraio 2026 AMD chiude il ticket classificandolo come “out of scope” — la falla esiste, ma non rientra nei criteri del programma di ricompensa della società.

L’esperto di sicurezza Tptacek ha commentato la vicenda su Hacker News precisando che AMD non nega l’esistenza della falla, ma la esclude semplicemente dal perimetro del proprio programma. Una distinzione sottile che, dal punto di vista dell’utente esposto, cambia poco.

Il 6 febbraio 2026 mrbruh pubblica una disclosure tecnica completa. Il post è stato successivamente rimosso dal blog del ricercatore, ma la notizia aveva già raggiunto la comunità di sicurezza internazionale.

Divulgazione responsabile: cosa dice l’industria

Il caso AMD AutoUpdate riaccende un dibattito che la comunità della sicurezza affronta continuamente: cosa succede quando un vendor rifiuta di riconoscere una vulnerabilità?

Il modello di Coordinated Vulnerability Disclosure (CVD) prevede che il ricercatore dia al vendor un periodo ragionevole per produrre una patch prima di rendere pubblica la falla. La finestra standard è 90 giorni, adottata da Google Project Zero e da CERT/CC come riferimento dell’industria. In questo caso AMD ha risposto in 9 giorni — ma con un rifiuto, non con una patch.

Il problema strutturale è evidente: i programmi bug bounty con perimetri rigidi possono creare zone grigie dove vulnerabilità reali rimangono non corrette semplicemente perché non rientrano nelle categorie previste dalla policy aziendale. Una falla non corretta è una falla che resta aperta, indipendentemente da come viene classificata.

Un altro caso emblematico di risposta lenta da parte del vendor riguarda Edge che salvava le password in chiaro nella RAM, dove la policy del vendor ha allungato il tempo di esposizione degli utenti.

Cosa fare se hai una GPU AMD

La AMD AutoUpdate vulnerabilità RCE non ha ancora una patch ufficiale. Finché AMD non rilascia un aggiornamento che migri i download su HTTPS con verifica della firma, le opzioni disponibili sono:

1. Disinstallare AMD AutoUpdate: il componente può essere rimosso separatamente dal pannello di controllo di Windows — Programmi e funzionalità, cercando “AMD AutoUpdate”. I driver GPU rimangono funzionanti.
2. Aggiornare i driver manualmente: scaricare i driver direttamente da amd.com/support tramite HTTPS e verificare la firma del file prima di eseguirlo.
3. Evitare reti non fidate con aggiornamenti automatici attivi: non connettersi a reti Wi-Fi pubbliche con AMD AutoUpdate in esecuzione in background.
4. Monitorare i security bulletin AMD: verificare se versioni future includono la fix su amd.com/en/resources/product-security.

🎬 Vuoi approfondire questo argomento?
Ho realizzato contenuti dedicati su YouTube @tuttelevitediunmaker dove analizzo vulnerabilità di questo tipo in modo pratico, con esempi reali di traffic analysis. Se vuoi supportare questo progetto e accedere a contenuti esclusivi, trovi tutto su Patreon.
👉 YouTube | Patreon
#tuttelevitediunmaker

FAQ — Domande frequenti

Cosa rischia chi usa AMD AutoUpdate sul proprio PC?
Chi ha AMD AutoUpdate installato su Windows è esposto alla AMD AutoUpdate vulnerabilità RCE tramite man-in-the-middle. Un aggressore posizionato tra il PC e i server AMD può sostituire l’eseguibile legittimo dell’aggiornamento con codice malevolo, eseguito con i privilegi del processo di update. Il rischio è concreto su reti Wi-Fi pubbliche e in ambienti con router compromessi.

Perché AMD ha rifiutato di correggere la vulnerabilità segnalata?
AMD ha classificato la segnalazione come “out of scope” rispetto al proprio programma bug bounty, indicando che la falla non rientra nel perimetro definito dalla policy aziendale. AMD non ha negato l’esistenza del problema, ma ha escluso l’obbligo di intervenire in base alle regole del proprio programma di ricompensa.

Come funziona un attacco MITM su un software di aggiornamento?
Un attacco man-in-the-middle su un updater si basa sull’intercettazione del traffico HTTP tra il client e il server del vendor. L’attaccante sostituisce il file eseguibile legittimo con un payload malevolo. Se il software non verifica la firma crittografica dell’eseguibile ricevuto, lo esegue senza accorgersi della sostituzione — tecnica alla base di molte campagne di supply chain attack.

Come si disabilita AMD AutoUpdate senza rimuovere i driver GPU?
AMD AutoUpdate può essere disinstallato separatamente dai driver tramite Pannello di controllo — Programmi e funzionalità, cercando “AMD AutoUpdate”. I driver Radeon rimangono operativi. In alternativa, è possibile bloccare l’accesso di rete al processo tramite Windows Firewall con regole in uscita.

AMD ha rilasciato una patch per questa vulnerabilità?
Al momento della divulgazione pubblica da parte di mrbruh, il 6 febbraio 2026, AMD non aveva rilasciato alcuna patch né comunicato una data di correzione. La vulnerabilità è stata resa pubblica senza fix disponibile a causa del rifiuto di AMD di riconoscerla nel perimetro del proprio bug bounty. Si raccomanda di verificare periodicamente i security bulletin ufficiali AMD.

Questa vicenda solleva una domanda che non ha ancora risposta definitiva: chi definisce il perimetro di sicurezza di un prodotto — il vendor o gli utenti che lo usano ogni giorno? I programmi bug bounty sono strumenti utili, ma non possono sostituire la responsabilità di chi produce software installato su milioni di macchine.

#tuttelevitediunmaker