Description

An issue was discovered in SysPasswordDxe in Insyde InsydeH2O. User and administrator password hashes are exposed in runtime UEFI variables, leading to escalation of privilege

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-03T13:04:12.157Z",
  "pubdate": "2026-09-03T13:04:12.157Z",
  "executiveSummary": "A vulnerability within the SysPasswordDxe component of Insyde InsydeH2O firmware allows for the unauthorized retrieval of sensitive authentication material. The flaw originates from the insecure handling of user and administrator password hashes, which are inappropriately exposed within runtime accessible UEFI variables.\nThis vulnerability constitutes an information disclosure issue that results in a significant escalation of privilege. An attacker with the ability to interface with the firmware environment can extract these hashes for offline cracking or direct reuse, potentially bypassing firmware-level authentication mechanisms.\nThe scope of impact is critical, as it undermines the integrity of the UEFI Secure Boot and BIOS password protection ecosystem. By gaining access to these secrets, an adversary can achieve persistent control over the platform, modify secure boot configurations, or disable platform security features. Successful exploitation requires local access to the system to query the UEFI runtime services, but once accessed, the credentials can be extracted without specialized hardware or sophisticated physical exploitation techniques.",
  "technicalDetails": "The vulnerability resides in the SysPasswordDxe driver, a component responsible for managing BIOS password authentication within the InsydeH2O UEFI firmware implementation. The root cause is the improper storage configuration of sensitive password hashes within UEFI NVRAM variables that are accessible during the runtime phase of the system lifecycle.\nUnder normal operating conditions, sensitive authentication data should be stored in secure, volatile memory locations or protected non-volatile storage that is inaccessible to the OS-level runtime environment. In this specific implementation, the password hashes are stored in variables that lack the necessary attributes to prevent unauthorized read access by the operating system. Because these variables are marked for runtime access, they remain readable after the handoff from the firmware to the operating system loader, effectively exposing the secrets to the kernel or any process with sufficient privileges to interact with UEFI variables.\nThe attack flow proceeds as follows: First, an attacker with administrative or root privileges within the operating system interacts with the UEFI runtime services (e.g., using tools such as 'efivar' on Linux or the GetVariable API on Windows). Second, the attacker queries the specific variable GUIDs associated with SysPasswordDxe that contain the serialized password hash objects. Third, the driver fails to restrict access to these variables, returning the cleartext-equivalent password hashes to the requester. Finally, the attacker captures these hashes, which can then be subjected to offline brute-force or dictionary attacks to recover the original BIOS/Setup password.\nThe impact of this vulnerability is severe. Once the administrator password is recovered, the attacker can reconfigure UEFI settings, such as disabling Secure Boot, modifying boot orders to execute malicious bootloaders, or altering platform security policies. This allows for the installation of malicious rootkits or persistent firmware-level malware that survives OS reinstallation and disk encryption. The lack of proper access control on these UEFI variables essentially bypasses the intended hardware-root-of-trust security boundaries designed to protect the system configuration."
}