Loading vulnerability…
CVE-2025-3052 is an arbitrary memory write vulnerability in Microsoft-signed UEFI firmware modules used by legitimate BIOS update utilities. The vulnerable code improperly reads a user-writable NVRAM variable without sufficient validation, allowing an attacker to influence a pointer or buffer used during the UEFI boot process and trigger arbitrary writes to memory before the operating system and kernel load. Public reporting indicates the flaw was identified in a BIOS flashing utility signed with Microsoft’s third-party UEFI certificate and that Microsoft’s investigation expanded the affected scope to 14 signed modules. A demonstrated exploitation path overwrites the global variable used to reference the Security2 Architectural Protocol, effectively neutralizing Secure Boot enforcement and permitting execution of unsigned UEFI modules.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
Repository is a research/PoC package for CVE-2025-3052, a UEFI Secure Boot bypass caused by trusting the NVRAM variable IhisiParamBuffer as a pointer and then writing through it without validation. The repo is not a framework module; it contains three main C-based EDK II UEFI applications plus two Ghidra Java analysis scripts and supporting documentation. Structure: (1) '01 Vulnerable Binaries/02 Educational Binary/CVE_2025_3052_Pkg/' is an EDK II package with DSC/DEC metadata and three UEFI applications: Component01 emulates the vulnerable DT Research/Insyde logic and reads IhisiParamBuffer from NVRAM before entering a vulnerable path; Component02 is an explanatory app that locates/discusses the DXE global gSecurity2 and explains how the arbitrary write can null it to disable Secure Boot; Component03 is the actual PoC-style exploit helper that asks the user for a custom IhisiParamBuffer value and writes that NVRAM variable. (2) '02 Exploitation Flow Analysis/PoC/' contains Ghidra scripts: Detect_CVE_2025_3052.java dynamically finds GetVariable("IhisiParamBuffer") usage and subsequent unvalidated writes, while DtbiosBehaviorReport.java generates a behavioral report for Dtbios-efi64-71.22.efi, including IHISI/SMI dependencies, NVRAM usage, and vulnerability location. (3) Markdown files document exploitation flow, prerequisites, affected module hashes, and mitigation context. Main exploit capability: local pre-boot/firmware abuse rather than remote compromise. The PoC enables controlled modification of the IhisiParamBuffer UEFI variable, which in the vulnerable signed module becomes an attacker-controlled arbitrary memory write primitive. The documented end goal is corruption of gSecurity2 during DXE so Secure Boot checks are bypassed and an unsigned UEFI PE/COFF payload can be loaded. This is therefore a local/firmware exploit chain requiring privileged OS access and reboot into a UEFI execution path. Notable endpoints/targets are mostly firmware artifacts rather than network IOCs: the NVRAM variable 'IhisiParamBuffer', the security target 'gSecurity2', UEFI protocol GUID symbols, EFI deployment paths on the ESP, and hardware I/O ports 0x66 and 0xB2 referenced by the analysis scripts. No C2 or external network infrastructure is present. Overall, this is a legitimate educational/operational PoC repository centered on demonstrating and analyzing a UEFI arbitrary-write primitive and Secure Boot bypass path, not malware or a fake exploit.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
28 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
A local security bypass vulnerability in HPE server platforms that can be exploited to achieve arbitrary code execution.
A UEFI Secure Boot bypass in DT Research UEFI applications (DTBios/BiosFlashShell) caused by improper handling of a runtime NVRAM variable enabling an arbitrary write primitive and modification of Secure Boot verification structures, allowing unsigned code execution during early boot.
A UEFI/boot-chain memory corruption issue in third-party UEFI-signed modules that could enable pre-OS execution of unsigned code and bootkit installation.
A Secure Boot bypass in a legitimately signed BIOS update utility (trusted via Microsoft’s UEFI CA 2011) that reads a user-writable NVRAM variable without validation, enabling arbitrary memory writes during UEFI boot and allowing Secure Boot enforcement to be disabled (e.g., by zeroing gSecurity2).
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.