Found in the wild: 2 Secure Boot exploits. Microsoft is patching only 1 of them.
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2025-3052 | An arbitrary write vulnerability in Microsoft signed UEFI firmware allows for code execution of untrusted software. An arbitrary write vulnerability in Microsoft signed UEFI firmware allows for code execution of untrusted software. This allows an attacker to control its value, leading to arbitrary memory writes, including modification of critical firmware settings stored in NVRAM. Exploiting this vulnerability could enable security bypasses, persistence mechanisms, or full system compromise. NVD description · AI analysis pending | 8.2 | <1% | — | — | ||
| CVE-2025-47827 | Secure Boot Bypass via Expired Key in IGEL OS Before 11 (CVE-2025-47827) CVE-2025-47827 is a Secure Boot bypass in IGEL OS before version 11, caused by improper verification of a cryptographic signature (CWE-347) in the igel-flash-driver module, which improperly validates a signature using a key past its expiration date. An attacker with physical access (CVSS vector AV:P) can boot a crafted root filesystem from an unverified SquashFS image, defeating the platform's Secure Boot guarantee and loading attacker-controlled code at boot time; the CVSS scoring assigns high availability impact. Deployments running IGEL OS 10 or earlier are affected; CISA's affected-product list names IGEL OS only, while the CPE data additionally tags Windows 10 (1507, 1607, 1809, 21H2, 22H2), Windows 11 (22H2-25H2) and Windows Server 2012/2016 releases, reflecting the shared Microsoft Secure Boot key ecosystem rather than a CISA-listed Microsoft impact. The flaw was added to the CISA Known Exploited Vulnerabilities catalog on 2025-10-14, indicating confirmed in-the-wild exploitation, with ransomware use unknown and EPSS estimating a 4.9% (92nd percentile) probability of exploitation within 30 days. A public proof-of-concept is available (github.com/Zedeldi/CVE-2025-47827), and vendors/CISA have required mitigation per BOD 22-01 guidance. Do: Inventory all IGEL endpoints and upgrade any running OS 10 or earlier to IGEL OS 11 (current 11.x) per vendor instructions, which is the required KEV/BOD 22-01 remediation path. Because the attack requires physical access (AV:P), restrict physical and console access to thin clients in exposed locations such as lobbies, clinical areas and production floors, and inspect any device that may have been accessed for signs of root-filesystem tampering or unexpected boot behavior. The public PoC (Zedeldi/CVE-2025-47827) can be used to verify whether devices still boot an unverified SquashFS image. | 4.6 | 5% | KEV PoC |
| largeon the order of 100,000-1,000,000 IGEL endpoints (residual pre-v11 share of IGEL's multi-million-device installed base) - estimate |
Full article909 words · extracted from arstechnica.com · click to collapse
A skeleton key for hackers
The publicly available exploits provide a near-universal way to bypass key protections.
Credit: Getty Images
Researchers have unearthed two publicly available exploits that completely evade protections offered by Secure Boot, the industry-wide mechanism for ensuring devices load only secure operating system images during the boot-up process. Microsoft is taking action to block one exploit and allowing the other one to remain a viable threat.
As part of Tuesday’s monthly security update routine, Microsoft patched CVE-2025-3052, a Secure Boot bypass vulnerability affecting more than 50 device makers. More than a dozen modules that allow devices from these manufacturers to run on Linux allow an attacker with physical access to turn off Secure Boot and, from there, go on to install malware that runs before the operating system loads. Such “evil maid” attacks are precisely the threat Secure Boot is designed to prevent. The vulnerability can also be exploited remotely to make infections stealthier and more powerful if an attacker has already gained administrative control of a machine.
A single point of failure
The underlying cause of the vulnerability is a critical vulnerability in a tool used to flash firmware images on the motherboards of devices sold by DT Research, a manufacturer of rugged mobile devices. It has been available on VirusTotal since last year and was digitally signed in 2022, an indication it has been available through other channels since at least that earlier date.
Although the module was intended to run on DT Research devices only, most machines running either Windows or Linux will execute it during the boot-up process. That’s because the module is authenticated by “Microsoft Corporation UEFI CA 2011,” a cryptographic certificate that’s signed by Microsoft and comes preinstalled on affected machines. The purpose of the certificate is to authenticate so-called shims for loading Linux. Manufacturers install it on their devices to ensure they’re compatible with Linux. The patch Microsoft released Tuesday adds cryptographic hashes for 14 separate variants of the DT Research tool to a block list stored in the DBX, a database listing signed modules that have been revoked or are otherwise untrusted.
“This discovery underscores how a single vendor misstep can ripple across the entire UEFI supply chain, and why forward-leaning orgs are investing in continuous binary-level scanning and rapid dbx rollouts instead of relying on the once-a-year ‘secure-BIOS-update’ ritual,” said Alex Matrosov, CEO and founder of Binarly, the security firm that discovered the Secure Boot exploit. UEFI is short for Unified Extensible Firmware Interface, the motherboard-resident firmware that replaced the BIOS.
Binarly assigned a severity rating of 8.2 out of a possible 10 to CVE-2025-3052. Microsoft’s rating is 6.7. The vulnerability also received a patch on Tuesday from Red Hat and other distributors of Linux operating systems.
Introduced more than a decade ago by a consortium of companies, Secure Boot uses public-key cryptography to block the loading of any code during the boot-up process that isn’t signed with a pre-approved digital signature. It establishes a chain of trust between the hardware and software or firmware that boots up a device. Each link in this chain must be digitally signed with a certificate authorized by the device manufacturer. Microsoft requires it to be on by default. Some certification programs mandated by various governments also require Secure Boot protections to be in place.
But wait, there’s more
The second publicly available Secure Boot exploit was discovered by researcher Zack Didcott. As he reported earlier this month, CVE-2025-47827 stems from IGEL, a Linux kernel module for handling their proprietary logical volume management. The initial shim, which loads GRUB and the vulnerable kernel, is signed by Microsoft.
Attackers with even brief physical access to a device can boot it up in IGEL and then modify the boot loader to install malware. Didcott said he reported the vulnerability to Microsoft and has received no indication the company has plans to revoke the signature. Microsoft didn’t respond to emails seeking confirmation and the reason for its decision.
Researchers at Eclypsium, a firm specializing in firmware security, said the module provides a near-universal means for bypassing Secure Boot protections.
“Because Microsoft’s 3rd Party UEFI CA is trusted by almost all PC-like devices, an unrevoked vulnerability in any of the components verified with that key… allows you to break Secure Boot to load an untrusted OS,” one of the researchers, Jesse Michael, wrote in an email. “Any system that trusts the Microsoft 3rd Party UEFI CA will load and run their version of the shim, which has been signed by that key. Their shim will then use its own embedded key to verify the IGEL-signed kernel+initramfs and malicious rootfs, which can be modified to chain-load another operating system such as Windows or a different version of Linux.”
Aside from installing patches issued by Microsoft and others, there isn’t much users can do to shore up Secure Boot protection. Of course, people can take extra precautions to physically secure their devices, but the entire point of Secure Boot is to minimize threats stemming from evil maid scenarios.
Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at here on Mastodon and here on Bluesky. Contact him on Signal at DanArs.82.
Text extracted automatically; images, tables and formatting may be missing. Original: https://arstechnica.com/security/2025/06/unearthed-in-the-wild-2-secure-boot-exploits-microsoft-patches-only-1-of-them/