Binarly: UEFI Secure Boot is completely compromised on 200+ device models sold by Acer, Dell, Gigabyte, Intel, and Supermicro due to a cryptographic key leak
hundreds of devices from Dell, Supermicro and more all affected, here's what we know Adam Conway / XDA Developers : PKFail puts hundreds of computers and laptops at risk and renders Secure Boot useless on them Jowi Morales / Tom's Hardware : Secure Boot key compromised in 2022 is still in use in over 200 models — an additional 300 more use keys are marked ‘DO NOT TRUST’ Steve / SC Media : UEFI malware delivery possible with PKfail issue Jonathan Bennett / Hackaday : This Week in Security: EvilVideo, Crowdstrike, and InSecure Boot Luke Jones / WinBuzzer : Researchers Find Malware-Threatening Secure Boot Bypass in Hundreds of Devices Eduard Kovacs / SecurityWeek : PKfail Vulnerability Allows Secure Boot Bypass On Hundreds Of Computer Models Tom Warren / The Verge : Secure Boot is completely broken on many PCs. Binarly on Github : Detected Products vulnerable to PKfail Mastodon: Kee Hinckley / @nazgul@infosec.exchange : “Hey, this BIOS key says “DO NOT TRUST. “Ship it!” — https://arstechnica.com/... @somebitslinks@tech.lgbt : Secure Boot fiasco: Another failure of this incredibly complicated and brittle system that turns out to provide no actual security — https://arstechnica.com/... #security #badtech #bios #uefi #- Misty / @misty@digipres.club : “Keys were labeled “DO NOT TRUST. ” Nearly 500 device models use them anyway.” — https://arstechnica.com/... Kenn White / @kennwhite@mastodon.social : Protip: When choosing a root-of-trust encryption key for a hardware secure enclave, maybe don't use the vendor's asymmetric key literally labeled “CN=DO NOT TRUST - Test PK”. New scoop by @dangoodin: Secure Boot is Completely Broken on 200+ Models from 5 Big Device Makers — https://arstechnica.com/... X: @e__soriano : “we noticed that the private key from American Megatrends International (AMI) related to the Secure Boot “master key”, called Platform Key (PK), was publicly exposed in a data leak (...) devices corresponding to this key are still deployed in the field” https://www.binarly.io/... Plum / @plumferno : It's that time again, folks! Here's Plum with another super-comforting bit of security industry news 🥰 *cries* https://arstechnica.com/... @vermaden : Secure Boot was introduced by Microsoft not to increase security of anything - but to make installing/using free and open operating systems harder - https://arstechnica.com/... - so I could not care less if its secure or not - first thing I do on my devices is to disable this shit. Nicolas Grégoire / @agarri_fr : What a joke! 🤡 https://arstechnica.com/... @binarly_io : 🚨New! “PKFail: Untrusted Platform Keys Undermine Secure Boot on UEFI Ecosystem.” #PKfail is a supply-chain issue affecting x86/ARM devices around the globe. Blog: https://www.binarly.io/... Full report: https://22222483.fs1.hubspotusercontent - na1.net/... A free scanning tool: https://pk.fail/ [video] Nikolaj Schlej / @nikolajschlej : Don't want to be a “well, actually” guy here, but the whole UEFI SecureBoot key hierarchy is supposed to be re-generated by the local admin, as trusting whomever (be it the HW vendor with their PK or MS with their KEK) other than yourself is way too dangerous even if convenient. Forums: r/hardware : Secure Boot is completely broken on 200+ models from 5 big device makers r/technology : Secure Boot is completely broken on 200+ models from 5 big device makers | Keys were labeled “DO NOT TRUST.” Nearly 500 device models use them anyway Lobsters : Secure Boot is completely broken on 200+ models from 5 big device makers Ars OpenForum : Secure Boot is completely broken on 200+ models from 5 big device makers
Context & Ripple Effects
This is another failure mode for a control meant to establish trust before an operating system loads. Related coverage had already shown that vulnerable boot components could remain usable when they were not added to a revocation list in the BlackLotus-related UEFI patch gap.
The incident also sits alongside earlier evidence that Secure Boot protections can fail through vendor configuration, including default settings on hundreds of MSI motherboards that accepted improperly signed software. PKFail shifts the focus to exposed signing material and the resulting trust chain across multiple device makers.
First-order effects
- Affected Acer, Dell, Gigabyte, Intel, and Supermicro device models can no longer rely on Secure Boot to block software signed through the leaked Platform Key path.
- Binarly’s free pk.fail scanner gives device owners and IT teams a way to identify exposed products, while vendors and firmware suppliers must assess and remediate affected firmware.
Second-order effects
- Organizations using affected systems may need to treat firmware integrity as an active verification task rather than assume the Secure Boot label is sufficient, adding pressure for vendor guidance and updates.
- The shared-key exposure concentrates remediation risk at the firmware-supplier layer: a single trust-material failure can create parallel support and update obligations for multiple OEMs.
Third-order effects
- If key exposure and incomplete remediation recur, boot-security assurance will increasingly depend on transparent key provenance, revocation practices, and fleet-level verification—not merely the presence of Secure Boot.
- The pattern strengthens the case that platform trust is a supply-chain property: weaknesses in firmware configuration, signing keys, or update handling can undermine protections across otherwise separate hardware brands.
The trend: PKFail is part of a broader shift from treating Secure Boot as a binary feature to scrutinizing the firmware supply chain, keys, and revocation processes that make it trustworthy.