The chip that guards your keys is broken: I audited all four machines in my swarm

The TPM exists for one thing: keeping keys where the operating system cannot read them. If you encrypt the disk and seal the key to the TPM, the machine boots on its own and a stolen disk is a brick. That whole promise depends on the chip holding up its end.

This week two CVEs appeared saying it does not. I saw them the same day in German, on heise, and in Russian, on OpenNet. In Spanish I found nothing, and that gap is why the original of this text exists.

So instead of translating the announcement, I went to check my own machines.

What broke

Both flaws are in the Trusted Computing Group’s TPM 2.0 reference code, not in AMD or Intel. They were found by four Intel researchers: Liran Perez, Zecharye Galitzky, Shai Sarfati and Yanai Moyal. Since almost every fTPM implementation derives from that code, the problem spreads by itself.

CVE-2026-6726 (CVSS 8.5) is a type confusion: the firmware does not separate objects properly and a region of memory that was already used stays accessible when it gets reused for something else. Data from a previous key survives where it should not.

CVE-2026-6727 (CVSS 8.3) is a timing side channel in RSA OAEP decryption. A program sends an enormous number of commands to the coprocessor and measures how long it takes to answer; from those differences it deduces the secret.

AMD published its bulletin on 11 August and marked both as “non-AMD”, because the origin is the TCG’s code. The list of affected parts is enormous anyway: from Ryzen 3000 to Ryzen 9000, Ryzen AI 300 and 400, Threadripper, the Z1 and Z2, several Embedded families. Intel’s fTPM also appears as affected in the CERT advisory.

Both require local access with privileges. That takes the panic down a good deal and raises the interesting question: if someone already has root on your machine, what was still protected? Exactly what the TPM was holding.

The audit

Four machines, four different answers. The command that separates the wheat from the chaff is this one:

sudo tpm2_getcap properties-fixed | grep -A3 TPM2_PT_MANUFACTURER

If the manufacturer is AMD or INTC, the TPM is firmware and runs inside the processor. If it says IFX, STM or NTC, it is a discrete chip and this story does not apply to you.

The Mac: immune by not having one

A MacBook Pro with an i7-9750H, a processor squarely in the affected range. But macOS does not use a TPM: it uses the T2 chip and its Secure Enclave, a different implementation that does not derive from the TCG’s code. There is no /dev/tpm0 to audit.

The one machine that escapes is the one that never had the broken part.

The VPS: the advantage of having no hardware

CPU: AMD EPYC 9355P 32-Core
hypervisor: kvm
no /dev/tpm* (VM with no TPM exposed)

An EPYC 9355P, a processor on the affected list. But it is a virtual machine and the hypervisor exposes no TPM to the guest. If it needed one, it would be an emulated swtpm, another stack of code with other problems. Nothing to patch here either.

fedora: affected, with a way out

This one stings, because it is the GPU node where half my work runs.

CPU:             AMD Ryzen 7 7800X3D
board:           ASUS PRIME B650M-A II
TPM manufacturer: AMD                 ← firmware TPM
fTPM version:    6.31.0.6
BIOS:            2613 (12/04/2024)
AGESA:           FireRangePI 1.1.7.0

A Ryzen 7000, right in range. AMD fTPM, not a discrete chip. And a BIOS from April 2024.

AMD delivered the corrected firmware to board vendors between May and June 2026, and for AM5 the fix lands with AGESA ComboAM5 PI 1.2.0.3k or above. ASUS already published BIOS 3886 for this board on 2 July 2026, with AGESA 1.3.0.1b, well above the minimum.

Which means: the patch has existed for six weeks and my machine is still on BIOS 2613 while the fixed one is 3886.

vworker: affected, no way out

CPU:             Intel Core i5-9400F
board:           ASUS PRIME H310M-E R2.0
TPM manufacturer: INTC / "Intel"      ← Platform Trust Technology
fTPM version:    302.12
BIOS:            1006 (13/08/2019)

Coffee Lake, ninth generation, inside Intel’s range. Platform Trust Technology active, which is Intel’s fTPM under another name. A BIOS from 2019.

I went looking for the update and found the end of the road: the last BIOS ASUS published for this board is 2209, from June 2022. Four years without a single new version. The H310 chipset came out in 2018 and is out of support.

An fTPM fix travels only inside a BIOS. If the board vendor stopped publishing BIOSes, the vulnerability stays there forever. There is no command, package or trick that removes it.

That machine cannot be fixed. Full stop.

The detail that nearly fooled me

Before going to the ASUS site I did what anyone on Linux would: ask fwupd, which is the standard tool for updating firmware.

$ sudo fwupdmgr get-updates
Devices with no available firmware updates:
 • KINGSTON SNV2S1000G
 • System Firmware
 • UEFI dbx
No updatable devices

fwupd sees the TPM. It lists it with its version, its manufacturer and even its GUIDs. And it still says there is nothing to update, while the board vendor has had the corrected BIOS on its site for a month.

The explanation is not a bug: fwupd only knows what is published on LVFS, and a good share of desktop board vendors do not publish there. The tool is not lying, but its silence reads exactly like “you are up to date”.

If you administer Linux machines and use fwupd as your signal that firmware is healthy, this is the most practical lesson in the article. It reporting no updates does not mean none exist.

I tried to measure the side channel, and did not detect it

This is where this blog parts ways with a translated news item. There is no public proof of concept, so reproducing the full attack is out of reach. What can be measured is its precondition: that the TPM’s response time depends on the data it processes.

I set up a simple harness. I create an RSA-2048 key inside the TPM, encrypt two different messages (one of all zeros, one random) and time sixty decryptions of each.

AMD fTPM 6.31.0.6, on the Ryzen 7800X3D:

1. RSA decryption, all-zero message325.74 msThe case an attacker would pick first, being the most degenerate.
2. RSA decryption, random message325.65 msIndistinguishable from the previous one. A timing side channel needs a difference that does not exist here.
3. getrandom of 32 bytes9.10 msFor reference: the cheap operation on the same chip, thirty-six times faster.

AMD fTPM. The two medians are 0.09 ms apart, four times less than the measurement's own 0.37 ms deviation: nothing leaks through here.

Intel PTT 302.12, on the i5-9400F:

The median difference between the two messages was 0.090 ms on AMD and 0.048 ms on Intel. In both cases it sits well below the measurement’s own deviation.

I did not detect the side channel. And that does not disprove the CVE: it says my instrument is too coarse. I am measuring from Python, launching a process per operation, with the system scheduler on top; my harness’s noise is in milliseconds and the real attack lives at the scale of CPU cycles, with messages chosen deliberately to trigger the branch, not random ones.

I am publishing the failed attempt because a negative result informs too: the precondition is not visible from user space with ordinary tools. Nobody is going to notice this attack by watching latencies.

What the measurement did produce was a side fact that surprised me. A single RSA-2048 decryption takes 326 ms on AMD’s fTPM and 374 ms on Intel’s PTT. That is fewer than three operations per second. A TPM is a slow guardian by design, and that slowness alone explains why an attack that needs “countless commands” is tedious, and why nobody thinks of putting a TPM in the path of anything with volume.

It also became clear that Intel’s PTT is considerably less consistent: its deviation on getrandom is 2.06 ms against AMD’s 0.15 ms, nearly fourteen times more spread.

My take

The headline is scarier than it deserves. Both flaws require local access with elevated privileges, and by then the attacker already has your machine. What these CVEs add is that the keys stored in the TPM, which were precisely the last thing supposed to be safe, stop being so.

What genuinely bothers me is the distribution chain. The bug lives in the TCG’s code, AMD and Intel inherit it, each delivers corrected firmware to board vendors, and each vendor decides whether to publish a BIOS. When the model is eight years old, the answer is no. The vulnerability does not get closed: it gets abandoned.

And it irritates me that Linux’s official tool for this told me everything was fine.

What I would do about it

• Find out whether your TPM is firmware or a chip. One command, thirty seconds. If it is discrete, stop reading with a clear conscience.
• Do not trust fwupdmgr as your only source. Go to your board vendor’s site and compare the BIOS version by hand.
• If you seal LUKS or BitLocker keys to the TPM, update the BIOS. That is the one scenario where these flaws change something concrete for you.
• If your board no longer gets BIOSes, do not seal anything to the TPM. A passphrase you type at boot is today more trustworthy than an fTPM nobody will ever touch again.

In my case: fedora is getting BIOS 3886. And on vworker the TPM stays as it is, because there is no other option, so I simply trust it with nothing.

---

Sources: heise online (German), OpenNet (Russian), AMD bulletin SB-7064, CERT/CC VU#431093.