Intel ha trovato due flaw nel firmware TPM di AMD: la patch era…

AMD ha confermato l'11 agosto 2026 due vulnerabilità nel TPM 2.0 dei propri processori attraverso il security bulletin AMD-SB-7064. Le due criticità, scoperte da

{"main_topic":"cybersecurity","topics":["cybersecurity","vulnerabilita","cve","amd","firmware"]}

AMD ha confermato l'11 agosto 2026 due vulnerabilità nel TPM 2.0 dei propri processori attraverso il security bulletin AMD-SB-7064. Le due criticità, scoperte da ricercatori di sicurezza di Intel, interessano l'intera gamma Ryzen 3000-9000, Ryzen AI, Threadripper, EPYC ed Embedded. Paradossalmente, gli aggiornamenti firmware erano già stati distribuiti agli OEM tra maggio e giugno 2026: la disclosure pubblica è arrivata con settimane di ritardo rispetto alla mitigazione effettiva, invertendo il consueto ritmo della sicurezza firmware.

Punti chiave

Le vulnerabilità CVE-2026-6726 e CVE-2026-6727 originano nel codice di riferimento TPM 2.0 del Trusted Computing Group, non in codice proprietario AMD.
CVE-2026-6726 è un use-after-free in TPM2_Certify con CVSS 4.0 di 8.5; CVE-2026-6727 è un timing side-channel RSA-OAEP con CVSS 4.0 di 8.3.
Entrambe richiedono accesso locale con privilegi elevati e consentono di falsificare la catena di attestazione hardware.
ASUS, MSI, GIGABYTE e ASRock hanno già rilasciato BIOS aggiornati con i firmware corretti tra maggio e luglio 2026.

Il paradosso della catena di fiducia: quando Intel scova i flaw di AMD

Le due vulnerabilità sono state identificate da Liran Perez, Zecharye Galitzky, Shai Sarfati e Yanai Moyal, ricercatori del team sicurezza di Intel. Questo dettaglio non è aneddotico: il TPM 2.0 è un componente condiviso tra ecosistema, dove il codice di riferimento del Trusted Computing Group funge da base comune per implementazioni firmware di vendor diversi. AMD ha esplicitamente classificato le due CVE come "non-AMD", sottolineando che le radici del problema risiedono upstream.

Il CERT/CC ha emesso la vulnerability note VU#431093 l'11 agosto 2026, confermando la portata cross-vendor del problema. Nella vendor status table dell'advisory, Intel fTPM risulta anch'essa elencata come "Affected". La tabella mostra però molti vendor — Qualcomm, NVIDIA, Amazon, Dell, HP, Lenovo, VMware — in stato "Unknown", a indicare che la disclosure coordinata non ha raggiunto uniformità di copertura.

"This does not simply mean that 'the TPM password is cracked'; instead, the chain of trust is attacked that systems are supposed to use to prove that keys are actually protected inside the TPM." — Igor'sLAB

Come funzionano gli attacchi: falsificare l'identità del dispositivo

CVE-2026-6726 sfrutta un errore nella separazione tra oggetti TPM. Come documenta Igor'sLAB, la condizione di use-after-free può causare la permanenza di informazioni da un oggetto TPM precedentemente utilizzato, compromettendo la funzione TPM2_Certify. Il risultato operativo è la possibilità di ottenere credenziali per chiavi TPM falsificate, vanificando il meccanismo attraverso cui un sistema prova la protezione crittografica delle proprie chiavi.

CVE-2026-6727 agisce su un vettore complementare. La decrittazione RSA-OAEP presenta tempi di elaborazione differenziati durante il controllo del padding, generando un canale laterale temporale. Questo consente un attacco Manger per decifrare blob crittografici e generare false Attestation Keys. TechTimes riporta che l'impatto enterprise è significativo in ambienti zero-trust: un attaccante con accesso interno potrebbe falsificare l'identità del dispositivo e bypassare i controlli di conformità.

Entrambi gli attacchi sono locali e richiedono privilegi elevati. Secondo Igor'sLAB, "there can therefore be no talk of a vulnerability that can simply be exploited from the Internet against arbitrary Ryzen PCs". Il perimetro di rischio si contrae quindi a scenari insider threat o post-compromissione, non a exposure di massa.

La timeline invertita: patch prima della disclosure

Il dato più rilevante dal punto di vista operativo è la cronologia. VideoCardz ha ricostruito le date di rilascio dei firmware AGESA corretti agli OEM: ComboAM4PI 1.0.0.11 per Ryzen 3000 il 18 maggio 2026; ComboAM4v2PI 1.2.0.12 per Ryzen 4000/5000 il 27 maggio; ComboAM5PI 1.3.0.1b per AM5 il 21 maggio, con versione alternativa 1.2.0.3k il 31 maggio.

ASUS ha distribuito il firmware per PRIME X870-P WIFI già a giugno, con patch aggiuntiva a luglio. MSI ha aggiornato schede B650 e X670E a luglio. ASRock ha coperto B650, B850 e A620 nello stesso periodo. GIGABYTE ha rilasciato a giugno. La disclosure pubblica dell'11 agosto ha quindi trovato un ecosistema già in parte immunizzato, seppur con gap di copertura su modelli meno recenti.

TechTimes segnala che alcune schede madri AM4 più datate, incluse certificazioni B550, non ricevono aggiornamenti da gennaio 2026 secondo segnalazioni community. Per Ryzen AI con Microsoft Pluton, l'aggiornamento è previsto per agosto 2026 senza data esplicita nel brief. La frammentazione dell'ecosistema OEM/BIOS resta il fattore di attrito principale.

Cosa fare adesso

Verificare la versione BIOS/AGESA del proprio sistema e confrontarla con le versioni corrette elencate nel bulletin AMD-SB-7064.
Chi utilizza BitLocker deve salvare la recovery key prima dell'aggiornamento firmware per evitare lockout del sistema.
Privilegiare il download del BIOS aggiornato direttamente dal sito del produttore della scheda madre (ASUS, MSI, GIGABYTE, ASRock) piuttosto che da canali intermedi.
Per sistemi Ryzen AI con Microsoft Pluton, monitorare le release note OEM per la disponibilità del firmware corretto nel corso di agosto 2026.

La lezione del codice condiviso: sicurezza oltre la competizione

L'episodio rivela una tensione strutturale della supply chain firmware. Il TPM 2.0 è diventato infrastructurale: Windows 11, BitLocker, Secure Boot e l'attestazione zero-trust enterprise ne dipendono. Quando il codice di riferimento condiviso presenta flaw, la competizione tra vendor si dissolve in responsabilità distribuita. AMD è apparsa più rapida e trasparente nella disclosure rispetto ad altri attori elencati nell'advisory CERT/CC, ma la velocità relativa non elimina il problema sistemico.

Il dossier non documenta exploit in-the-wild né impatti quantificati su infrastrutture enterprise già compromesse. La criticità CVSS 4.0 è elevata, ma i prerequisiti di accesso locale privilegiato ne ridimensionano l'urgenza per utenti domestici rispetto a ambienti corporate gestiti. La vera posta in gioco è la fiducia nell'attestazione hardware: se un dispositivo può mentire sulla propria identità crittografica, l'intero stack di sicurezza sopra di esso diventa opinabile.

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

Fonti

Fonti e riferimenti