In this blog post, the Binarly Research team documents a Secure Boot bypass that likely impacts most devices supporting UEFI. At the center of this discovery is CVE-2025-3052 (BRLY-2025-001), a memory corruption vulnerability in a module signed with Microsoft’s third-party UEFI certificate. Attackers can exploit this vulnerability to run unsigned code during the boot process, effectively bypassing Secure Boot and compromising the system’s chain of trust. Because the attacker’s code executes before the operating system even loads, it opens the door for attackers to install bootkits and undermine OS-level security defenses.
The story behind this discovery begins with a UEFI application we found on VirusTotal, signed with Microsoft’s third-party UEFI certificate. This application has been publicly available since November 2024 when it was first submitted. However, the signature data indicates it was actually signed in October 2022, suggesting it may have been circulating for much longer.
The application is a BIOS flashing tool for devices sold by DT Research, a company specializing in rugged mobile devices. Although this module was originally developed for DT Research devices only, it can run on any device that trusts the certificate with subject "Microsoft Corporation UEFI CA 2011" certificate. This includes the vast majority of systems, as the same certificate is widely used to sign the Linux bootloader shim, significantly increasing the potential impact of this vulnerability.
The root cause of this bug, once again, lies in the unsafe handling of NVRAM variables. Issues involving NVRAM variables have been a persistent problem in the UEFI ecosystem, with Binarly alone responsibly disclosing hundreds of related vulnerabilities over the past few years. Because these bugs have been so widespread and impactful, our Binarly Transparency Platform performs multiple analyses to detect these bug classes. One of these checks looks specifically for any unsafe usage of data read from NVRAM variables, and this analysis is what automatically discovered CVE-2025-3052.
As shown in the image below, the signed application reads the content of the IhisiParamBuffer variable and directly uses it as a pointer for multiple memory write operations, without performing any validation or sanity checks on its value. This allows an attacker to set the IhisiParamBuffer variable to any arbitrary address in memory, effectively granting them an arbitrary memory write primitive.
We reported this finding to CERT/CC on February 26, 2025. During our disclosure with Microsoft, it became clear that this issue wasn’t limited to a single module, but it actually affected 14 different modules. For this reason, to address CVE-2025-3052, Microsoft added 14 new hashes to the Secure Boot dbx as a mitigation measure, which was delivered as part of Patch Tuesday on June 10, 2025.
Secure Boot and Microsoft Certificates
Before delving into the details of CVE-2025-3052, let’s recap what Secure Boot is and what security problems it solves. First of all, Secure Boot plays a crucial role in the chain of trust built by UEFI. It can be thought of as a bridge connecting the system’s firmware to the operating system, carrying trust from one bank to the other. At the end of the DXE phase, with the platform initialized, the firmware is ready to boot the OS. With Secure Boot, the firmware cryptographically verifies the integrity and authenticity of the OS loader before handing over control. This check stops attackers from replacing the legitimate OS loader with a malicious component, such as a bootkit. Without Secure Boot, it is trivial for attackers to gain early execution, compromising OS defenses before the OS even has a chance to install them.
UEFI applications are signed with the private part of a signing certificate (leaf certificate on the image) that chains through one or more intermediate certificates to a trusted, root CA certificate from db. This is for example what happens with applications signed by Microsoft, where the private key of the certificate with subject “Microsoft Corporation UEFI CA 2011” signs the signing/leaf certificate, whose private key is in turn used to sign the Authentocode hash of the UEFI Application.
The verification process is instead based on two signature databases: db and dbx. The db contains a list of trusted Authenticode hashes and root certificates:
The dbx instead contains Authenticode hashes and certificates that are untrusted or revoked.
Depending on whether the application is signed, the firmware allows execution based on either its Authenticode hash or CA certificate being present in the db and not present in the dbx. By default, most devices are shipped with at least these trusted certificates present in db:
The second certificate is the one used to sign the vulnerable application. As previously mentioned, this certificate is widely trusted and present in db, since it’s used to sign components like the Linux’s shim, the EFI application responsible for booting Linux systems.
The Beginning: Module Discovery and Reconnaissance
This REsearch began after the discovery of the vulnerable UEFI module on VirusTotal. The first submission on VT was done in November 2024 but the signing time dates back to October 2022, meaning that this module may have been around for a longer time. The original submission filename was Dtbios-efi64-71.22.efi.The filename, combined with details from the Authenticode certificate and strings found within the binary itself, led us to conclude that the module has been developed by “DT Research, Inc”.
Additionally, the name of the vulnerable NVRAM variable immediately pointed to Insyde as the Independent BIOS Vendor (IBV) involved. This same variable had already been at the center of two vulnerabilities we previously reported: BRLY-2022-023 and BRLY-2023-005.
After some reversing, we also conclude that the module is a BIOS update utility, as it reads a BIOS image from a file and attempts to flash it onto the device’s ROM.
The Intermezzo: Finding and Exploiting CVE-2025-3052
Our Binarly Transparency Platform can automatically detect a wide range of UEFI-related vulnerabilities, including issues involving NVRAM variable handling. As a result, identifying the vulnerability behind CVE-2025-3052 was as simple as uploading the affected module to our platform.
The generated report (shown in the image below) immediately revealed the impact of this finding: the root cause behind the vulnerability is the use of untrusted pointers originating from an NVRAM variable. Additionally, our patented reachability metric confirmed that the vulnerable function is directly accessible from the module's entry point, thus likely exploitable.
The pseudocode shown in the next image, generated by our platform as evidence of the issue, enabled quick and effective triaging of the vulnerability. This pseudocode is generated using Binarly’s program analysis framework delivering comprehensive static analysis techniques.
The vulnerable function reads the value of the IhisiParamBuffer NVRAM variable and stores it in a global variable located at address 0xf7a0. Later, the value of this global variable plus 0x18 is used as the target address for a memory write operation, setting it to zero. Subsequent writes are also attacker-controlled, since var2 points to the same NVRAM variable (our platform generates independent findings for these additional write operations as well).
While this write capability is constrained, as it only allows writing zeros or a few constants to an arbitrary address, it provides a powerful primitive that can be exploited in a variety of creative ways. For our proof of concept (PoC), we chose to overwrite the global variable gSecurity2. This variable holds a pointer to the Security2 Architectural Protocol, which the LoadImage function uses to enforce Secure Boot. By setting it to zero, we effectively disable Secure Boot, allowing the execution of any unsigned UEFI modules.
One prerequisite for this vulnerability is that the IhisiParamBuffer variable must be writable. On Insyde-based devices, this variable is often locked and read-only. Therefore, unless there is another vulnerability (such as BRLY-2023-005, which allows setting arbitrary variables even if locked) Insyde-based devices are not vulnerable.
All other devices, however, remain vulnerable. Thinking about it, this situation is quite unique and it highlights, once again, the complexities surrounding the UEFI supply chain security, where a mistake by one vendor can affect the entire ecosystem, except for the vendor itself!
The following figure provides a high-level overview of an attack leveraging CVE-2025-3052. A privileged attacker can set the IhisiParamBuffer variable from the operating system (Step 1) and register the vulnerable module in the UEFI Boot Manager, or replace an existing OS loader with the malicious module.
Additionally, the attacker registers a second unsigned module containing the actual payload they intend to execute (Step 2). After the victim's device reboots (Step 3) and the firmware enters the Boot Device Selection (BDS) phase, the vulnerable module is executed. Its arbitrary write capability allows the attacker to overwrite gSecurity2, effectively disabling Secure Boot. With Secure Boot disabled, the second unsigned module is then loaded and executed by the firmware, granting the attacker arbitrary code execution at the end of the DXE phase (Step 4).
Based on the previous description, we recorded a demo video demonstrating the different stages of this PoC. One important aspect is that the PoC is transparent to the operating system: as shown at the end of the video (at minute 1:07), Secure Boot still appears to be enabled from the OS, even though it has been effectively bypassed.
The Conclusion: Disclosure and Remediation for CVE-2025-3052
After discovering this vulnerability, we opened a case with CERT/CC on February 26, 2025 to notify the affected parties and help provide a fix and detection for impacted Binarly customers.
During the triage process, Microsoft determined that the issue did not affect just a single module as initially believed, but actually 14 different modules. For this reason, the updated dbx released during the Patch Tuesday on June 10, 2025 contains 14 new hashes.
In terms of remediation, we recommend that impacted users update the dbx as soon as possible. In our previous research blog “From Trust to Trouble: The Supply Chain Implications of a Broken DBX,” we described in detail the potential impact of outdated and inconsistent dbx.
Detecting CVE-2025-3052
Secure Boot bypasses continue to be a persistent issue within the UEFI ecosystem, with new vulnerabilities surfacing a few times each year. For example, in January 2025, ESET researchers disclosed the details of another Secure Boot bypass (CVE-2024-7344). In addition, following the discrepancies we uncovered in the dbx and their supply-chain implications that we discussed earlier this year, we decided to implement a new feature in our product specifically focused on Secure Boot security. This addition ensures that the Binarly Transparency Platform users are promptly informed with precise findings about any issues affecting Secure Boot, so that they can quickly remediate them.
Here is a demonstration of the Binarly Transparency Platform detecting and reporting on this Secure Boot bypass issue.
Binarly Deep Vulnerability Analysis (DVA) technology detects automatically CVE-2025-3052 as a previously unknown vulnerability (0-day):
Binarly Mitigate technology proactively detects signed vulnerable modules in DB/DBX databases to highlight potential high-impact risks:
