Ddos 
A new high-severity vulnerability discovered by BINARLY REsearch has reignited concerns about the integrity of the UEFI Secure Boot mechanism, a foundational security feature in modern computing. Tracked as CVE-2025-3052, the flaw—scoring 8.2 on the CVSS scale—stems from a vulnerable UEFI application that is signed with a Microsoft third-party UEFI certificate, granting it trusted status on a vast array of devices.
“An attacker can exploit this vulnerability to bypass Secure Boot, allowing them to execute untrusted code during the boot process,” BINARLY warned in their disclosure.
The maliciously exploitable component, identified as Dtbios-efi64-71.22.efi, is signed with the Microsoft Corporation UEFI CA 2011 key. This key is widely trusted across consumer and enterprise systems, making the application valid under Secure Boot policies.
The vulnerability lies in the application’s mishandling of a specific NVRAM variable named “IhisiParamBuffer”—a buffer from which the module blindly performs multiple memory writes.
“This allows an attacker to store an arbitrary memory address in the ‘IhisiParamBuffer’ NVRAM variable, and when the module runs, attacker-controlled writes will be performed,” the report explains.
In their proof-of-concept, BINARLY researchers demonstrated how a local attacker with OS-level privileges could overwrite a pointer to the gSecurity2 structure—a critical component that enforces Secure Boot checks.
By zeroing this pointer during the boot sequence, attackers can disable Secure Boot entirely, thus enabling the execution of unsigned UEFI modules like bootkits or early-stage malware.
“This PoC demonstrates how an attacker can bypass Secure Boot and load untrusted code without any user interaction or physical access to the device,” they stated.
The signed UEFI binary was found on VirusTotal and is widely trusted due to Microsoft’s signature. BINARLY notes that the issue may affect any system that trusts the Microsoft UEFI CA 2011 certificate—which includes the vast majority of modern Windows and Linux machines with Secure Boot enabled.
However, exploitation success may vary depending on hardware implementation. For instance, devices using Insyde BIOS may restrict NVRAM variable manipulation, slightly reducing the attack surface—unless paired with a second vulnerability.
“This advisory affects all devices where the previous loop condition eventually evaluates to false and all devices that trust the ‘Microsoft Corporation UEFI CA 2011’ certificate.”
BINARLY advises the following steps:
- Revoke the vulnerable EFI binary by adding its Authenticode hash to the UEFI revocation list (dbx database).
- Remove the vulnerable code from the application to prevent arbitrary writes from user-controlled NVRAM variables.
- Review NVRAM protections in firmware, especially around variables that influence bootloader behavior.
Related Posts:
- Multiple vulnerabilities affect all versions of ASUS routers
- PKfail Vulnerability: A New Threat to UEFI Security Unveiled by Binarly Research Team
- Security Alert: Bootkitty Bootkit Targets Linux via UEFI Vulnerability (CVE-2023-40238)
- LogoFAIL Vulnerabilities Expose Firmware Attacks: Endpoint Security Solutions at Risk
- LogoFAIL Vulnerabilities Expose Firmware Attacks: Endpoint Security Solutions at Risk
Donate