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.
An important nuance: the IhisiParamBuffer variable present in CVE-2025-3052 is often locked on Insyde-based platforms, making direct exploitation harder there. CVE-2025-4275 requires no such variable to be writable and does not depend on any memory corruption primitive. The attack works on any Insyde H2O system where the attacker can write to NVRAM, which is the default behavior on unpatched firmware.
The following describes the end-to-end attack for the initial Secure Boot bypass stage, assuming a privileged attacker with OS-level access:
The Secure Boot bypass achieved in Part 1 opens the door to a significantly more impactful second stage: full takeover of the DXE volume, achieved by hijacking the Insyde firmware update process itself.
The firmware update subsystem in Insyde H2O works as follows: the OS updater places a firmware capsule and the signed updater application (isflash.bin) onto the EFI System Partition, then sets a SecureFlashTrigger=1 flag inside the SecureFlashInfo NVRAM variable. On the next boot, the firmware detects the trigger, disables flash write protections during PEI, and eventually calls LoadImage on isflash.bin after verifying it against the Insyde certificate, the same certificate mechanism that CVE-2025-4275 allows an attacker to replace.
Three additional technical steps are required to escalate from Secure Boot bypass to DXE takeover:
Once all three conditions are met, the firmware reboots into update mode, loads the attacker's custom isflash.bin (signed with the attacker's certificate, now trusted due to the shadowed SecureFlashCertData), and executes it with the SPI flash unprotected. From this position, the attacker can write arbitrary content to the DXE volume, installing persistent drivers or modifying firmware components in ways that survive OS reinstallation and most security controls.
Insyde released a fix as part of the June 10, 2025 patch cycle. The fix was analyzed by comparing two consecutive Dell BIOS updates (one pre-patch, one post-patch) using UEFITool-generated reports and binary diffing via Diaphora.
The changes were concentrated in three drivers:
The fix is effective under the assumption that an attacker cannot bypass VariablePolicy or LibSetSecureVariable. However, the VariablePolicy default EDK2 implementation uses a global flag internally, which is structurally similar to InsydeVariableLock defeated in Part 2. Physical NVRAM editing via SPI programming hardware would also bypass the fix entirely, though physical attacks are conventionally out of scope for Secure Boot threat models.
The researcher's recommended remediation, removing NVRAM entirely from the certificate relay mechanism between BdsDxe and SecurityStubDxe, was attempted by Insyde but caused regressions and was deferred to a future engineering cycle.
Any vendor shipping Insyde H2O-based firmware built before June 10, 2025 is potentially affected. Confirmed status at time of disclosure:
| Vendor | Status |
|---|---|
| Dell | Fixed - BIOS updates released shortly after embargo end |
| Lenovo | Vulnerable - fixes announced, delivery from 2025-07-30 onward |
| Framework | Vulnerable - no delivery estimate provided at time of disclosure |
| Acer | No advisory or fix published at time of disclosure |
| Fujitsu | No advisory or fix published at time of disclosure |
| HP | No advisory or fix published at time of disclosure |
| Huawei | Original test device vendor - fix status unknown |
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.
