Cyber Security News

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.
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:

Summary of the UEFI Secure Boot signing and verification process
  • 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

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 NameAuthenticode SHA256 Hash
BiosFlashShell-efi64-80.02.efiC54A4060B3A76FA045B7B60EEAEBC8389780376BA3EF1F63D417…
BiosFlashShell-efi64-81.02.efiCBFAA286144EB2D165A6B17245BAD4F73058436C7292BE56DC6…
Dtbios-efi64-70.17.efi9D7E7174C281C6526B44C632BAA8C3320ADDD0C77DC90778CC…
… (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.

Find this News Interesting! Follow us on Google NewsLinkedIn, & X to Get Instant Updates

Kaaviya

Kaaviya is a Security Editor and fellow reporter with Cyber Security News. She is covering various cyber security incidents happening in the Cyber Space.

Recent Posts

Kali Linux 2025.2 Released: New Tools, Smartwatch and Car Hacking Added

Kali Linux, the preferred distribution for security professionals, has launched its second major release of…

19 hours ago

Arsen Launches AI-Powered Vishing Simulation to Help Organizations Combat Voice Phishing at Scale

Arsen, the cybersecurity startup known for defending organizations against social engineering threats, has announced the…

20 hours ago

NIST Releases New Guide – 19 Strategies for Building Zero Trust Architectures

The National Institute of Standards and Technology (NIST) has released groundbreaking guidance to help organizations…

21 hours ago

Spring Framework Flaw Enables Remote File Disclosure via “Content‑Disposition” Header

A medium-severity reflected file download (RFD) vulnerability (CVE-2025-41234) in VMware's Spring Framework has been patched,…

21 hours ago

Microsoft Defender Spoofing Flaw Enables Privilege Escalation and AD Access

A newly disclosed spoofing vulnerability (CVE-2025-26685) in Microsoft Defender for Identity (MDI) enables unauthenticated attackers…

23 hours ago

Amazon Cloud Cam Flaw Allows Attackers to Intercept and Modify Network Traffic

A critical vulnerability (CVE-2025-6031) has been identified in Amazon Cloud Cam devices, which reached end-of-life…

23 hours ago