AMD shipped the fix for these TPM flaws in May. On a Minisforum HM80 there is nowhere to put it
Two high-severity vulnerabilities, a mitigation dated 18 May, and a support page whose newest file is three years old.
A mini PC bought five years ago has two high-severity firmware flaws, a fix that exists, and nowhere to put it.
AMD handed its manufacturers the firmware that mitigates CVE-2026-6726 and a companion flaw on Ryzen 4000-series mobile chips on 18 May. On 9 September an owner of a Minisforum HM80 — a small desktop built on a Renoir-generation Ryzen part — said the company had declined to ship it and suggested buying a newer machine. That is nearly four months, and counting.
The complaint itself is one account. VideoCardz, which reported it, says plainly that the owner "did not provide emails that confirm it". So set the refusal aside as unproven and look at the parts that can be checked.
AMD's bulletin can be checked.
An information leakage vulnerability was reported in the TCG TPM 2.0 reference code that could allow a local attacker with elevated privileges to obtain a credential from a TPM-aware CA for a falsified TPM key (such as an Attestation Key, DevID Key or TLS authentication key) and falsify other TPM 2.0 attestations with this key.
AMD scores that one 8.5 and its companion, a timing side channel in RSA decryption, 8.3. Both are rated High. The listed mitigation is a firmware package called RenoirPI-FP6 1.0.0.Ee, and the bulletin's instruction to users is a single sentence: "Please contact your OEM for the BIOS update specific to your product(s)."
So we opened the page
Minisforum's support page for the HM50, HM60 and HM80 lists a user guide, two Windows images, a chipset driver bundle, a multimedia driver bundle, a driver package and a wireless driver. Seven files. No BIOS of any version, of any vintage. The newest thing on that page is three years old.
Which makes the refusal almost beside the point. Even a helpful support agent has nothing to send you.
The honest defence, and where it stops
Both flaws require a local attacker who already holds elevated privileges, so the practical risk to a home machine sitting behind a router is small. The hardware is five years old and long out of warranty. AMD's own bulletin says the vulnerability originates in the Trusted Computing Group's reference implementation rather than in AMD silicon. All of that is fair, and a reasonable person could stop reading here.
It is also beside the mechanism, which is the part worth understanding. A firmware TPM exists precisely to hold secrets against a privileged local attacker. That is the threat model it is sold for, not an edge case of it. A flaw that only matters to an attacker who is already inside is, for this component, the whole point.
AMD did its part. It wrote the mitigation and dated it. But AMD ships platform initialisation firmware only to manufacturers, and the manufacturer is the sole route to the machine. One company deciding a product is finished ends the security lifecycle of every unit it ever sold, and nobody has to file anything, notify anyone, or explain themselves.
Notice who else AMD fixed in the same bulletin. Athlon and Ryzen 3000-series mobile parts, built on the older Picasso design, got their own firmware three days earlier. The chip designer is still supporting silicon two years older than the box in the complaint.
Our expectation is that no HM80 BIOS appears on that page before the end of the year, and that the bulletin goes on listing mitigations for dozens of consumer parts whose owners will never see them. If Minisforum posts one, we will say so and link it.
Do you own something with a firmware TPM in it and a vendor that has gone quiet? Check the download page before you check the CVE. The gap between those two is your actual exposure.
