Approximately 200,000 Framework devices running Linux were shipped with legitimately signed UEFI Shell components that include the memory modify (mm) command, according to Eclypsium. In the affected configuration, attackers can abuse mm to bypass Secure Boot and load persistent bootkits. Framework has acknowledged the issue and is rolling out fixes; users are advised to apply firmware updates promptly and limit physical access until patches are fully deployed.
UEFI Shell risk: signed diagnostics with raw memory access
UEFI Shell is a low-level diagnostic environment often signed to maintain Secure Boot compatibility. In this case, the Shell contains the mm command, which grants direct read/write access to system memory. Eclypsium reports that an attacker can use mm to tamper with critical runtime structures, including the gSecurity2 variable involved in verifying UEFI module signatures.
How this undermines Secure Boot
Secure Boot enforces a chain of trust that permits only trusted, signed components during early boot. If gSecurity2 is overwritten with NULL, signature verification can be effectively disabled. Once checks are bypassed, untrusted or malicious UEFI drivers and applications may execute pre-OS, enabling bootkit deployment and resilience across reboots.
Scope and root cause: configuration, not supply-chain compromise
Eclypsium estimates the exposure at roughly 200,000 Framework devices. The presence of the mm command is characterized as a misconfiguration in signed UEFI Shell components, not a supply-chain compromise. Framework has confirmed the problem and is issuing phased updates.
Attack scenarios and persistence mechanisms
An adversary who can launch UEFI Shell on a target system could use mm to disable verification and then stage a bootkit. The process can be automated via UEFI autorun scripts, allowing the payload to survive reboots and, in many cases, persist through OS reinstallation. The highest risk exists when attackers obtain physical access or can boot from removable media.
Mitigation guidance for Framework owners
Apply firmware/BIOS/UEFI updates from Framework as soon as they are released. Vendor patches are the primary control to prevent unsafe UEFI Shell behavior and restore Secure Boot integrity.
Until updates are installed, implement defense-in-depth:
Restrict physical access and harden firmware settings: set strong UEFI/BIOS passwords, disable or lock boot from external media, and enforce a controlled boot order.
Disable or limit UEFI Shell if the option exists, and block unauthorized UEFI drivers/applications from executing.
Temporarily remove the Framework DB key via BIOS where supported if updates are unavailable. This can reduce the chance that signed vendor Shell components are accepted. Note this may impact compatibility; reintroduce keys after patching.
Detection and hardening: measured boot and integrity monitoring
Continuously monitor Secure Boot policy changes and early-boot events. Use TPM-based measured boot and integrity tooling to track firmware and boot component measurements (for example, PCR logs) and investigate anomalies. Regularly review UEFI configuration to detect unauthorized changes. Historical cases such as LoJax and BlackLotus illustrate that pre-OS implants can survive OS reinstallation and evade traditional endpoint controls; measured boot and attestation can help surface such activity. Public guidance from Microsoft’s Secure Boot documentation and NIST resources align with these practices.
This incident underscores a recurring theme in platform security: legitimately signed diagnostics can become trust-chain liabilities if powerful features like raw memory access are left enabled in production. Organizations and individual users should prioritize timely firmware updates, minimize opportunities to run unsigned or unnecessary pre-OS code, and apply the principle of least functionality at the firmware level. Rapid remediation and stronger boot policies materially reduce the risk of persistent bootkits and Secure Boot bypass.
