CVE-2026-32606 is a vulnerability in IncusOS, an immutable OS image designed to run Incus, affecting versions prior to 202603142010. The root cause lies in the default configuration of systemd-cryptenroll used via mkosi, which configures the TPM to release the LUKS encryption key based on PCR7 and PCR11 values. Critically, the PCR11 policy allows the TPM to release the key to the fully booted system rather than restricting it to the initrd phase of the signed kernel image (UKI). This misconfiguration enables an attacker with physical access to the machine to perform a root partition substitution attack. By replacing the original encrypted root partition with one controlled by the attacker, the system prompts for a recovery key at boot, which the attacker can supply. The system then boots from the attacker's root partition, which can include a systemd unit configured to run at startup. This unit operates in an environment where the TPM releases the encryption key for the real root disk, allowing the attacker to extract the immutable LUKS master key. With this key, the attacker can decrypt, modify, or exfiltrate data from the original root disk before restoring it to avoid detection. The attack does not require tampering with Secure Boot or the TPM state, as the bootloader and kernel measurements remain valid. The vulnerability exploits the GPT partition identifier-based root disk selection, facilitating the root partition swap. The patched IncusOS version 202603142010 introduces new PCR15 logic that updates TPM policies to bind keys more securely, preventing this attack vector. Because the LUKS key is immutable and not rotated automatically, any system suspected of physical compromise must undergo a full wipe and reinstallation to rotate keys and secure data. No alternative mitigations or workarounds are available besides updating to the fixed version.

This vulnerability poses a significant risk to the confidentiality, integrity, and availability of data on affected IncusOS systems. An attacker with physical access can bypass encryption protections without alerting the system owner or triggering Secure Boot or TPM state changes. By extracting the immutable LUKS volume key, the attacker gains full access to encrypted data, enabling data theft, unauthorized modification, or persistent backdoors. The stealthy nature of the attack, which leaves no trace after restoring the original root disk, complicates forensic detection and incident response. Organizations relying on IncusOS for secure, encrypted environments—especially in sensitive or high-security contexts—face potential data breaches and system compromise. The requirement for physical access limits remote exploitation but elevates risk in environments where devices may be physically accessible to adversaries, such as data centers, edge deployments, or shared facilities. The lack of known exploits in the wild currently reduces immediate threat but the high CVSS score (7.7) and ease of exploitation with physical access make timely patching critical to prevent future attacks.

The primary mitigation is to upgrade all affected IncusOS systems to version 202603142010 or later, which includes the corrected TPM PCR15 policy logic that securely binds LUKS keys and prevents this attack. Organizations should implement strict physical security controls to prevent unauthorized access to systems, including locked server rooms, surveillance, and tamper-evident seals. For systems suspected of physical compromise, a full system wipe and reinstallation is mandatory to rotate the LUKS volume key and eliminate any attacker persistence. Administrators should audit boot configurations and GPT partition identifiers to detect unauthorized root partition substitutions. Implementing monitoring for unexpected systemd units or unusual boot-time behaviors can help detect exploitation attempts. Additionally, consider integrating hardware security modules or enhanced TPM configurations that restrict key release policies more tightly. Regularly review and update system images and cryptographic policies to align with best practices. Finally, maintain an incident response plan that includes procedures for physical compromise scenarios and key rotation.