Framework's Firmware Flaw Exposes 200,000 Laptops to Bootkits

A firmware flaw in 200,000 Framework laptops allows bootkit attacks, raising questions about trust in secure systems and the balance of user control versus safety.

Framework laptops contained a firmware backdoor bypassing Secure Boot. TechReviewer

Published: October 15, 2025

Written by Scarlett Sorokin

A Hidden Backdoor in Framework Laptops

A serious vulnerability in Framework laptops caught the industry off guard. Roughly 200,000 devices, designed with Linux users in mind, shipped with a firmware flaw that lets attackers bypass Secure Boot, a system meant to ensure only trusted software runs during startup. Discovered by Eclypsium researchers in October 2025, the issue stems from a memory modify command in UEFI shells, tools Framework included for firmware updates. This command, meant for diagnostics, opens a door to persistent bootkits like BlackLotus or HybridPetya, which can hide below the operating system and evade detection.

The flaw affects a wide range of Framework models, including the Framework 13 with Intel and AMD processors, Framework 16, and Framework Desktop systems. Attackers exploiting this could overwrite a critical security variable, disabling signature checks and allowing malicious code to run unchecked. What's worse, the system still reports Secure Boot as active, creating a false sense of safety. Framework has started rolling out patches, but the scale of the issue raises tough questions about trust in firmware security.

Why Firmware Trust Matters

Firmware sits at the heart of every modern device, acting as the bridge between hardware and software. Secure Boot, introduced in 2011, was designed to lock out unauthorized code by verifying digital signatures before execution. But this vulnerability shows how even trusted, signed components can carry dangerous flaws. The memory modify command, signed by Microsoft's UEFI certificate authority, was meant for low-level debugging but became a weapon for attackers to disable protections and install bootkits that persist across reboots.

This isn't just a Framework problem. The reliance on Microsoft's signing infrastructure means similar risks could lurk in devices from Dell, HP, or Lenovo. Eclypsium's findings build on earlier research, like their DEF CON 30 talk, which warned about weaponizing UEFI shells. The discovery of Bootkitty in November 2024, a Linux-targeted bootkit, and HybridPetya ransomware in September 2025 shows attackers are already exploiting these gaps. The stakes are high: bootkits can steal encryption keys or enable espionage, all while remaining invisible to antivirus tools.

Real-World Impacts: Ransomware and Gaming Cheats

The consequences of this flaw play out in starkly different ways. Take HybridPetya, a ransomware strain from September 2025 that exploits similar UEFI vulnerabilities. It sneaks past Secure Boot, encrypts critical system files, and demands $1,000 in Bitcoin, all while displaying fake error screens to mask its work. This case shows how firmware flaws can lead to direct financial harm, hitting users who thought their systems were secure.

Contrast that with gaming cheats, where UEFI exploits have found a surprising niche. For up to 40 euros a month, cheat providers sell tools that bypass anti-cheat systems in multiplayer games by operating at the firmware level. These exploits, targeting users' own hardware, highlight a gray area: what starts as a gaming shortcut can refine techniques later used by ransomware or nation-state hackers. Both cases underscore a hard truth; that firmware vulnerabilities don't just threaten data, they erode trust in the systems we rely on daily.

Balancing User Freedom and Security

Framework's mission to champion right-to-repair and modular design makes this vulnerability especially ironic. By empowering users with tools like UEFI shells for firmware updates, Framework supports Linux users and tinkerers who value control. But this openness created the very flaw that attackers can exploit. Firmware developers argue that commands like memory modify are essential for diagnostics and system recovery, especially in enterprise settings. Removing them entirely could hinder legitimate work, they say, suggesting stronger access controls like BIOS passwords instead.

Yet security researchers push back, arguing that UEFI shells should never reach end users in secure boot chains. The EDK2 community, which develops UEFI standards, is exploring changes to block such shells when Secure Boot is enabled. Framework's response, patching shells to limit dangerous functions and updating revocation lists, shows progress, but coordinating updates across 200,000 devices is no small feat. For users, applying these patches requires technical know-how, and some legacy systems may never see fixes, leaving them exposed.

Lessons From the Fallout

This vulnerability offers two clear lessons. First, trusting signed components without scrutinizing their functionality is a recipe for trouble. Framework's rapid patching, with updates like version 3.06 for Framework 13 AMD systems, sets a strong example, but the industry needs broader change. Security reviews of signed firmware must go beyond code integrity to assess what the code can do. Second, user empowerment and security don't have to be at odds. Framework's direct-to-consumer model lets them communicate fixes clearly, but the burden shouldn't fall on users alone.

Looking ahead, the industry is shifting. Regulations like the EU's Cyber Resilience Act demand tougher firmware security, while tools like Python-based scanners and QEMU testing help catch flaws early. For Framework users, applying patches is critical, but the bigger challenge is rebuilding trust in a system that promised security but delivered vulnerability. As firmware threats grow, from gaming cheats to nation-state espionage, the lesson is clear: no part of a device is too low-level to secure.