New Secure Boot Vulnerability Allows Attackers to Install Malware in PC and Server Boot Processes

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.

Technical Background and Vulnerability Details

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:

• db: Contains trusted Authenticode hashes and root certificates.
• dbx: Contains revoked or untrusted hashes and certificates.

By default, most devices include at least the following certificates in the db database:

• Microsoft Windows Production PCA 2011 (for the Windows bootloader)
• Microsoft Corporation UEFI CA 2011 (for third-party bootloaders and components, such as Linux’s shim)
• OEM certificates (for vendor-specific utilities)

These certificates allow boot components signed by Microsoft and OEMs to be trusted.

The Vulnerability: CVE-2025-3052

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:

1. Set the Malicious Variable:
   A privileged attacker on a running system sets the IhisiParamBuffer variable.
2. Register the Malicious Module:
   The attacker registers the vulnerable module (or a replacement) with the UEFI Boot Manager.
   Alternatively, they can replace the existing OS loader.
3. Trigger Reboot and Exploit:
   On reboot, the vulnerable module is executed. It reads IhisiParamBuffer and uses it for memory writes, allowing the attacker to overwrite critical security variables.
4. Disable Secure Boot:
   For example, overwriting the gSecurity2 variable (a pointer to the Security2 Architectural Protocol) with zero disables Secure Boot.
5. Execute Malicious Payload:
   With Secure Boot disabled, the attacker’s unsigned module is executed.

Pseudocode Example:

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.

Impact and Mitigation

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:

• Early execution of malicious code (before the OS loads)
• Installation of persistent malware (bootkits)
• Complete compromise of OS-level security measures

Interestingly, on Insyde-based devices, the variable is often locked and read-only, making exploitation more difficult unless another vulnerability is present.

Microsoft’s Response and Mitigation

Upon discovery, 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) …	…

---

Broader Implications and Industry Response

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:

• Supply Chain Risks: Mistakes by one vendor can impact the entire ecosystem, especially when a widely trusted certificate is involved.
• Importance of Transparency: Automated analysis and transparency platforms like Binarly’s are crucial for early detection of such vulnerabilities.
• Vendor Coordination: Prompt disclosure and coordinated mitigation efforts (like database updates) are essential to protecting users.

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.