Research on CVE-2025-3052, an Insyde firmware vulnerability that exposes an arbitrary write primitive capable of modifying security-critical pointers.
This repository centralizes research material related to CVE-2025-3052, a memory corruption vulnerability in a UEFI module signed with Microsoft's third-party certificate that allows an attacker to corrupt security-critical firmware structures, neutralize Secure Boot enforcement, and execute arbitrary unsigned code before the operating system loads. It includes technical analysis of the root cause and exploitation technique, real-world and educational vulnerable binaries, and supporting documentation intended to help researchers understand, reproduce, and experiment with this vulnerability class.
CVE-2025-3052 was originally discovered and responsibly disclosed by the Binarly Research Team. Official and community references:
This repository includes two vulnerable binaries, provided with different research and learning objectives.
This binary represents the vulnerability as it existed in the wild.
CVE-2025-3052 is a Secure Boot bypass vulnerability affecting UEFI systems, caused by unsafe handling of data retrieved from an NVRAM variable inside a signed UEFI application. The vulnerability allows an attacker to corrupt security-critical firmware structures during the boot process, effectively breaking the UEFI chain of trust and enabling the execution of unsigned code before the operating system is loaded.
What makes this vulnerability particularly impactful is not only the nature of the bug itself, a memory corruption primitive, but the context in which it exists: a UEFI module signed with Microsoft's third-party UEFI certificate, trusted by default on the vast majority of modern systems. As a result, exploitation occurs at one of the earliest and most privileged execution stages of the platform, prior to OS-level security controls.
Secure Boot is a core security feature of UEFI designed to enforce the platform's chain of trust from firmware to operating system. Its primary purpose is to prevent unauthorized or malicious boot components, such as bootkits, from executing during the boot process.
At a high level, Secure Boot works by cryptographically validating UEFI executables before they are allowed to run. This validation is performed using two firmware-maintained databases:
A UEFI application is allowed to execute if either:
By default, most systems ship with the following certificates trusted in db:
The vulnerable modules associated with CVE-2025-3052 were signed using the Microsoft Corporation UEFI CA 2011 certificate. Because this certificate is widely trusted across vendors and platforms, any signed application using it can execute on most UEFI systems without user interaction. This broad trust significantly amplifies the impact of a vulnerability within such a module, as it effectively bypasses Secure Boot's intended protection guarantees.
The vulnerable UEFI module was initially discovered during large-scale analysis of UEFI binaries uploaded to public malware repositories, most notably VirusTotal. While the first public submission of the module occurred in November 2024, inspection of its Authenticode signature revealed that it had been signed as early as October 2022, indicating that the binary may have been circulating for a considerable amount of time before detection.
The original filename observed during analysis was Dtbios-efi64-71.22.efi. Examination of embedded strings, certificate metadata, and file behavior strongly suggested that the module was developed by DT Research, Inc, a vendor specializing in rugged mobile computing devices.
Further reverse engineering revealed that the module is a BIOS flashing utility, designed to read a firmware image from disk and write it to the system's ROM. Although originally intended for DT Research hardware, the module is not restricted to a specific platform and can execute on any system that trusts the Microsoft third-party UEFI certificate.
A critical clue during reconnaissance was the presence of the IhisiParamBuffer NVRAM variable. This variable is closely associated with Insyde-based firmware implementations and had previously been involved in other vulnerabilities disclosed by Binarly (e.g., BRLY-2022-023 and BRLY-2023-005). Its presence immediately suggested a potential class of NVRAM-related issues.
The root cause of CVE-2025-3052 lies in the unsafe use of data read from an NVRAM variable without validation. Specifically:
As a result, an attacker who can control the IhisiParamBuffer variable gains the ability to influence where in memory these writes occur. While the write primitive is somewhat constrained, typically allowing writes of zero or small constants to an arbitrary address, it is still powerful enough to corrupt critical firmware state.
In Binarly's proof of concept, the attack targets the global variable gSecurity2, which holds a pointer to the Security2 Architectural Protocol (for a detailed explanation of this specific exploitation technique, refer to the following repository "TheMalwareGuardian: Exploitation Technique SecureBoot Bypass gSecurity2 Corruption"). This protocol is consulted by the LoadImage service to enforce Secure Boot policy, meaning that overwriting gSecurity2 with a null pointer effectively disables Secure Boot checks at runtime. Crucially, this bypass is transparent to the operating system: once booted, Secure Boot still appears enabled at the OS level even though it has been fully neutralized at the firmware level.
An important nuance is that on Insyde-based platforms, the IhisiParamBuffer variable is typically locked as read-only, which effectively prevents exploitation on those systems without an additional vulnerability. Ironically, this means the vendor whose IBV introduced the vulnerable variable pattern in the first place is among the least exposed, while all other platforms remain at risk. For cases where the variable is locked, a bypass such as BRLY-2023-005 can be chained to gain write access to the variable before proceeding with exploitation. On systems where the variable is directly writable, the attack is straightforward and highly reliable.
The following describes the end-to-end attack leveraging CVE-2025-3052, assuming a privileged attacker with OS-level access:
Microsoft determined that 14 different UEFI modules were affected and mitigated the issue by adding their hashes to the Secure Boot dbx.
| Module Name | Authenticode SHA-256 Hash |
|---|---|
| BiosFlashShell-efi64-80.02.efi | C54A4060B3A76FA045B7B60EEAEBC8389780376BA3EF1F63D417BA1B5528E95 |
| BiosFlashShell-efi64-81.02.efi | CBFAA286144EB2D165A6B17245BAD4F73058436C7292BE56DC6EBA29A369ADDF |
| Dtbios-efi64-70.17.efi | 9D7E7174C281C6526B44C632BAA8C3320ADDD0C77DC90778CC14893882D74618 |
| Dtbios-efi64-70.18.efi | 9B1F35052CFC5FB06DABE5E8F7B747F081DA28D722DB59ADE253B9E38A7A3C76 |
| Dtbios-efi64-70.19.efi | E3CE55E584371D3F2FBCA2241EF0711FF80876EBF71BAB07D8ECEE645A40DCFC |
| Dtbios-efi64-70.20.efi | EE093913ABBD34CB8B5EA31375179A8B55A298353C03AFE5055AA4E8E3F705EF |
| Dtbios-efi64-70.21.efi | B4E1880425F7857B741B921D04FD9276130927CF90A427C454B970E7A2F442F9 |
| Dtbios-efi64-70.22.efi | CDA0B4A59390B36E1B654850428CBB5B4C7B5E4349E87ACDE97FB543736FF1D4 |
| Dtbios-efi64-71.17.efi | C87EFD057497F90321D62A69B311912B8EF8A045FE9C5E6BD5C8C1A4E6F39629 |
| Dtbios-efi64-71.18.efi | 9E19DD645235341A555D6AC0665591453AE13918ECD37DF22DFBEE91EAA9A2DA |
| Dtbios-efi64-71.19.efi | 63F67824FDA998798964FF33B87441857DA92F3A8EE3E04166EEC3156E4E6B82 |
| Dtbios-efi64-71.20.efi | 0BC4F078388D41AB039F87AE84CF8D39302CCBDD70C4ADEE02263EBF6A2DD328 |
| Dtbios-efi64-71.21.efi | E2AEC271B9596A461EB6D54DB81785E4E4C615CFDA5F4504BCC0A329248A4D36 |
| Dtbios-efi64-71.22.efi | 6B4328EBCBE46ED9118FF2D4472DE329D70BA83016DF7A6F50F8AF92342160A1 |
Working on something similar? Researching UEFI, Kernel security, exploitation, or another interesting security topic? If you need a hand developing an exploit, exploring a technique, or just want to exchange ideas, don't hesitate to reach out. I'm always open to discussing research, helping where I can, and collaborating on interesting projects. Feel free to contact me on LinkedIn.
