A major firmware vulnerability has put over 200,000 Framework laptops and desktops at risk by allowing hackers to bypass Secure Boot protections using trusted diagnostic tools.
Quick Summary – TLDR:
- Signed UEFI shells distributed by Framework can disable Secure Boot through memory modification commands.
- Hackers can exploit this flaw to load bootkits or rootkits that persist undetected across reboots.
- Framework has released firmware updates and revocation lists to fix the issue across affected models.
- The flaw reveals deeper industry-wide challenges in trusting signed pre-boot components.
What Happened?
Researchers at Eclypsium found that legitimate UEFI diagnostic shells distributed by Framework include a powerful command that can disable Secure Boot, a key security feature that ensures only trusted code runs during system startup. These shells, signed with Microsoft-trusted certificates, allow memory manipulation that could lead to deeply persistent, undetectable malware infections.
Trust is something earned, except in the case of Secure Boot, where trust is often overlooked and never verified. Enter UEFI shells, included in many system utilities, have to be signed to work with Secure Boot. Functionality in UEFI shells allows attackers to bypass Secure Boot.… pic.twitter.com/A7JwFodFsF
— Paul Asadoorian @paulasadoorian@infosec.exchange (@securityweekly) October 14, 2025
Signed Tools Open the Door to Pre-Boot Attacks
Framework, known for its repairable and customizable laptops, offers UEFI shells primarily to help Linux users perform firmware updates. However, these tools include the mm command, which enables direct access to system memory. While useful for debugging, this command can also be used to overwrite memory addresses tied to Secure Boot enforcement, such as the gSecurity2 variable.
By modifying or nullifying this pointer, attackers can trick the system into believing Secure Boot is enabled even while loading unsigned code. This undermines the entire boot security chain, potentially allowing bootkits or rootkits to run with no warnings or errors reported to the operating system.
How the Attack Works?
Eclypsium researchers Jesse Michael and Mickey Shkatov showcased this technique, which involves:
- Launching the signed UEFI shell before the OS boots.
- Using shell commands to locate the Security Architectural Protocol.
- Running the mm command to alter the memory where signature checks happen.
- Disabling verification for any unsigned modules or code.
Attackers can automate this using startup scripts in the UEFI environment, ensuring persistence across reboots.
Real-World Impact and Threat Actors
Testing confirmed that Framework devices across multiple generations, including Intel Core and AMD Ryzen models, were affected. Using QEMU environments, sbverify, and Python scripts, researchers verified the presence of the mm command and demonstrated how easily the flaw could be exploited.
While no specific malware campaign has been directly linked to this vulnerability, similar Secure Boot bypasses have been used by ransomware like HybridPetya and offered by gaming cheat vendors. The existence of commercial tools selling for as much as 40 euros a month shows this is far from a theoretical issue.
More worryingly, the attack surface is appealing for nation-state actors and advanced persistent threats. Exploiting the trust placed in Microsoft-signed components, attackers can gain a foothold that’s almost invisible to traditional security tools.
Framework’s Response and Fixes
Framework has acknowledged the problem and is working actively to roll out fixes. Several BIOS updates have been released to remove the mm command from UEFI shells and update the DBX revocation list to blacklist vulnerable binaries.
Firmware Updates and Status by Model:
- Intel 13th Gen: Fixed in version 3.08 and DBX fix in 3.09.
- Intel 12th Gen: Shell fixed in 3.18, DBX fix planned for 3.19.
- Intel 11th Gen: Fix coming in version 3.24.
- AMD Ryzen 7040 Series: Fixed in version 3.16.
- AMD Ryzen AI 300 Series: Fix in 3.04, DBX update in 3.05 (planned).
- Framework 16 and Desktop models: Fixes included in latest beta versions or upcoming updates.
Framework also recommends that users manually delete the DB keys through BIOS setup to revoke trust for older UEFI shells. Detailed support resources are being made available for affected users.
SQ Magazine’s Takeaway
I find this case especially alarming because it shatters the long-held belief that signed means safe. Framework didn’t do anything shady, yet trusted tools became a liability due to how deeply Secure Boot trusts them. It’s a reminder that security isn’t just about locking the doors but checking who holds the keys. As users, we often assume firmware is safe if it looks official, but this proves that even the cleanest intentions can open dangerous holes. I strongly recommend updating your BIOS if you use a Framework device and start treating your firmware like the critical layer of defense it really is.
