TPM vulnerabile su milioni di CPU AMD: perché il BIOS va aggiornato

Il chip TPM (Trusted Platform Module 2.0) dovrebbe rappresentare uno dei punti più difficili da aggirare nella catena di fiducia di un PC moderno. Conserva materiale crittografico, registra misure sull’avvio della macchina e permette a sistemi locali o remoti di verificare che chiavi e informazioni sull’integrità provengano realmente dal dispositivo atteso. Proprio per questo le vulnerabilità CVE-2026-6726 e CVE-2026-6727 emerse a ridosso di ferragosto 2026 hanno fatto suonare un campanello d’allarme.

I problemi interessano il codice di riferimento TPM 2.0 del Trusted Computing Group (TCG) e AMD ha confermato che le proprie implementazioni firmware presenti in un vastissimo numero di processori risultano coinvolte.

Il problema ha una portata particolare anche per il mondo Windows. Microsoft richiede TPM 2.0 per Windows 11 e usa il componente in varie funzioni di sicurezza, dal Measured Boot alla protezione delle chiavi, fino agli scenari di attestazione dello stato del dispositivo. La specifica TPM 2.0 risale ormai a oltre un decennio fa, ma il requisito imposto da Windows 11 l’ha trasformata in una tecnologia praticamente onnipresente sui PC recenti. Le due falle pubblicate l’11 agosto 2026 dal TCG colpiscono tutte le revisioni interessate del reference code fino alla v184 del 2025; AMD assegna loro, con CVSS 4.0, punteggi rispettivamente di 8,5 e 8,3.

Perché il TPM è molto più di un requisito di Windows 11

Il chip TPM non serve semplicemente a superare il controllo effettuato dal programma di installazione di Windows 11. È un processore crittografico con memoria protetta e un insieme ben definito di comandi: può generare e conservare chiavi, firmare dati, gestire contatori, produrre numeri casuali e registrare misurazioni nei Platform Configuration Registers, comunemente indicati come PCR.

Durante il Measured Boot, firmware, boot manager e altri componenti della sequenza di avvio contribuiscono progressivamente ai valori dei PCR. Un servizio di attestazione può quindi chiedere al TPM di firmare determinati PCR e confrontare il risultato con il log dell’avvio. In questo modo è possibile stabilire con maggiore affidabilità se una macchina si è avviata seguendo una configurazione ritenuta attendibile.

Altrettanto importante è la gestione delle chiavi. Una chiave privata può nascere all’interno del TPM e restare legata al componente, evitando che il sistema operativo debba manipolarla direttamente. Tecnologie come BitLocker utilizzano il TPM come parte del meccanismo che protegge il materiale necessario per sbloccare il volume.

Esistono poi TPM discreti, saldati sulla scheda madre, implementazioni integrate nell’hardware e soluzioni firmware. AMD utilizza da tempo un firmware TPM, o fTPM, che svolge le funzioni previste dalla specifica sfruttando l’infrastruttura di sicurezza della piattaforma anziché un chip TPM esterno dedicato. È proprio questa implementazione che AMD indica interessata dai problemi descritti dal TCG.

CVE-2026-6726: il TPM può certificare una chiave creata da un aggressore

La prima vulnerabilità, CVE-2026-6726, è probabilmente la più interessante da comprendere perché nasce da un errore nella gestione interna degli oggetti.

TCG la definisce “Improper Object Slot Reuse“: il codice di riferimento non separa correttamente gli slot usati per chiavi e oggetti da quelli impiegati per i contesti delle operazioni di hashing. L’attaccante carica un oggetto esterno tramite comandi come TPM2_LoadExternal, libera lo slot e induce successivamente il TPM a riutilizzare quella stessa area per una sequenza hash creata con TPM2_HashSequenceStart. Alcune informazioni appartenenti all’oggetto precedente possono però rimanere nello slot.

Con TPM2_Certify, il TPM può produrre una prova crittografica relativa a un oggetto che dovrebbe trovarsi sotto il suo controllo.

A causa del riutilizzo scorretto degli slot interni, il reference code può conservare metadati appartenenti a un oggetto precedente anche dopo che lo slot è stato assegnato a un’entità di tipo diverso. L’attaccante può quindi usare informazioni residue per costruire una certificazione apparentemente valida riferita a una chiave esterna, cioè a una chiave la cui parte privata non è mai stata generata né protetta dal TPM.

Una credenziale di questo tipo potrebbe poi servire a costruire attestazioni false, incluse quelle basate sui PCR utilizzate per dichiarare lo stato di salute di un dispositivo.

CVE-2026-6727 sfrutta invece il tempo impiegato dal TPM

La seconda vulnerabilità, CVE-2026-6727, non riguarda l’attestazione ma il modo in cui il TPM esegue alcune operazioni di decifratura RSA. In particolare, il problema interessa RSA-OAEP, uno schema che non cifra direttamente il messaggio “così com’è”: prima dell’operazione RSA aggiunge una struttura progettata per rendere la cifratura sicura anche contro attacchi basati su messaggi scelti.

Quando il TPM riceve un dato cifrato, deve quindi decifrarlo e controllare che la struttura OAEP risultante sia valida. Ed è proprio qui che nasce la falla. Il codice vulnerabile non impiega sempre lo stesso tempo per completare queste verifiche: alcune condizioni fanno terminare l’elaborazione leggermente prima, altre leggermente dopo.

Un aggressore con accesso privilegiato al TPM può inviare migliaia di messaggi cifrati costruiti appositamente e misurare con precisione i tempi di risposta. Ogni richiesta gli fornisce un piccolo indizio su ciò che il TPM ha trovato durante la decifratura. Il dispositivo non rivela mai direttamente il contenuto in chiaro, ma il tempo impiegato finisce per comunicare indirettamente informazioni che dovrebbero restare segrete.

TCG spiega che la lacuna di sicurezza può consentire un Manger’s attack, una tecnica specifica contro RSA-OAEP. L’aggressore modifica progressivamente i messaggi cifrati inviati al TPM e usa i tempi di risposta per capire se il valore decifrato soddisfa determinate condizioni. Ogni risposta permette di restringere l’intervallo dei valori possibili; ripetendo il procedimento tante volte, diventa possibile ricostruire il messaggio originario senza conoscere la chiave privata RSA.

Ryzen 3000, 5000, 7000, 9000 e molte altre CPU AMD interessate

AMD ha pubblicato il bollettino AMD-SB-7064 confermando che i suoi fTPM risultano interessati: la lista è molto lunga e comprende numerose generazioni di processori desktop, mobile, workstation ed embedded.

Tra i prodotti più diffusi compaiono Ryzen 3000, Ryzen 4000, Ryzen 5000, Ryzen 6000, Ryzen 7000, Ryzen 8000 e Ryzen 9000, oltre alle relative varianti mobili. AMD elenca inoltre Ryzen AI 300, Ryzen AI 400, Ryzen AI Max 300, Threadripper, Threadripper PRO, Ryzen Z1 e Z2, diversi Ryzen Embedded e alcune famiglie EPYC.

Per l’utente di un PC Ryzen, la conseguenza pratica consiste nell’applicazione della correzione sotto forma di aggiornamento del BIOS. AMD distribuisce infatti la patch ai produttori hardware sotto forma di aggiornamenti della piattaforma; sono poi ASUS, MSI, Gigabyte, ASRock, gli OEM dei notebook e dei PC assemblati a integrare il nuovo firmware nei rispettivi BIOS/UEFI.

Conviene quindi controllare la pagina di supporto relativa allo specifico modello di scheda madre, notebook o sistema preassemblato. Il numero della versione del BIOS, da solo, dice poco se confrontato con un modello differente: ciò che interessa è verificare nelle note di rilascio la presenza di un AGESA o di una revisione PI almeno pari a quella indicata da AMD per la propria famiglia di processori.

Prima di aggiornare il firmware occorre inoltre considerare BitLocker. Un aggiornamento UEFI può modificare misure registrate nei PCR e ingenerare la richiesta della chiave di ripristino al riavvio. È quindi fondamentale verificare che le chiavi di ripristino siano accessibili e disponibili.