By Binarly REsearch

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 ha