CVE-2026-32606: IncusOS Privilege Escalation Vulnerability

CVE-2026-32606 Overview

CVE-2026-32606 is a Secure Boot Bypass vulnerability affecting IncusOS, an immutable operating system image designed for running Incus containerization workloads. The vulnerability exists in the default configuration of systemd-cryptenroll as used by IncusOS through mkosi, which allows an attacker with physical access to the machine to access encrypted data without requiring any interaction by the system owner or tampering with Secure Boot state or the kernel (UKI) boot image.

The flaw stems from the TPM policy configuration that releases the LUKS encryption key based solely on expected PCR7 and PCR11 values. This default PCR11 policy critically allows the TPM to release the key to the booted system rather than restricting it to the initrd portion of the signed kernel image.

Critical Impact

An attacker with physical access can extract the immutable LUKS volume master key, enabling unauthorized decryption, data exfiltration, and system tampering without leaving forensic traces.

Affected Products

• IncusOS versions prior to 202603142010 (2026/03/14 20:10 UTC)
• Systems using systemd-cryptenroll with default mkosi TPM configuration
• Environments relying on TPM-based LUKS encryption with PCR7/PCR11 binding only

Discovery Timeline

• 2026-03-14 - IncusOS version 202603142010 released with PCR15 binding fix
• 2026-03-18 - CVE-2026-32606 published to NVD
• 2026-03-18 - Last updated in NVD database

Technical Details for CVE-2026-32606

Vulnerability Analysis

This vulnerability represents a fundamental weakness in TPM-based disk encryption implementations that rely solely on PCR7 and PCR11 measurements for key release policies. The attack exploits the fact that the initrd component of the UKI selects the root disk based on GPT partition identifiers, making it trivial for an attacker to substitute the legitimate encrypted root partition with a malicious one they control.

When the system boots with the attacker's substituted root partition, it maintains identical TPM state because the bootloader and kernel image (UKI) remain unmodified with Secure Boot enabled. The system prompts for a recovery key—which the attacker has predefined on their malicious partition—and proceeds to boot using the attacker-controlled root filesystem.

Once booted, the attacker can place a systemd unit file within their malicious root partition that executes automatically on system startup. This unit runs in an environment where the TPM will release the encryption key for the original root disk, allowing complete extraction of the LUKS volume key.

Root Cause

The root cause is classified as CWE-522 (Insufficiently Protected Credentials). The TPM policy binding configuration in systemd-cryptenroll as deployed by IncusOS did not include PCR15 in its measurement requirements. PCR15 is specifically designed to be extended when a root LUKS volume is successfully opened in the initrd, creating a state that cannot be reset without a full system reboot.

Without PCR15 binding, the TPM releases encryption keys based solely on:

• PCR7: Secure Boot policy measurements
• PCR11: Unified Kernel Image (UKI) measurements

This configuration fails to differentiate between legitimate initrd key retrieval and post-boot key retrieval attempts from a potentially compromised userspace.

Attack Vector

The attack requires physical access to the target system and follows this exploitation chain:

1. Partition Substitution: The attacker removes or modifies the original encrypted root partition and replaces it with a malicious partition using matching GPT partition identifiers
2. Recovery Key Setup: The attacker configures their malicious partition with a known recovery key
3. System Boot: The victim system boots normally—Secure Boot validates the UKI, TPM state remains pristine
4. Recovery Key Entry: The system prompts for recovery key (original partition missing); attacker provides their predefined key
5. Malicious Code Execution: A pre-configured systemd unit on the attacker's root partition executes with TPM in a valid state
6. Key Extraction: The malicious unit retrieves the LUKS encryption key from the TPM and extracts the volume master key
7. Cover Tracks: Attacker restores original partition configuration, leaving no forensic evidence

The fix introduces PCR15 binding logic that ensures the TPM only releases encryption keys during the initrd phase. The security patch adds verification for PCR15 binding:

// Check if the root and swap partitions include a binding on PCR15. If not, update the LUKS bindings before proceeding.
// This is required to counter the attack described at https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock/.
//
// Binding to exact values of PCRs 4+7 and a PCR11 policy are insufficient when an attacker has physical access to the system
// and can create a malicious root partition. Because the system will boot with an unmodified UKI and SecureBoot/TPM state,
// after the system exits the initrd IncusOS will behave like it's a first boot, but more critically the TPM will be in a
// known "good" state and happily release its encryption key used by LUKS allowing the attacker to trivially extract the
// LUKS volume key. They can then undo their malicious changes to the disk, and IncusOS wlll have no idea an attack occurred
// while the attacker now can decrypt the LUKS volumes at any time to exfiltrate data, mess with the system, etc.
//
// We add a binding to an empty PCR15. This PCR is extended when a root LUKS volume is successfully opened in the initrd, so the
// only time the TPM state could automatically unlock things for us is at the beginning of the initrd. After that point, PCR15
// will have a different value which cannot be reset, rendering the attack impossible.
//
// Performing the check and PCR binding update here catches both fresh installs as well as existing deployments. In either case,
// the TPM state will allow a single re-bind, after which it will only work in the initrd. At some point after September 2026
// we can move this logic into the recovery key generation block above so only fresh installs are inspected. systemd v259 did
// add a TPM2PCRs= option to systemd-repart which would also make life easier.
luksVolumes, err := util.GetLUKSVolumePartitions(ctx)
if err != nil {
	return err
}

isBoundPCR15, err := storage.LUKSBoundToPCR(ctx, luksVolumes["root"], 15)
if err != nil {
	return err
}

Source: GitHub Commit for Incus OS

Detection Methods for CVE-2026-32606

Indicators of Compromise

• Unexpected system recovery key prompts during boot sequences
• Evidence of GPT partition table modifications or partition UUID changes
• Unusual systemd unit files in the root filesystem that were not part of the original deployment
• TPM event log entries indicating key release events outside of expected initrd execution context
• Physical tampering indicators on server hardware or storage devices

Detection Strategies

• Monitor TPM event logs for anomalous key release patterns, particularly those occurring after the initrd phase completes
• Implement hardware intrusion detection systems that alert on physical access to servers
• Configure centralized logging for boot events and compare against known-good baseline boot sequences
• Audit LUKS key slot configurations to verify PCR15 binding is present on all encrypted volumes

Monitoring Recommendations

• Enable TPM attestation logging and forward events to SIEM for correlation analysis
• Implement boot integrity monitoring that validates partition UUIDs and GPT structures against known configurations
• Deploy physical security monitoring with tamper-evident seals on server chassis
• Configure alerts for any recovery key usage events, as these may indicate compromise attempts

How to Mitigate CVE-2026-32606

Immediate Actions Required

• Update IncusOS to version 202603142010 or later, which includes the PCR15 binding logic and automatically updates TPM policies on boot
• If physical compromise is suspected, perform a complete system wipe and reinstallation to rotate the LUKS volume key
• Audit all IncusOS deployments to verify they are running the patched version
• Review physical security controls for systems running IncusOS with TPM-based encryption

Patch Information

The fix is included in IncusOS version 202603142010 (2026/03/14 20:10 UTC). The patch adds PCR15 binding to the TPM policy, ensuring that LUKS encryption keys can only be retrieved during the initrd phase of boot. Upon first boot after updating, the system automatically rebinds LUKS keys to include PCR15, preventing the attack vector from being exploited.

For detailed technical information, refer to the GitHub Security Advisory GHSA-wj2j-qwcf-cfcc and the GitHub Pull Request for Incus OS.

Additional technical background on this class of TPM encryption bypass is available in the Oddlama Blog on Disk Encryption.

Workarounds

• There are no known workarounds other than updating to a patched version
• Implement strict physical access controls to limit exposure while awaiting patching
• Consider temporarily disabling automatic TPM-based unlocking and requiring manual key entry for critical systems
• Monitor for and immediately investigate any unexpected recovery key prompts

# Verify IncusOS version includes PCR15 fix
incus-osd --version

# Check if LUKS volumes are bound to PCR15 (post-patch)
systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=? /dev/disk/by-partlabel/root

# After updating, verify automatic TPM policy rebinding occurred by checking journal
journalctl -u incus-osd | grep -i "PCR15"