Two years after PKfail, most affected hardware is still booting on a compromised Secure Boot key

In July 2024, Binarly’s research team published PKfail. The short version: AMI (American Megatrends International), which supplies UEFI reference firmware to a large fraction of the PC industry, ships a default Platform Key for test and development use. The intent is that OEMs generate platform-specific keys and replace the AMI test key before shipping product. Multiple OEMs did not do this. Binarly found AMI’s test key material in firmware images sitting in public repositories. The private key for the test cert was recoverable from those images, which means it is publicly accessible to anyone who wants it.

Affected devices span Acer, Dell, Gigabyte, HP, Intel, Lenovo, and Supermicro, among others. Hundreds of device models. Some server hardware. Two years later, most of it has not been patched.

What the Platform Key is

Secure Boot’s trust model is a hierarchy. At the top sits the Platform Key (PK). The PK signs Key Exchange Keys (KEKs). KEKs sign updates to the Signature Database (db), which contains hashes and certificates for bootloaders that are permitted to run. Below that sit the distribution-supplied certs for shim and whatever bootloader your OS ships.

The PK is the root. If you control the PK’s private key, you control the whole chain. You can enroll whatever you want in the trust hierarchy. You can sign your own bootloader. Secure Boot will bless it. The TPM attestation that depends on Secure Boot measurements is also gone.

There is nothing above the PK in the UEFI Secure Boot spec. It is, by definition, where the trust starts and where the trust ends.

AMI’s test key is not a weakly-guarded production credential. Its purpose was specifically to be thrown away before hardware ships. The key having landed in public firmware images suggests nobody checked whether it was thrown away. On affected devices, Secure Boot enforces a trust root whose private half is sitting on GitHub.

The scope

Binarly’s disclosure was methodical. They scanned firmware images, identified the test keys by their certificate metadata, and cross-referenced against device model lists. The affected vendors include names you find in data centers, not just consumer gear. Supermicro is in the list. The CVEs assigned include CVE-2024-8105 and related identifiers covering different key variants from different IBVs.

This is not a case of one vendor shipping a bad build. The pattern repeated across multiple IBVs using the same AMI reference, each of which supplied firmware to multiple OEMs. The failure was systemic: nobody in the supply chain had a process that verified “did we actually replace the test key before we shipped this.”

The xz backdoor showed something similar at the social engineering layer: trust extended to a dependency without anyone checking what that dependency was actually doing. PKfail is the same mechanism one layer down. The OEM trusted AMI’s reference implementation. The OEM did not check what keys the reference implementation contained. The users trusted the OEM.

Why it is still unpatched

Firmware updates require the OEM to ship a BIOS update, the customer to apply it, and the update to actually rotate the PK rather than just the layers below it. Each step has failure modes.

On the enterprise side, firmware updates move slowly through change control. Test the update in staging. Validate no regressions. Schedule a maintenance window. Some organizations have taken two years and still are not done. Others will not patch until the devices cycle out. For server hardware, “device cycles out” can mean five to seven years.

On the consumer side, many of the affected models are already past their vendor’s active support window. No update is coming. The people who own that hardware do not know PKfail exists and would not know how to patch it if they did.

There is also a subtler problem with PK rotation itself. In the UEFI spec, updating the PK requires the update to be signed by the current PK, since the PK governs its own successor. If the current PK’s private key is compromised, this creates an awkward circular dependency. OEMs can use platform-specific out-of-band mechanisms to update the PK, but those mechanisms vary, some are undocumented, and some UEFI implementations do not implement them cleanly. A few vendors shipped BIOS updates that rotated the KEKs and db but left the compromised PK in place.

What Secure Boot’s threat model actually says

The spec’s threat model assumes the Platform Key’s private key stays under the OEM’s or owner’s exclusive control. Physical access cannot tamper with the boot sequence because the attacker cannot sign a malicious bootloader without that key.

On the affected hardware, the key’s private half is public. An attacker who wants to install a bootkit does not need physical access to flash the firmware directly. They can sign a malicious bootloader with the leaked key, enroll it via standard EFI variable writes (which do require some level of access, but far less than reflashing firmware), and Secure Boot will accept it without complaint.

For corporate compliance checklists, “Secure Boot enabled” still returns true. For actual boot integrity, it provides nothing on the affected systems. The gap between the checkbox and the reality is what PKfail made visible. It is not a subtle gap. The CVE scoring debate applies here: a vulnerability that requires “some access” reads lower on paper than one that requires zero preconditions, but “some access” on an enterprise workstation means a user-space process that calls EFI variable write APIs.

What you can do

mokutil --sb-state tells you Secure Boot is enabled. It does not tell you whether the PK is trustworthy. To inspect the enrolled keys you need efi-readvar (from efitools) or access to the EFI variable store directly. Binarly also published a scanner as part of the PKfail disclosure.

If your hardware is in the affected set and a BIOS update exists that specifically addresses the PK rotation, apply it and verify the PK changed. Not just the BIOS version, the key. efi-readvar before and after.

If your hardware is end-of-life with no update available, the honest assessment is: Secure Boot on that machine is theater. You can disable it and lose nothing real, or leave it enabled and understand what you are and are not getting. Enabling TPM-based attestation on top of a compromised PK gives you measurements of a boot sequence that an attacker can control. That is worse than having no attestation because it creates false confidence.

The problem with security features that depend on a supply chain doing its job is that supply chains are not always doing their job. Nobody announced they were shipping AMI’s test key. Nobody announced they were not going to replace it. It shipped. It is still shipped, on most of those devices, two years on.

See also: the NVD and OSV feed changes and how vulnerability metadata quality shapes whether disclosures like this get the triage weight they deserve.