.webp)
By Fabio Pagani (Binarly REsearch)
Over the past few years, the Binarly REsearch team has led the way in documenting security problems haunting the entire UEFI ecosystem. We presented our discoveries at major security conferences like OffensiveCon, Black Hat, LABScon and RE//verse to share data and collaborate with the industry to secure the UEFI ecosystem.
It therefore comes as no surprise that when something unusual emerges in this space, Binarly is contacted to provide technical expertise.
This story starts at the end of February 2025, when Thierry Laurion opened an issue in our SupplyChainAttacks repository, where we keep records of devices impacted by supply chain failures, such as the Intel Boot Guard keys that leaked during the MSI data breach or Intel and Lenovo source code breach.
This issue pointed to a second post hosted in the Win-Raid forum, where a user reportedly found Boot Guard Key Manifest and Boot Policy Manifest Private keys in the firmware update packages of Clevo devices.
In this blog, we document our investigation that began with this initial report and present findings with a focus on the implications of this private keys leakage.
After downloading the Clevo BIOS archive found on Win-Raid, we quickly discover two private keys embedded in the BootGuardKey.exe binary (note: a copy of these keys is also stored in the standalone files CreateDeleteBIOSKey.keyprivkey.pem and CreateDeleteBIOSKey.privkey.pem).
After extracting the private key modulus from these keys (see Figure 2), we confirmed that they match the modules stored in the Boot Guard Key Manifest (KM) and Boot Policy Manifest (BPM) used in a Clevo firmware image found within the archive. This means that these keys can be used to sign a malicious firmware image that will pass validation at runtime, effectively bypassing Boot Guard—bingo!
Similar attacks have been demonstrated multiple times in the past: for example, the HardenedLinux team showed how a Boot Guard key leaked during the MSI data breach can be exploited to bypass Boot Guard on a MSI device.
Given our unique insight into the UEFI firmware ecosystem, we integrated the leaked Clevo keys into our Binarly Transparency Platform to conduct an ecosystem-wide scan and identify where these keys are actually deployed. To our surprise, we discovered 15 firmware images containing these keys, corresponding to 10 unique devices.
Notably, all of these firmware images belong to recently released devices, including one for the Gigabyte G6X 9KG that was released in 2025.
An important note: the previous table includes only firmware from vendors present in our dataset. Clevo-based devices may also be used by other vendors, and we believe some other gaming-focused vendors may also be affected by this leak.
Fortunately, Clevo's mistake was not repeated by other vendors in our dataset. A scan of our internal firmware update package dataset–which counts more than 200,000 packages from all major vendors–did not reveal any Boot Guard keys leaked in a similar manner.
On February 28, 2025 we shared the BRLY-2025-002 advisory to CERT/CC to report our findings, but the case was closed a few days later without much explanation.
In this blog post, we highlighted the risks and impact of Boot Guard private key leaks. Since these keys are shared across multiple devices and vendors, each leak can have far-reaching consequences for the entire ecosystem.
As the screenshot below shows, the Binarly Transparency Platform can accurately detect devices affected by this Boot Guard private key leak, as well as previous ones, without any false positives.
In our upcoming RSA Conference talk – "Repeatable Supply Chain Security Failures in Firmware Key Management,” we will discuss this incident along with past cases of private key management failures in the UEFI ecosystem. Save the date.
