InsydeH2O UEFI CVE-2026-6485

Exploitation requires one of two access paths: (1) knowledge of the BIOS administrator password combined with the ability to reach the BIOS setup menu (local physical or KVM access), or (2) direct physical access to the machine where the BIOS is either unprotected or has been unlocked. The UEFI Shell must be enabled and accessible in the firmware build - many OEM configurations expose this by default for diagnostics. Attack requires local presence or equivalent privileged remote access (e.g., out-of-band management such as IPMI/iDRAC with BIOS-level access). No network-facing exploitation path exists (AV:L). Exploitation is further limited to systems where the OEM did not disable or restrict shell access in their InsydeH2O customization. Systems where the UEFI Shell is fully disabled or where BIOS access requires a hardware jumper/token are not exploitable through this vector.

The CVSS 3.1 vector AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H scores 8.2 (High), which reflects the high-privilege prerequisite but acknowledges the complete impact once that threshold is crossed. PR:H is the critical limiting factor: exploitation requires an attacker who already holds BIOS administrator credentials or physical access to the machine (e.g., to change BIOS settings or boot to external media). AC:L indicates no further complexity once access is obtained - the UEFI Shell is directly usable. The Scope:Changed metric is accurate and significant: bypassing Secure Boot invalidates every downstream security assumption made by the OS, hypervisor, and endpoint protection software, potentially enabling persistent firmware-resident or bootkit-level implants that survive OS reinstallation. No KEV listing and no public exploit have been identified, and EPSS data was not provided. Real-world priority is therefore high for environments with strict boot-integrity requirements (government, critical infrastructure, high-value enterprise), but lower for general consumer deployments where physical access controls are the primary defense. The absence of an exact fixed firmware version in public disclosures introduces supply-chain uncertainty: OEM patch availability is uneven.

An attacker with BIOS administrator credentials (or physical access to a system left unattended with BIOS unlocked) boots to the embedded UEFI Shell, then executes shell commands or drops a startup.nsh script on a FAT-formatted USB drive to load an unsigned bootloader or implant a pre-OS payload. Because execution occurs before Secure Boot can enforce signature checks, the attacker can install a bootkit that persists across OS reinstalls and is invisible to OS-resident endpoint security tools. No public exploit code has been identified, but the technique is well-documented in UEFI security research.