GNU GRUB CVE-2026-97876

Exploitation requires (1) a system booted with Secure Boot and GRUB lockdown mode active, and (2) a local attacker who can control/modify GRUB's configuration and invoke the GRUB 'serial' command with an attacker-chosen MMIO base address. The core prerequisite is write access to the boot configuration (reflected as PR:H), which normally implies prior admin or physical access. Limiting factors: it is not remotely reachable (AV:L), it demands high-privilege config control, and it has high attack complexity because the attacker must select an MMIO base that causes GRUB to write the specific values needed to reset the grub_file_verifiers list - making this a trust-boundary/lockdown bypass rather than an easily automated remote exploit.

This is a genuine but constrained security issue rather than a mass-exploitation priority. The CVSS 3.1 vector (AV:L/AC:H/PR:H/UI:N) is self-consistent with the description: exploitation is local, requires high privileges (control over GRUB's configuration), and has high attack complexity (the attacker must craft a precise MMIO base address so that GRUB writes specific non-arbitrary data that resets the grub_file_verifiers list). No EPSS score, KEV listing, or public POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active or widespread exploitation. The 6.4 Medium base score is appropriate - the high confidentiality/integrity/availability impact (full Secure Boot lockdown bypass enabling unsigned module loading) is heavily gated by the requirement that the attacker already control the boot configuration, which typically implies prior administrative or physical access. The realistic threat is an attacker defeating a trust boundary (Secure Boot/lockdown) they are not supposed to be able to cross, not remote compromise. No key signals are directly conflicting, but note that EPSS and KEV data are simply absent, not confirmed low/no.

An attacker who already has the ability to modify GRUB's configuration (e.g., a local admin or someone with physical access to a Secure Boot machine) invokes GRUB's serial command with a maliciously chosen MMIO base address. Because GRUB does not validate that the address points to a real UART device, the resulting writes land at an attacker-controlled memory location, resetting the grub_file_verifiers list so that subsequent module signature checks are skipped - letting an unsigned module load while GRUB still reports lockdown as enabled. No public exploit code was identified at time of analysis.