Security researchers from Binarly have uncovered a major software vulnerability in the Unified Extensible Firmware Interface (UEFI) ecosystem, specifically impacting the Secure Boot mechanism used by almost all modern PCs and servers.
Dubbed CVE-2025-3052 (BRLY-2025-001), this memory corruption flaw enables attackers to execute unsigned code during the early boot phase, bypassing Secure Boot protections and potentially compromising the entire device.
Modern computers use UEFI firmware as a replacement for older BIOS firmware.
A critical component of UEFI is Secure Boot, a security feature that cryptographically verifies the integrity of the operating system loader before execution.
This ensures only trusted, signed executables can run during the boot process, thwarting efforts by attackers to replace the legitimate OS loader with malware such as bootkits.
Secure Boot relies on two databases:
By default, most devices include at least the following certificates in the db database:
These certificates allow boot components signed by Microsoft and OEMs to be trusted.
The vulnerability was discovered in a BIOS flashing utility developed by DT Research, signed using the Microsoft Corporation UEFI CA 2011 certificate. Since this certificate is widely trusted and used to sign components including Linux’s shim, the potential impact is vast.
Root Cause: The vulnerable module reads an NVRAM variable called IhisiParamBuffer
and uses its content as a pointer for memory write operations, without any sanity checks.
This allows an attacker to set IhisiParamBuffer
to an arbitrary memory address, granting them an arbitrary memory write primitive.
Exploitation Flow:
IhisiParamBuffer
variable.IhisiParamBuffer
and uses it for memory writes, allowing the attacker to overwrite critical security variables.gSecurity2
variable (a pointer to the Security2 Architectural Protocol) with zero disables Secure Boot.c// Vulnerable code in the module
void vulnerable_function() {
void* ptr = NvRamGetVariable(L"IhisiParamBuffer", ...);
*(ptr + 0x18) = 0; // Arbitrary write to attacker-controlled address
// ... more writes possible ...
}
This means that by controlling IhisiParamBuffer
, an attacker can write zeros (or other constants) to any address in memory, not just the gSecurity2
variable shown here.
The vulnerability affects virtually any device that trusts the Microsoft Corporation UEFI CA 2011 certificate, which is most PCs and servers worldwide.
Successful exploitation allows attackers to bypass Secure Boot entirely, resulting in:
Interestingly, on Insyde-based devices, the variable is often locked and read-only, making exploitation more difficult unless another vulnerability is present.
Binarly reported the issue to CERT/CC and worked with Microsoft, which found the problem was not limited to a single module but affected 14 different modules (see list below).
As a mitigation, Microsoft added all affected hashes to the dbx (blocked) database as part of Patch Tuesday on June 10, 2025.
List of Affected Modules and Authenticode Hashes:
Module Name | Authenticode SHA256 Hash |
---|---|
BiosFlashShell-efi64-80.02.efi | C54A4060B3A76FA045B7B60EEAEBC8389780376BA3EF1F63D417… |
BiosFlashShell-efi64-81.02.efi | CBFAA286144EB2D165A6B17245BAD4F73058436C7292BE56DC6… |
Dtbios-efi64-70.17.efi | 9D7E7174C281C6526B44C632BAA8C3320ADDD0C77DC90778CC… |
… (truncated for brevity, 11 more) … | … |
This vulnerability highlights ongoing issues in UEFI security, particularly around the handling of NVRAM variables and trusted certificates.
Binarly has disclosed hundreds of similar issues in recent years, underscoring the need for improved supply chain security and better auditing tools for UEFI firmware.
Key Takeaways:
The discovery of CVE-2025-3052 is a stark reminder of the challenges in securing firmware and the far-reaching impact of supply chain vulnerabilities.
While Microsoft’s Patch Tuesday update blocks the most common attack vectors, organizations and users must remain vigilant, apply patches promptly, and consider the broader implications for their own supply chains.
For IT professionals and security teams, the Binarly report serves as a valuable case study in firmware security, highlighting the importance of robust code auditing, NVRAM variable handling, and the need for ongoing vigilance in the face of increasingly sophisticated attacks on the boot process.
Find this News Interesting! Follow us on Google News, LinkedIn, & X to Get Instant Updates
Kali Linux, the preferred distribution for security professionals, has launched its second major release of…
Arsen, the cybersecurity startup known for defending organizations against social engineering threats, has announced the…
The National Institute of Standards and Technology (NIST) has released groundbreaking guidance to help organizations…
A medium-severity reflected file download (RFD) vulnerability (CVE-2025-41234) in VMware's Spring Framework has been patched,…
A newly disclosed spoofing vulnerability (CVE-2025-26685) in Microsoft Defender for Identity (MDI) enables unauthenticated attackers…
A critical vulnerability (CVE-2025-6031) has been identified in Amazon Cloud Cam devices, which reached end-of-life…