CVE-2026-6484

This CVE exposes a verified boot gap where a firmware volume (FV) executes outside the measured boot chain. The 'certain FV' qualifier is deliberately unspecific, which itself signals a deeper problem: UEFI architectures lack a formal taxonomy distinguishing which firmware volumes MUST be verified from those permitted to run unverified as recovery paths or debug payloads. This isn't a novel discovery—CVE-2019-11097, CVE-2020-12353, and CVE-2022-21890 all surfaced the same pattern. What distinguishes this instance is the temporal dimension that defenders must internalize: coverage gaps don't only form at initial integration. The dangerous assumption is treating verified boot coverage as a one-time build-time configuration. In practice, firmware volumes get patched, refactored, or accumulate new capabilities that cross verification boundaries. A volume verified at initial integration can drift into unverified status as maintenance proceeds—no build failure fires, no review gate catches it. Attackers mapping this CVE class don't need zero-days inside the unverified FV; they need to identify which FV escaped coverage when the manifest was last touched. For defenders, three concrete actions matter. First, treat verified boot coverage as a versioned state requiring explicit re-confirmation whenever any FV changes, not a static checklist at build time. Second, interrogate your firmware supply chain for machine-readable trust metadata—if a third-party vendor delivers opaque FV blobs without attestation records, that's a contractual gap, not a tooling limitation. Third, recognize that remediation for this class runs in quarters, not weeks; the CVSS 8.2 severity compounds over an 18-36 month exposure window while patches propagate through OEM validation cycles. The architectural permission for unverified FV execution in UEFI is a design choice, not an inevitability. Until the industry treats 'which FVs may run outside measured boot' as an explicit trust boundary question rather than a configuration convenience, this CVE class will recur with each firmware release cycle.

Reviewed through automated stages and approved by a human before publication.