Analysis and exploitation of CVE-2025-4275 (Hydr0ph0bia), a Secure Boot trust-chain weakness where firmware variables are used to introduce attacker-controlled certificates trusted by subsequent boot components.
This repository contains research material related to CVE-2025-4275, a Secure Boot bypass vulnerability affecting UEFI-compatible firmware based on Insyde H2O. It centralizes technical analysis of the vulnerability, the binaries involved in the issue, as well as documentation and tooling intended to help researchers better understand, study, and experiment with this vulnerability in both real-world and educational contexts.
CVE-2025-4275 was originally discovered and responsibly disclosed by Nikolaj Schlej, with coordination handled through CERT/CC. Official and community references:
CVE-2025-4275, dubbed Hydroph0bia (a pun on Insyde H2O), is a Secure Boot bypass vulnerability affecting UEFI-compatible firmware built on the Insyde H2O platform. The vulnerability stems from a design flaw in the firmware update subsystem: a signing certificate meant to be loaded into a volatile NVRAM variable by a trusted driver can instead be pre-populated as a non-volatile variable by an attacker, causing the firmware to trust arbitrary external code as if it had been signed by Insyde themselves.
What makes this vulnerability particularly impactful is the combination of its simplicity and its reach. Exploitation only requires local administrator privileges, enough to write files to the EFI System Partition and create NVRAM variables, and affects any system running Insyde H2O firmware built before June 10, 2025. The attack is OEM-agnostic, meaning it applies broadly across Acer, Dell, Framework, Fujitsu, HP, Huawei, Lenovo, and any other vendor shipping Insyde-based firmware.
UEFI provides an abstract interface to non-volatile variable storage known as NVRAM. One long-standing quirk of this interface is that a non-volatile variable with a given name and GUID can coexist with, and shadow, a volatile variable with the same identity. If code expects a volatile variable (created at runtime by a trusted driver) but a non-volatile one with the same name already exists, the non-volatile version may be consumed instead. This behavior, sometimes called NVRAM variable shadowing, is the foundation of this vulnerability.
Insyde H2O's firmware update subsystem relies on two NVRAM variables to communicate a signing certificate between drivers:
In the expected flow, both variables are created as volatile by BdsDxe during the firmware update process. SecurityStubDxe then consumes them to verify that isflash.bin is signed by Insyde's certificate before allowing it to execute. The critical flaw is that SecurityStubDxe does not validate whether these variables are volatile or non-volatile before trusting their contents.
The root cause of CVE-2025-4275 is that SecurityStubDxe uses a generic library function to read SecureFlashSetupMode and SecureFlashCertData instead of calling the GetVariable runtime service directly. This means it cannot distinguish between a volatile variable set by a trusted BdsDxe and a non-volatile one pre-populated by an attacker (for a detailed explanation of this specific technique, refer to the following repository "TheMalwareGuardian: Exploitation Technique NVRAM Variable Shadowing").
As a result, an attacker with local administrator privileges can:
On the next boot, SecurityStubDxe will find both variables, treat them as legitimate, and trust any UEFI executable signed with the attacker's certificate, effectively bypassing Secure Boot entirely. No firmware-level interaction, hardware access, or exploitation of a memory corruption primitive is required. The attack surface is simply the UEFI NVRAM write interface, accessible from a privileged OS session.
The vulnerability was discovered during a security review of a HUAWEI MateBook 14 2023, running an Insyde H2O-based firmware with Secure Boot, firmware password, and other modern security features enabled. Despite these protections, full exploitation was achieved using only OS-level administrator privileges.
The initial exploitation stage requires a small Windows tool (SFCD) that:
After rebooting, SecurityStubDxe reads both variables and begins trusting anything signed by the attacker's certificate. A practical demonstration of this first stage is the loading of a custom-certificate-signed CrScreenshotDxe UEFI driver, which successfully captures a screenshot of the BIOS Setup screen, with Secure Boot enabled, as proof of arbitrary code execution in the firmware environment.
