AMD conferma due falle TPM 2.0: attestazioni false su Ryzen dal…

Due vulnerabilità nel firmware TPM 2.0 di AMD mettono a rischio la catena di attestazione hardware su processori Ryzen. Il firmware corretto è disponibile da maggio

AMD ha confermato l'11 agosto 2026 due vulnerabilità nel firmware TPM 2.0 che interessano processori Ryzen dalla serie 3000 alle serie AI, con punteggi CVSS 4.0 di 8.5 e 8.3. Il paradosso è che i firmware corretti erano già stati consegnati agli OEM tra maggio e giugno, mentre le piattaforme con Microsoft Pluton attendono ancora aggiornamenti. La scoperta, firmata da ricercatori Intel, espone una fragilità sistemica: il componente che dovrebbe garantire l'integrità del sistema diventa esso stesso vettore di falsificazione della fiducia.

Punti chiave

CVE-2026-6726 e CVE-2026-6727 colpiscono il reference code TPM 2.0 del Trusted Computing Group, non codice proprietario AMD; Intel fTPM risulta anch'esso affetto.
Entrambe richiedono accesso locale con privilegi elevati e minano la catena di attestazione hardware, consentendo generazione di chiavi di attestazione false.
I firmware corretti ComboAM4PI e ComboAM5PI sono stati distribuiti agli OEM tra il 18 maggio e il 31 maggio 2026; ASUS, MSI, GIGABYTE e ASRock hanno già rilasciato BIOS aggiornati.
Le piattaforme Ryzen AI con Microsoft Pluton non hanno ancora ricevuto patch: AMD prevede aggiornamenti per agosto 2026.

Il meccanismo: come si falsifica l'attestazione TPM

Le due vulnerabilità colpiscono meccanismi crittografici distinti ma convergono sullo stesso obiettivo: compromettere la prova che una chiave risieda effettivamente nel TPM. CVE-2026-6726 è un use-after-free causato da errore nella separazione di tipi di oggetto in memoria nel reference code TPM 2.0. Questo difetto può influire su TPM2_Certify, la funzione che certifica le proprietà di una chiave caricata nel modulo, lasciando residui di informazioni da oggetti precedentemente utilizzati.

CVE-2026-6727 è un timing side-channel nella decrittazione RSA-OAEP. I tempi di elaborazione diversi durante il controllo del padding creano una canalizzazione laterale misurabile: attraverso il cosiddetto attacco Manger, un attaccante con accesso locale può recuperare il plaintext crittografico e generare chiavi di attestazione false. Secondo il bollettino AMD-SB-7064 riportato da Igor's LAB, entrambe le vulnerabilità sono classificate come "non-AMD" perché originano nel reference code TPM 2.0 del Trusted Computing Group.

Il CERT/CC, che ha gestito la disclosure coordinata multi-vendor con codice VU#431093, conferma che entrambe le vulnerabilità richiedono accesso locale con privilegi elevati. Come riporta Igor's LAB citando il bollettino AMD: "Both attacks are local and require elevated privileges. There can therefore be no talk of a vulnerability that can simply be exploited from the Internet against arbitrary Ryzen PCs."

Una scoperta Intel che mette a nudo le reference implementation

Le vulnerabilità sono state scoperte dai ricercatori di sicurezza Intel Liran Perez, Zecharye Galitzky, Shai Sarfati e Yanai Moyal. Il fatto che siano stati ricercatori di Intel a individuare falle nel firmware TPM di AMD non è ironia di mercato, ma indicatore di un problema strutturale: le reference implementation condivise nell'ecosistema TPM espongono tutti i vendor che le adottano senza modifiche sostanziali.

Il CERT/CC elenca Intel stessa come vendor affetto, con il suo fTPM (firmware TPM) marcato come "Affected" nella tabella delle parti interessate. Altri vendor come Dell, HP, Lenovo, Qualcomm, NVIDIA e VMware risultano invece con stato "Unknown" nel database CERT/CC, un limite che il dossier non permette di superare con affermazioni assertive. Ciò che emerge con chiarezza è che la vulnerabilità non riconosce confini competitivi: chiunque implementi il reference code TCG senza audit indipendente condivide la stessa superficie di attacco.

"The machine could pass device compliance checks and slip through conditional access gates while actually harboring malware, a backdoor, or unauthorized firmware."

Timeline e frammentazione: quando la patch non basta

I firmware corretti sono stati consegnati agli OEM con cronologie differenziate per piattaforma. Secondo VideoCardz, ComboAM4PI 1.0.0.11 per Ryzen 3000 è stato distribuito il 18 maggio 2026; ComboAM4v2PI 1.2.0.12 per Ryzen 4000/5000 il 27 maggio; ComboAM5PI 1.3.0.1b per piattaforme AM5 il 21 maggio, seguito da ComboAM5PI 1.2.0.3k il 31 maggio. I processori Ryzen Embedded hanno ricevuto aggiornamenti a luglio 2026, secondo TechSpot.

La frammentazione emerge nel passaggio dai firmware base ai BIOS dei singoli produttori. ASUS ha rilasciato ComboAM5 PI 1.3.0.1b su schede come la PRIME X870-P WIFI a giugno, seguito da una Patch A il 2 luglio. MSI, GIGABYTE e ASRock risultano anch'essi con aggiornamenti già disponibili. Tuttavia, TechTimes segnala che alcune schede madri AM4 più datate, come modelli ASUS B550, non ricevono aggiornamenti BIOS dal gennaio 2026. AMD prevede aggiornamenti per le piattaforme Ryzen AI con Microsoft Pluton ad agosto 2026, una data ancora da confermare al momento della pubblicazione.

Il rischio enterprise: quando la radice di fiducia marcia

L'impatto delle due vulnerabilità si misura sul presupposto fondamentale dell'architettura TPM: che la chiave di attestazione sia legata in modo inscindibile all'hardware. Se questo presupposto crolla, crolla la catena di fiducia su cui si reggono Windows 11, BitLocker, Secure Boot e i framework zero-trust enterprise. Una macchina compromessa può generare attestazioni TPM false, superare i controlli di compliance e accedere a risorse protette da conditional access gates pur ospitando malware o firmware non autorizzati.

Il rischio per gli utenti consumer è mitigato dai prerequisiti di accesso locale con privilegi elevati. Per le aziende con fleet gestite, invece, il problema si sposta su due piani: quante macchine sono state effettivamente aggiornate tra maggio e giugno senza che gli amministratori sapessero della criticità sottostante, e quante piattaforme Ryzen AI con Pluton restano esposte in attesa di patch. Il TCG raccomanda, oltre all'aggiornamento firmware, la revoca e ricreazione delle chiavi di attestazione e la migrazione da chiavi RSA a ECC dove possibile. Queste indicazioni sono presenti nelle fonti citate e riguardano specificamente la gestione post-patch delle chiavi compromesse.

Cosa fare adesso

Verificare la versione del firmware TPM nel BIOS: cercare ComboAM4PI 1.0.0.11 o successivo per piattaforme AM4 Ryzen 3000, ComboAM4v2PI 1.2.0.12 per Ryzen 4000/5000, ComboAM5PI 1.3.0.1b o 1.2.0.3k per AM5.
Controllare il sito del produttore della scheda madre per BIOS aggiornati: ASUS, MSI, GIGABYTE e ASRock hanno già rilasciato versioni corrette, ma la disponibilità varia per modello.
Per sistemi con BitLocker attivo, preparare il recovery key prima di aggiornare il BIOS: il cambio di firmware TPM può innescare richieste di recupero all'avvio.
Per piattaforme Ryzen AI con Microsoft Pluton, monitorare gli aggiornamenti previsti per agosto 2026: al momento della pubblicazione, il firmware corretto non risulta ancora distribuito.

La consapevolezza pubblica arriva a distanza di mesi dalla disponibilità tecnica delle correzioni, e questo ritardo è esso stesso parte del problema. Le infrastrutture che gestiscono migliaia di endpoint devono ora ricostruire retroattivamente lo stato di patch delle loro fleet, sapendo che il firmware corretto era già circolante quando nessuno ancora conosceva la criticità. È un caso studio su come la disclosure coordinata, pur essendo standard industriale, possa lasciare finestre di esposizione gestite solo a chi ha visibilità upstream.

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

Fonti

Fonti e riferimenti