gibmat/cve-2026-32606-pocProof-of-concept demonstrating bypass of TPM-bound LUKS disk encryption on Linux systems, extracting volume keys via custom root filesystem attack.
This repo has simple proof-of-concept code exploiting a common weakness initially described over a year ago at https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock/. While it specifically targets IncusOS, the attack is pretty generic against most modern Linux systems.
If you're binding your LUKS encryption to a TPM, make sure you also set a PIN for the TPM.
This is a quick-n-dirty PoC. It's not fully polished, and there are some rough edges. There's no support, and I don't plan on any further development.
I, like most people, assumed that setting up LUKS disk encryption bound to my laptop's TPM chip would be secure and prevent an attacker from being able to extract the LUKS volume key (aka, master key). Turns out, it's almost depressingly easy to do and leave no trace of the attack.
Yup, the problem is an attacker can provide a custom root file system, and after your system boots the TPM will be in a known "good" state where it will happily unlock your LUKS volume. The attacker can then do whatever they want, and easily cover any evidence of the attack.
But a prepared attacker literally only needs to have your computer in their possession for a couple of minutes and you're pwned. Leave your laptop in the hotel room while going out to dinner? What about a security checkpoint where you're pulled aside for questioning? Yup, this isn't good.
The script ./prepare.sh runs the steps necessary to compromise the target VM. The same steps can easily
be run against a real hard drive that's been temporarily removed from its normal housing.
The actual "exploit" will extract the original LUKS volume key, which can be seen by looking at the journal
log for attack.service. Many variations on this attack are possible.
Run ./restore.sh to wipe away all evidence of your deeds while you walk away with the LUKS volume key of
your victim.
