A critical vulnerability has emerged that threatens the fundamental security of modern computing systems, allowing attackers to bypass Secure Boot protections and install malware directly into the boot process of PCs and servers.
CVE-2025-3052, designated as BRLY-2025-001, represents a memory corruption vulnerability discovered in a module signed with Microsoft’s third-party UEFI certificate, effectively compromising the chain of trust that underpins system security across millions of devices worldwide.
The high-level overview of a PoC exploiting CVE-2025-3052 (Source – Binarly)
The vulnerability’s impact extends far beyond individual systems, as it affects most devices supporting UEFI due to the widespread trust placed in Microsoft’s certificate infrastructure.
The compromised module, originally designed as a BIOS flashing tool for DT Research devices, has been circulating since at least October 2022, though it only surfaced on VirusTotal in November 2024.
Because the module carries Microsoft’s legitimate digital signature, it can execute on virtually any system that trusts the “Microsoft Corporation UEFI CA 2011” certificate, which includes the vast majority of modern computers.
Binarly researchers identified this sophisticated threat through their automated vulnerability detection platform, which flagged the unsafe handling of NVRAM variables within the signed application.
Summary of the UEFI Secure Boot signing and verification process (Source – Binarly)
The discovery process began when security analysts found the suspicious UEFI application on VirusTotal, leading to comprehensive analysis that revealed the vulnerability’s true scope and potential for widespread exploitation.
The technical foundation of this attack lies in the module’s blind trust of the IhisiParamBuffer NVRAM variable, which it reads and directly uses as a memory pointer without performing any validation or sanity checks.
This fundamental flaw grants attackers an arbitrary memory write primitive, enabling them to manipulate critical system components before the operating system loads.
Microsoft’s response included adding 14 different module hashes to the Secure Boot denial database (dbx) as part of their June 10, 2025 Patch Tuesday update, effectively blocking the vulnerable modules from executing on updated systems.
Attack Mechanism and Exploitation Pathway
The exploitation process demonstrates remarkable sophistication in its approach to circumventing modern security measures.
Attackers can leverage this vulnerability by first setting the IhisiParamBuffer variable from within the operating system, then registering the vulnerable module in the UEFI Boot Manager or replacing an existing OS loader.
The attack sequence involves the preparation of two components: the vulnerable signed module that serves as the initial breach point, and a secondary unsigned module containing the actual malicious payload.
During system reboot, when the firmware enters the Boot Device Selection phase, the vulnerable module executes with full privileges.
The module’s critical flaw lies in its direct use of the IhisiParamBuffer variable value plus 0x18 as a target address for memory write operations, as evidenced in the generated pseudocode from Binarly’s analysis framework.
By targeting the global variable gSecurity2, which holds a pointer to the Security2 Architectural Protocol used by the LoadImage function to enforce Secure Boot, attackers can effectively disable these protections by overwriting the pointer with zero values.
This manipulation creates a scenario where Secure Boot appears enabled to the operating system while remaining functionally bypassed, allowing unsigned malicious code to execute with impunity during the critical boot phase.
Speed up and enrich threat investigations with Threat Intelligence Lookup! -> 50 trial search requests
