Critical HP ThinPro TPM Flaw Exposes LUKS Disk Encryption Keys

Key Takeaways

• A critical boot-chain vulnerability exists in HP ThinPro 8 and 9 operating systems.
• The flaw allows attackers with physical access to HP thin clients to extract LUKS disk encryption keys.
• The issue stems from incomplete Trusted Platform Module (TPM) measurements during the boot process.
• HP has acknowledged the vulnerability and is reportedly working on a fix, though no patch is publicly available yet.

A cybersecurity researcher has unveiled a significant boot-chain vulnerability impacting HP ThinPro versions 8 and 9. This flaw could enable threat actors with physical access to an HP thin client to compromise its LUKS disk encryption, thereby extracting the root partition’s decryption key.

The vulnerability specifically targets HP thin clients where the operating system’s root partition is secured by LUKS2 encryption, with the decryption key intended to be sealed within the device’s Trusted Platform Module (TPM). While this security architecture aims to prevent unauthorized data access from removed storage drives, the researcher discovered that the TPM policy fails to comprehensively validate all software components loaded during the boot sequence.

HP ThinPro utilizes a proprietary utility, hptc-tpm-tool, to retrieve the LUKS key from the TPM during system startup. An initramfs script, named unseal_key, then requests this key and supplies it directly to cryptsetup, facilitating the unlocking of the encrypted root partition.

Incomplete TPM Measurements Expose Keys

The core of the problem lies in the limited scope of the TPM key sealing process. The key is reportedly sealed only to PCR 0, PCR 2, and PCR 4. These Platform Configuration Registers (PCRs) are designed to measure critical boot components such as the BIOS firmware, option ROMs or UEFI drivers, and the GRUB bootloader binary, respectively.

Crucially, the TPM’s measurement process does not extend to GRUB configuration commands, the Linux kernel, or the initramfs that GRUB loads. This omission creates a critical blind spot in the security chain.

While an attacker cannot simply substitute the GRUB binary without altering PCR 4, which would prevent the TPM from releasing the key, they can modify the unencrypted initramfs. This includes the shell script responsible for unsealing the key, without triggering any changes to the PCR values that the TPM checks.

According to the AmberWolf disclosure, a maliciously altered initramfs can be configured to copy the retrieved LUKS key to the unencrypted BOOT partition before the regular startup process continues. During the subsequent boot, the TPM perceives the system as trusted because the firmware and GRUB measurements remain unaltered. The device then boots normally, while the attacker can later retrieve the exposed key from the drive at their leisure.

Attack Vector and Impact

This attack necessitates physical access to the device and the ability to remove or modify the M.2 SATA storage drive. The researcher emphasized that no specialized hardware, soldering, or advanced reverse engineering skills are required to execute this exploit.

The vulnerability was successfully confirmed on an HP t530 thin client running ThinPro 8.1.0 build 22, and an HP t540 thin client operating ThinPro 9.0.0 build 15.

Once the raw 32-byte LUKS key is obtained, an attacker gains the capability to decrypt the protected partition, thereby accessing sensitive data such as device configuration, certificate stores, stored credentials, and password hashes. This poses significant risks for organizations, particularly when thin clients are returned, lost, resold, or disposed of without proper secure data sanitization of the internal drive.

The flaw has been assigned a CVSS 3.1 score of 6.1, categorizing it as a Medium severity vulnerability. This rating reflects the requirement for physical access, low attack complexity, and high impact on both confidentiality and integrity.

The researcher also noted that Secure Boot is disabled by default on the affected systems. While enabling Secure Boot and setting a BIOS password might increase the difficulty for an attacker, these measures may only delay rather than completely mitigate the underlying PCR measurement deficiency.

The issue was reported to HP PSIRT on February 22, 2026. HP has reportedly confirmed the vulnerability and indicated that a fix is undergoing quality assurance. However, at the time of the public disclosure, no official security bulletin, CVE identifier, or deployed patch was available.

What You Should Do

• Organizations employing HP ThinPro with full-disk encryption should consider any devices outside their direct physical control as potentially compromised until HP releases a comprehensive remediation.
• Implement robust physical security measures for all HP thin clients to prevent unauthorized access.
• Regularly monitor HP’s official security advisories and support channels for updates regarding a patch or further mitigation guidance.
• Consider implementing additional layers of encryption or access control for critical data stored on thin clients, where feasible, as a temporary measure.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.