Key takeaways
- UEFI Secure Boot anchors its entire chain of trust in a single asymmetric key pair called the Platform Key (PK).
- NVD's own description of CVE-2024-8105 states the vulnerability directly: "A vulnerability exists in UEFI implementations that use a hard-coded software-based Platform Key (PK).
- The three independent BIOS/UEFI vendors — AMI itself, Insyde, and Phoenix — are each listed as not affected, meaning none of them ships the leaked AMI test key as a production default in their own reference firmware.
- Not through a cryptographic break — RSA and AES were never the weak point here.
PKfail is Binarly REsearch's name for a 2024 discovery that hundreds of UEFI device models ship with their Secure Boot root of trust — the Platform Key — set to a key explicitly marked "DO NOT TRUST" in its own certificate fields, because the private half of that exact key had already leaked publicly years earlier. Tracked as CVE-2024-8105 and coordinated by CERT/CC as VU#455367, the flaw lets anyone holding that leaked private key sign arbitrary UEFI firmware or bootloader code and have it trusted as legitimate by every affected device — a complete, practical Secure Boot bypass that requires no cryptographic breakthrough, only possession of a key that device vendors should never have shipped in the first place.
This guide draws on CERT/CC's own VU#455367 vulnerability note, NVD's CVE-2024-8105 record, Binarly REsearch's original BRLY-2024-005 advisory, Red Hat's CVE-2024-8105 security page, and CERT/CC's CERTCC/PKfail remediation tool repository — each fetched directly for this guide on 6 November 2026.
What is a Platform Key, and what does "PKfail" actually mean?
UEFI Secure Boot anchors its entire chain of trust in a single asymmetric key pair called the Platform Key (PK). CERT/CC's VU#455367 describes the mechanism in its own words: "The platform owner enrolls the public half of the key (PKpub) into the platform firmware. The platform owner can later use the private half of the key (PKpriv) to change platform ownership or to enroll a Key Exchange Key." In other words, whoever holds the PK's private half effectively controls the device's entire trust database — the Key Exchange Key (KEK) list, the signature database (db) of what firmware is allowed to run, and the forbidden-signature database (dbx) of what is explicitly banned.
PKfail is what Binarly REsearch's team called its finding that hundreds of shipping device models use, as that single root of trust, a Platform Key generated by UEFI firmware vendor American Megatrends International (AMI) purely as a development/test artifact. Binarly's own advisory notes these test keys carry certificate subject or issuer fields containing strings like "DO NOT TRUST" or "DO NOT SHIP" — AMI's own built-in warning label — and were, in Binarly's words, "likely supplied as reference example to device vendors," never intended to reach a customer's hands. They reached customers' hands anyway, in firmware images Binarly found spanning release dates from 2011 through 2024.
What does CVE-2024-8105 actually let an attacker do?
NVD's own description of CVE-2024-8105 states the vulnerability directly: "A vulnerability exists in UEFI implementations that use a hard-coded software-based Platform Key (PK). An attacker in possession of the corresponding PK private key can sign arbitrary UEFI executables or firmware components, causing them to be trusted by affected systems and potentially bypassing UEFI Secure Boot trust validation." Binarly's BRLY-2024-005 advisory rates this CVSS 8.2 High (vector AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) and lays out the attack chain step by step: generate new KEK and db certificates, use the leaked PK private key to enroll those certificates into the device's trust database, then sign arbitrary EFI binaries with the newly trusted db key. Red Hat's own advisory classifies the underlying weakness as CWE-1394, Use of Default Cryptographic Key — precisely what happened: a key meant as a disposable development placeholder became the permanent, unchangeable root of trust on a production device.
The one precondition for exploitation is that the specific private key has to be exposed, and it was — Binarly traced the key its research centered on to a motherboard-vendor data breach, after which it circulated publicly, available to anyone who wanted it. CERT/CC frames the resulting capability without hedging: an attacker can "sign malicious UEFI software, enabling the execution of code with the highest privileges during the early boot phases of a UEFI Secure Boot-protected system" — a foothold earlier and more privileged than almost anything an operating system's own defenses can see or remove.
Which vendors are confirmed affected, and which are not?
CERT/CC's VU#455367 publishes a per-vendor status table, current as of its 14 January 2025 revision:
| Status | Vendors |
|---|---|
| Affected | Fujitsu Europe, Intel, Supermicro |
| Not affected | American Megatrends (AMI), Insyde Software, Phoenix Technologies |
| Unknown | GIGABYTE, Acer, Aopen, Dell, Formelife, Fujitsu HQ, HP Enterprise, HP Inc., Lenovo |
The three independent BIOS/UEFI vendors — AMI itself, Insyde, and Phoenix — are each listed as not affected, meaning none of them ships the leaked AMI test key as a production default in their own reference firmware. The nine vendors listed "Unknown" is the detail worth sitting with: CERT/CC's own documentation makes clear that status means the vendor had not returned a determination by the note's last revision, not that the vendor was cleared. An "Unknown" entry still sitting five months after the 25 July 2024 public disclosure date is itself evidence of how hard this class of supply-chain issue is to fully close out — it depends on every device maker individually confirming which exact Platform Key shipped in which exact firmware build, across years of product lines.
How did a test key end up in production firmware in the first place?
Not through a cryptographic break — RSA and AES were never the weak point here. It happened through an ordinary, repeatable supply-chain gap: AMI generates a Platform Key as a reference example for firmware bring-up and testing, explicitly marks its certificate "DO NOT TRUST" or "DO NOT SHIP" so nobody mistakes it for a production credential, and hands it to device vendors building firmware on top of AMI's reference code. Somewhere between that reference firmware and a shipping product, the step that should have generated a unique, secret production Platform Key for each vendor — or at minimum, each product line — simply did not happen, on hundreds of device models, across more than a decade of release dates. The explicit warning label in the key's own certificate fields is what makes this particular failure so stark: the firmware itself was carrying a visible, machine-readable flag saying "do not ship this," and it shipped anyway.
Is there a patch, and what should a device owner do right now?
Red Hat's advisory states the fix in one line: "The fix for PKfail is straightforward: the compromised key needs to be replaced and device vendors need to ship a firmware update." That fix can only come from the vendor — no end-user setting replaces a hard-coded Platform Key, since the PK's entire function depends on being something the operating system cannot casually rewrite. For devices awaiting that update, CERT/CC's own CERTCC/PKfail GitHub repository provides an interim Windows-specific tool, a PowerShell script (Updateamipk.ps1) that replaces an AMI test Platform Key with Microsoft's Windows OEM Devices PK, explicitly described as a bridge "until firmware patches become available," not a permanent substitute for the vendor's own signed update.
A workable sequence for any fleet of UEFI devices:
Check the actual Platform Key on each device model, not just the vendor's name — Binarly's detection guidance looks for "DO NOT TRUST"/"DO NOT SHIP" strings in the PK certificate's subject or issuer fields, and an "Unknown" status in CERT/CC's vendor table is not evidence of safety. Apply the vendor's firmware update as soon as one shipsfor any confirmed-affected model — this is the only change that actually replaces the compromised key. Use the CERTCC/PKfail interim tool only as a bridge on Windows systems that cannot wait, understanding it switches to a Microsoft-controlled key, not the vendor's own eventual production key. Treat "Secure Boot: Enabled" in a BIOS menu as a process claim, not a security guarantee, until the underlying Platform Key has actually been confirmed trustworthy — PKfail is a direct, real-world instance of the gap between secure boot and hardware root of trust in theory and what a specific shipping device actually enforces. Build Platform Key provenance into any firmware intake or procurement review, the way NIST SP 800-193's roots of trust for update and detection assume a verification chain actually exists before resilience features can matter at all.
Is PKfail a one-off, or does it point to a bigger pattern?
It points to a pattern, and that is the part worth carrying past this single CVE. CERT/CC's nine "Unknown" vendor entries, still open months after public disclosure, are not a cryptographic problem — they are an organizational one: nobody in a multi-tier firmware supply chain (silicon vendor, BIOS vendor, ODM, brand owner) owned the specific step of confirming the Platform Key before signing off on a shipping build. NIST SP 800-147's BIOS Protection Guidelines and the EU Cyber Resilience Act's integrity-protection expectations, covered in CRA Annex I, explained, both assume exactly this kind of gap is the realistic failure mode — not a broken algorithm, but a trust anchor nobody verified end to end. OWASP's firmware security testing methodology is the practical answer: testing a device's actual Secure Boot configuration, including the specific Platform Key it ships with, rather than trusting a vendor's "Secure Boot enabled" checkbox at face value.
SoftWSP's Device & Firmware Security service reviews boot chains, key provenance and signing practices against a device's actual shipped firmware, not a vendor's marketing claim about it: see Device & Firmware Security.
This guide summarizes CERT/CC's VU#455367 vulnerability note, NVD's CVE-2024-8105 record, Binarly REsearch's BRLY-2024-005 advisory, Red Hat's CVE-2024-8105 security page, and CERT/CC's CERTCC/PKfail tool repository, each fetched directly for this guide on 6 November 2026. It is not a substitute for a vendor's current firmware advisory for a specific device model, or for an engineer's direct inspection of that device's shipped Platform Key.
Sources
- CERT/CC: VU#455367 — Insecure Platform Key (PK) used in UEFI system firmware signature
- NVD: CVE-2024-8105 — hard-coded software-based UEFI Platform Key allows Secure Boot bypass
- Binarly REsearch: BRLY-2024-005 — "Usage of default test keys leads to complete Secure Boot bypass" (original PKfail advisory, CVSS 8.2)
- Binarly: "PKfail: Untrusted Platform Keys Undermine Secure Boot on UEFI Ecosystem" (original disclosure announcement)
- Red Hat: CVE-2024-8105 security advisory (CVSS 8.2, CWE-1394 Use of Default Cryptographic Key)
- CERT/CC: CERTCC/PKfail GitHub repository — interim Windows Platform Key replacement tool
Frequently asked questions
What is a Platform Key, and what does "PKfail" actually mean?
The Platform Key (PK) is the single root of trust for UEFI Secure Boot on a given device. CERT/CC's vulnerability note VU#455367 describes the mechanism plainly: "The platform owner enrolls the public half of the key (PKpub) into the platform firmware. The platform owner can later use the private half of the key (PKpriv) to change platform ownership or to enroll a Key Exchange Key." PKfail is the name Binarly REsearch gave to the discovery that hundreds of shipping device models use, as that single root of trust, a Platform Key that was never meant to leave a test lab — a cryptographic key explicitly marked "DO NOT TRUST" or "DO NOT SHIP" in its own certificate fields, generated by firmware vendor American Megatrends International (AMI) purely for development, that device makers left in place in production firmware instead of replacing it with their own unique key.
What does CVE-2024-8105 / VU#455367 actually let an attacker do?
NVD's own description of CVE-2024-8105 states it directly: "A vulnerability exists in UEFI implementations that use a hard-coded software-based Platform Key (PK). An attacker in possession of the corresponding PK private key can sign arbitrary UEFI executables or firmware components, causing them to be trusted by affected systems and potentially bypassing UEFI Secure Boot trust validation." Binarly's own advisory, BRLY-2024-005, rates the issue CVSS 8.2 High (vector AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) and lays out the exact attack chain: an attacker who holds the leaked AMI test PK private key can generate new Key Exchange Key (KEK) and signature-database (db) certificates, use the leaked PK to enroll those certificates as trusted, then sign arbitrary EFI binaries with the new db key — code that the device's own Secure Boot will execute during the earliest, highest-privilege phase of boot, fully believing it is legitimate. CERT/CC describes the practical consequence the same way: an attacker can "sign malicious UEFI software, enabling the execution of code with the highest privileges during the early boot phases of a UEFI Secure Boot-protected system." The one precondition is that the key itself has to be exposed — and it was: the specific private key Binarly tracked had leaked years earlier in a motherboard-vendor data breach and had been circulating publicly since.
Which vendors were confirmed affected, and which were not?
CERT/CC's VU#455367 publishes a per-vendor status table, current as of its 14 January 2025 revision. Confirmed **Affected**: Fujitsu Europe, Intel, and Supermicro. Confirmed **Not Affected**: American Megatrends (AMI) itself, Insyde Software, and Phoenix Technologies — the three major independent BIOS/UEFI vendors, none of which ship the leaked AMI key as a production default. Status listed as **Unknown** (meaning CERT/CC had not received a determination from that vendor at the time of its last revision): GIGABYTE, Acer, Aopen, Dell, Formelife, Fujitsu HQ, HP Enterprise, HP Inc., and Lenovo. An "Unknown" status is not a clean bill of health — it means the vendor had not told CERT/CC one way or the other — which is exactly why CERT/CC's own guidance is to check a specific device's firmware directly rather than infer safety from the vendor's name alone.
How is PKfail actually fixed, and can an end user do anything before a firmware update ships?
Red Hat's advisory for CVE-2024-8105 states the fix in one sentence: "The fix for PKfail is straightforward: the compromised key needs to be replaced and device vendors need to ship a firmware update." That is a vendor-side fix — no end-user action replaces a hard-coded Platform Key, because the PK's entire purpose is that only a firmware update, not a registry setting or OS-level control, can change it. CERT/CC's coordinated response includes an interim workaround for Windows devices: the CERTCC/PKfail GitHub repository publishes a PowerShell script (`Updateamipk.ps1`) that replaces an AMI test Platform Key with Microsoft's own Windows OEM Devices PK on an affected device, explicitly described as a temporary measure "until firmware patches become available," not a substitute for the vendor's own update. The practical sequence for an asset owner is: confirm whether a specific device's PK certificate carries a "DO NOT TRUST"/"DO NOT SHIP" marker (Binarly's detection guidance), apply the vendor's firmware update once one ships, and use the interim Microsoft/CERT-CC tool only as a bridge on Windows systems that cannot wait.
Is PKfail a one-off incident, or does it point to a bigger pattern?
It points to a bigger pattern, and that is the detail worth taking away beyond the single CVE. PKfail did not originate from a cryptographic break — AES and RSA were never the weak point. It originated from a supply-chain and process failure: a key explicitly labeled as untrustworthy, moving from a reference design through multiple tiers of firmware vendors and device makers, without any one of them substituting a real production key before the device shipped. CERT/CC's own finding that nine vendors remained "Unknown" months after public disclosure — not confirmed fixed, not confirmed safe, simply unresponsive — underscores that the gap was organizational as much as technical: nobody in the supply chain owned the step of confirming the Platform Key before signing off on a shipping build. That is precisely the class of failure NIST SP 800-193's roots of trust for update and detection, and a disciplined secure boot chain-of-trust review, are built to catch before a device reaches a customer rather than years into its field life.
In this cluster
Questions about this page?