Intel Researchers Found Two Flaws in AMD TPM Firmware — The…

AMD confirmed two TPM 2.0 vulnerabilities across its processor lineup on August 11, 2026 via security bulletin AMD-SB-7064. The flaws, discovered by Intel security researchers, affect Ryzen 3000-9000, Ryzen AI, Threadripper, EPYC, and Embedded processors. Unusually, firmware fixes had already been shipped to OEMs in May–June 2026, weeks before public disclosure, reversing the typical firmware security timeline.

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

AMD confirmed two vulnerabilities in the TPM 2.0 implementation of its processors on August 11, 2026 through security bulletin AMD-SB-7064. The two flaws, discovered by Intel security researchers, affect the entire Ryzen 3000-9000, Ryzen AI, Threadripper, EPYC, and Embedded range. Paradoxically, firmware updates had already been distributed to OEMs between May and June 2026: public disclosure arrived weeks after actual mitigation, inverting the usual firmware security cadence.

Key Takeaways

The vulnerabilities CVE-2026-6726 and CVE-2026-6727 originate in the Trusted Computing Group's TPM 2.0 reference code, not in AMD proprietary code.
CVE-2026-6726 is a use-after-free in TPM2_Certify with CVSS 4.0 8.5; CVE-2026-6727 is an RSA-OAEP timing side-channel with CVSS 4.0 8.3.
Both require local access with elevated privileges and allow forging the hardware attestation chain.
ASUS, MSI, GIGABYTE, and ASRock have already released updated BIOSes with the fixed firmware between May and July 2026.

The Trust Chain Paradox: When Intel Finds AMD's Flaws

The two vulnerabilities were identified by Liran Perez, Zecharye Galitzky, Shai Sarfati, and Yanai Moyal, researchers on Intel's security team. This detail is not anecdotal: TPM 2.0 is a shared ecosystem component where the Trusted Computing Group's reference code serves as the common base for different vendors' firmware implementations. AMD explicitly classified the two CVEs as "non-AMD," underscoring that the problem's roots lie upstream.

CERT/CC issued vulnerability note VU#431093 on August 11, 2026, confirming the cross-vendor scope of the issue. In the advisory's vendor status table, Intel fTPM is also listed as "Affected." The table shows, however, many vendors — Qualcomm, NVIDIA, Amazon, Dell, HP, Lenovo, VMware — in "Unknown" status, indicating that coordinated disclosure did not achieve uniform coverage.

"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

How the Attacks Work: Forging Device Identity

CVE-2026-6726 exploits an error in the separation between TPM objects. As documented by Igor'sLAB, the use-after-free condition can cause information from a previously used TPM object to persist, compromising the TPM2_Certify function. The operational result is the ability to obtain credentials for forged TPM keys, nullifying the mechanism by which a system proves cryptographic protection of its own keys.

CVE-2026-6727 operates on a complementary vector. RSA-OAEP decryption exhibits differentiated processing times during padding checks, generating a timing side-channel. This enables a Manger attack to decrypt cryptographic blobs and generate false Attestation Keys. TechTimes reports that enterprise impact is significant in zero-trust environments: an attacker with internal access could forge device identity and bypass compliance checks.

Both attacks are local and require elevated privileges. According to Igor'sLAB, "there can therefore be no talk of a vulnerability that can simply be exploited from the Internet against arbitrary Ryzen PCs." The risk perimeter therefore contracts to insider threat or post-compromise scenarios, not mass exposure.

The Inverted Timeline: Patches Before Disclosure

The most operationally relevant datum is the chronology. VideoCardz reconstructed the release dates of corrected AGESA firmware to OEMs: ComboAM4PI 1.0.0.11 for Ryzen 3000 on May 18, 2026; ComboAM4v2PI 1.2.0.12 for Ryzen 4000/5000 on May 27; ComboAM5PI 1.3.0.1b for AM5 on May 21, with alternative version 1.2.0.3k on May 31.

ASUS shipped firmware for PRIME X870-P WIFI as early as June, with an additional patch in July. MSI updated B650 and X670E boards in July. ASRock covered B650, B850, and A620 in the same period. GIGABYTE released in June. The August 11 public disclosure therefore found an ecosystem already partially immunized, albeit with coverage gaps on older models.

TechTimes notes that some older AM4 motherboards, including certified B550 models, have not received updates since January 2026 according to community reports. For Ryzen AI with Microsoft Pluton, the update is slated for August 2026 without an explicit date in the brief. OEM/BIOS ecosystem fragmentation remains the primary friction factor.

What to Do Now

Verify your system's BIOS/AGESA version and compare it against the corrected versions listed in bulletin AMD-SB-7064.
BitLocker users must save the recovery key before the firmware update to avoid system lockout.
Prefer downloading the updated BIOS directly from the motherboard manufacturer's site (ASUS, MSI, GIGABYTE, ASRock) rather than intermediate channels.
For Ryzen AI systems with Microsoft Pluton, monitor OEM release notes for availability of the corrected firmware through August 2026.

The Shared Code Lesson: Security Beyond Competition

The episode reveals a structural tension in the firmware supply chain. TPM 2.0 has become infrastructural: Windows 11, BitLocker, Secure Boot, and enterprise zero-trust attestation depend on it. When shared reference code has flaws, vendor competition dissolves into distributed responsibility. AMD appeared faster and more transparent in disclosure than other actors listed in the CERT/CC advisory, but relative speed does not eliminate the systemic problem.

The dossier documents no in-the-wild exploits nor quantified impacts on already-compromised enterprise infrastructure. CVSS 4.0 severity is high, but the local privileged-access prerequisites reduce urgency for home users relative to managed corporate environments. The real stake is trust in hardware attestation: if a device can lie about its cryptographic identity, the entire security stack above it becomes questionable.

Information verified against cited sources and current as of publication.

Sources

Sources and references

Get DeafLetter