UEFI shell vulnerabilities allow attackers to bypass Secure Boot
One of our fears, as individuals who have spent years examining firmware security, is stumbling upon a vulnerability that reveals the fundamental flaws in our trust models. Recently, that fear became a reality when we conducted deeper research into signed UEFI shells and discovered what can only be described as signed backdoors on 200k laptops and desktops.
UEFI vulnerabilities like this can raise the specter of BlackLotus and Bootkitty, UEFI-bypassing bootkits that have been released and exploited in recent years. The impact is the same, but a key difference must be noted: signed UEFI shells aren’t traditional backdoors placed by malicious actors. Instead, they’re legitimate diagnostic tools signed with trusted certificates that contain functionality to effectively bypass security controls we’ve built into the boot process. The implications? Systems that have a secure boot process, in reality, do not.
This may sound academic, but the reality is that these capabilities are already being used for malicious or at least grey-area purposes outside their intended use. In the gaming world, commercial cheat providers openly sell UEFI-level anti-cheat bypasses for up to €40 a month, taking advantage of Microsoft-signed components to evade detection. The same techniques could be weaponized by nation-state or APT groups for espionage or sabotage, and recent cases, such as HybridPetya, suggest that ransomware operators are also adopting pre-OS infection methods. This ability to persist below the operating system while maintaining the facade of a “secure” boot process marks a dangerous escalation in attacker sophistication.
What Are UEFI Shells and Why Do They Exist?
UEFI shells are command-line environments that run before the operating system loads. Think of them as the firmware equivalent of a Windows Command Prompt or Linux bash shell, but with direct hardware access and elevated privileges that make administrator access look quaint by comparison.
These shells serve legitimate purposes in enterprise environments:
- Diagnostic Operations: IT administrators use them to diagnose hardware issues, test system components, and troubleshoot boot problems
- Firmware Updates: They provide a pre-OS environment for updating firmware components safely
- System Configuration: They allow configuration of hardware settings that aren’t accessible from the OS level
- Development and Testing: Firmware developers use them for testing UEFI applications and drivers
The problem isn’t their existence – it’s their implementation, specifically the trust granted via Secure Boot, and the dangerous commands they expose.
How Systems Learn to Trust Signed UEFI Shells
Here’s where things get interesting from a supply chain security perspective. The trust model for UEFI shells follows the same chain of trust as other boot components:
- Root of Trust: Microsoft’s UEFI Certificate Authority serves as the foundational trust anchor. These certificates are embedded in virtually every PC, laptop, and server shipped in the last decade.
- Third-Party Signing: Microsoft signs bootloaders and UEFI applications from various vendors using their third-party UEFI certificate authority. Once signed, these applications are trusted by default across the entire Windows ecosystem.
- Supply Chain Integration: OEMs and IBVs (Independent BIOS Vendors) integrate these signed components into their firmware images, often without fully understanding the security implications of the tools they’re including. OEMs also add their own certificates to the root of trust and sign software, such as UEFI shells, to ensure they are trusted only on the OEM’s hardware.
- Automatic Trust: When a system boots, the UEFI firmware automatically trusts anything signed with Microsoft’s or other vendors’ certificates, loading and executing shells, bootloaders, and drivers without question.
This trust model works beautifully—until it doesn’t. And in the case of UEFI shells with dangerous functionality, it spectacularly doesn’t.
The mm Command Secure Boot Bypass
At the heart of this issue is a seemingly innocent command: mm (memory modify). This command, present in many UEFI shells, provides direct read and write access to system memory. While this capability is essential for legitimate diagnostics, it’s also the perfect tool for bypassing every security control in the system.
Here’s what makes the mm command so dangerous:
- Direct Memory Access: The command can read from and write to any memory address in the system, bypassing all operating system protections and security boundaries.
- Pre-OS Execution: Since UEFI shells run before the operating system loads, they operate in an environment where modern security controls like ASLR, DEP, and kernel protections simply don’t exist.
- Signed and Trusted: Because these shells are signed with Microsoft certificates, they execute with implicit trust from the firmware, without triggering any security warnings or logging.
- Persistent Access: Commands can be scripted in startup.nsh files, allowing automated execution every time the system boots.
Eclypsium researchers Jesse Michael and Mickey Shkatov demonstrated exactly how devastating the mm command can be in their DEF CON 30 presentation “One Bootloader To Load Them All”. Their research reveals a clear path to completely bypassing Secure Boot while maintaining the system’s perception that it’s still protected.
The attack targets the Security Architectural Protocol, which is responsible for enforcing Secure Boot policies during the boot process. Here’s the step-by-step breakdown:
Step 1: Identify the Target Variable
The attack targets a global variable called gSecurity2, which points to the Security Architectural Protocol. This protocol is called by the LoadImage function to verify digital signatures before loading any UEFI modules.
Step 2: Locate the Memory Address
Using UEFI shell commands, an attacker can enumerate system handles and locate the memory address where the gSecurity2 variable is stored. Tools like the dh command can list handles, while memory inspection commands can help identify the exact location.
Step 3: Patch the Security Handler
Once the address is identified, the mm command can overwrite the security handler pointer with NULL or redirect it to a function that always returns “success” without performing any verification:
Shell> mm 0x[target_address] 0x00000000 -w 8 -MEM
This command writes zeros to the memory location containing the security handler pointer, effectively disabling signature verification for all subsequent module loads.
Step 4: Load Arbitrary Code
With the security handler neutralized, the system will load and execute any UEFI module, signed or unsigned. An attacker can then load their own bootkit, rootkit, or other malicious software, all while the system continues to report that Secure Boot is enabled and functioning.
Step 5: Establish Persistence
The most insidious aspect of this attack is its persistence. By placing the attack commands in a startup.nsh script, the bypass executes automatically on every boot, before any operating system security controls can intervene.
Real-World Discovery & Testing: Framework Signed UEFI Shells Vulnerability Disclosure
The Eclypsium research team identified signed UEFI shells distributed by Framework for select model laptops. The UEFI shells in this case are distributed by Framework for Linux users to update UEFI on their systems. For example, we extracted the certificates from the Secure Boot DB on a Framework system and tested to see if the UEFI shells from Framework were signed:
$ find ~/src/framework/ -name *.efi -type f -print -exec sbverify --cert db.der-0.pem --cert db.der-1.pem --cert db.der-2.pem {} \;
Framework_Laptop_13_12th_Gen_Intel_Core_3.08d_EFI_extracted/efi/boot/Bootx64.efi = Signature verification OK
Framework_Laptop_13_13th_Gen_Intel_Core_BIOS_3.07_EFI_extracted/efi/boot/Bootx64.efi = Signature verification OK
For the models listed above, the output indicates that the UEFI shell is signed to be authorized to run according to the DB included on Framework systems.
Further Testing
Given that this situation is not unique to Framework, we created scripts to test UEFI shells for the presence of the “mm” command described above. Using a Python script and the pefile Python library, we can look for indicators that the UEFI shell contains the mm command:
$ python test_for_mm.py vulnerable/efi/boot/bootx64.efi
Analyzing: vulnerable/Framework13-Intel-11thgen/efi/boot/bootx64.efi
=== UEFI Shell Analysis Results ===
File: vulnerable/Framework13-Intel-11thgen/efi/boot/bootx64.efi
Is UEFI Application: Yes
--- MM Command Indicators ---
[PARAMETER] -MMIO
Found in: DMEM [-b] [address] [size] [-MMIO]
[PARAMETER] -MMIO
Found in: -MMIO - Forces address cycles to the PCI bus.
[PARAMETER] -MMIO
Found in: Shell> dmem 1af3088 16 -MMIO
[PARAMETER] -MEM
Found in: MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
[PARAMETER] -MMIO
Found in: MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
[PARAMETER] -IO
Found in: MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
[PARAMETER] Address [Value]
Found in: MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
[PARAMETER] [-w 1|2|4|8]
Found in: MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
[PARAMETER] MM Address
Found in: MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
[PARAMETER] MM address
Found in: MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
[PARAMETER] mm Address
Found in: MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
[PARAMETER] mm address
Found in: MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
[PARAMETER] -MEM
Found in: -MEM - Memory Address type
[PARAMETER] -MMIO
Found in: -MMIO - Memory Mapped IO Address type
[PARAMETER] -IO
Found in: -IO - IO Address type
[PARAMETER] -IO
Found in: Shell> mm 80 -w 4 -IO
[PARAMETER] -IO
Found in: Shell> mm 80 52 -w 1 -IO
[PARAMETER] -IO
Found in: Shell> mm 80 -w 1 -IO
[PARAMETER] -MMIO
Found in: -mmio
[PARAMETER] -MEM
Found in: -mem
[PARAMETER] Read memory
Found in: Read Memory Failed
[PARAMETER] -IO
Found in: Lithium-ion
--- Function Analysis ---
Dangerous memory functions: 0
Legitimate memory functions: 7
✓ MemoryMappedIOPortSpace
✓ MemoryMapped(0x%x,0x%lx,0x%lx)
✓ MemoryMapped
✓ EfiMemoryMappedIOPortSpace
✓ EfiMemoryMappedIO
✓ MemoryMappedIO
✓ MemoryMappedIO, and MemoryMappedIOPortSpace memory types.
✓ Only diagnostic/read-only memory functions detected
--- Legacy Memory Functions (All) ---
MemoryMappedIOPortSpace
MemoryMapped(0x%x,0x%lx,0x%lx)
MemoryMapped
EfiMemoryMappedIOPortSpace
EfiMemoryMappedIO
MemoryMappedIO
MemoryMappedIO, and MemoryMappedIOPortSpace memory types.
--- Protocol References ---
No relevant protocol references found
--- Risk Assessment ---
Risk Level: HIGH
Risk Factors:
- Valid UEFI application
- MM command parameters found: 22
- Only legitimate memory functions found: 7
⚠️ HIGH: This binary shows strong indicators of MM command capability
Manual verification recommended in controlled environment
Next, we created a shell script that uses Qemu to launch the UEFI shell and automatically try to run the “mm” command:
We used these scripts to test and validate UEFI shells distributed by Framework. We discovered that the signed shells contained functionality that allowed them to manipulate memory and bypass Secure Boot. This information was disclosed to Framework, and they have been working on remediating the vulnerabilities affecting roughly 200k Framework laptops and desktops. Below is a chart indicating the status of the fix, removing the memory manipulation commands from the UEFI shells, and the DBX update status:
| Product | BIOS Version with Limited Shell | BIOS Version with DBX Update |
| Framework13 11th Gen Intel® Core™ | Vulnerable: Fixed planned in upcoming release 3.24 | Vulnerable: Fixed planned in upcoming release 3.24 |
| Framework13 12th Gen Intel® Core™ | Fixed in 3.18 | Fix Planned for version 3.19 (Date TBD) |
| Framework13 13th Gen Intel® Core™ | Fixed in 3.08 | Fixed in 3.09 |
| Framework13 Intel® Core™ Ultra Series 1 | Fixed in 3.06 | Fixed in 3.06 |
| Framework13 AMD Ryzen™ 7040 Series | Fixed in 3.16 | Fixed in 3.16 |
| Framework13 AMD Ryzen™ AI 300 Series | Fixed in 3.04 | Planned fix in 3.05 (Date TBD) |
| Framework16 AMD Ryzen™ 7040 Series (Laptop 16) | Fixed in 3.06 (Beta release) | Fixed in 3.07 |
| Framework Desktop AMD Ryzen™ AI 300 MAX Series | Fixed in 3.01 | Planned fix in 3.03 |
Framework is updating the DBX databases with previously released shells to blacklist them and sign a DBX database update that will block UEFI shells previously signed. Documentation will be published with instructions. Framework customers can contact Framework for more information and details on the timing of these rollouts.
For users who require immediate remediation steps, you can refer to the Framework documentation to delete the Framework DB key using the BIOS setup menu.
Real-World Impact: Beyond Proof-of-Concept
Signed UEFI shells are not a new problem, as there have been previous disclosures, including:
- Signed third-party UEFI bootloaders are vulnerable to Secure Boot bypass (VU#309662). Eclypsium researchers found that UEFI bootloaders signed and authenticated by Microsoft are vulnerable, allowing attackers to bypass Secure Boot. Multiple CVEs were issued: CVE-2022-34302, CVE-2022-34301, and CVE-2022-34303.
- CVE-2023-48733 – An insecure UEFI Shell in EDK2 was left enabled in Ubuntu’s EDK2, allowing attackers to bypass Secure Boot.
- CVE-2024-7344 – Vulnerable bootloaders associated with system recovery tools were signed and distributed, enabling malware such as HybridPetya to bypass Secure Boot to install ransomware.
- Disable Shells When Secure Boot is Enabled? – Recommendations from the community propose a change to the UEFI specification (EDK2) that disallows UEFI shells when Secure Boot is enabled.
- EDK2 Pull Request – One user, NikolaSchlej, makes an interesting point: “I think we also need to prevent OEMs from signing a shell and using it as a part of their workflows, especially ones facing the user. UEFI shell should be considered a developer-only tool that should never be a part of secure boot chain, and should never be released as a part of such.”
As we mentioned in the intro, this type of functionality is already exploited by video gamers looking to cheat. That’s pretty benign. Far more troubling is the potential for nation-state actors or advanced persistent threat groups to leverage these techniques for espionage or sabotage operations. The real potential for this has already been demonstrated by the discovery of malware, such as HybridPetya, that leverages CVE-2024-7344, as disclosed by ESET researchers. This may indicate that not only are advanced attackers aware of this technique, but ransomware groups and other less sophisticated attackers are also using pre-OS infection techniques. The ability to establish pre-OS persistence while maintaining the appearance of a secure system represents a significant escalation in attack sophistication.
Defensive Strategies: Fighting Back Against Signed Threats
The good news is that there are defensive measures available, though they require coordination across the entire industry:
- Revocation via DBX – The most important defense is keeping UEFI revocation lists (DBX) up to date. Microsoft has released DBX updates that blacklist vulnerable bootloaders and shells; however, end users and organizations must apply these updates.
- Password Protection – Set BIOS/UEFI setup passwords to prevent unauthorized changes to the configuration.
- Custom Secure Boot Keys – Where possible, implement custom Secure Boot key management to reduce reliance on Microsoft’s root of trust.
- UEFI Firmware Analysis – Tools like those provided by Eclypsium can scan systems for known vulnerable components and configuration weaknesses.
Conclusion: The Hidden Attack Surface
This issue forces us to confront some uncomfortable truths about our current security models. The concept of implicit trust based solely on digital signatures is fundamentally flawed when those signatures can be applied to components with dangerous functionality.
The discovery of these signed UEFI shell vulnerabilities serves as a stark reminder that our most fundamental security assumptions may be flawed. While we’ve spent decades hardening operating systems and applications, we’ve largely ignored the firmware layer that underlies everything else.
The attack surface “below” the operating system, encompassing firmware, bootloaders, and hardware components, presents a ripe target for threat actors. As our research demonstrates, attackers who can operate at this level can bypass virtually every security control we’ve built above it.
This isn’t just a technical problem – it’s a supply chain security crisis that requires coordinated action from hardware vendors, software companies, enterprise security teams, and individual users. The time for treating firmware as “someone else’s problem” is over. The most dangerous vulnerabilities often hide in the components we trust the most. In this case, that trust may be signed and delivered by Microsoft and OEMs themselves, who may not rush to fix the issues by revocation to avoid “bricking” systems or causing disruptions.
The lesson here isn’t that we should abandon trust altogether – it’s that we need to be much more careful about what we trust and why. In the context of firmware security, trusting without verification isn’t only naive but also dangerous.
Organizations that take action now to understand their firmware attack surface, implement proper configuration management, and maintain updated revocation lists will be far better positioned to defend against these sophisticated threats. Those that continue to operate under the assumption that “signed equals safe” may find themselves on the wrong side of a fundamental shift in the threat landscape.
The dusty corners of our infrastructure, those firmware components we rarely think about, are precisely where the next generation of attacks will emerge. It’s time we started paying attention.
