Loading vulnerability…
CVE-2026-32606 affects IncusOS prior to version 202603142010. The issue stems from the default systemd-cryptenroll configuration used by IncusOS through mkosi for TPM-bound LUKS unlocking. In the vulnerable configuration, the TPM releases the LUKS key when PCR7 matches the expected Secure Boot state and the PCR11 policy matches, but the PCR11 policy is too permissive because it allows key release to the fully booted system rather than restricting access to the initrd portion of the signed UKI. An attacker with physical access can replace the legitimate encrypted root partition with an attacker-controlled root partition. Because the initrd selects the root disk based on GPT partition identifiers, the substituted partition can be accepted during boot. The attacker can configure that replacement root partition to request a recovery key they control, allowing the system to boot normally with Secure Boot still enabled and the expected bootloader and UKI measured. Once the attacker-controlled root filesystem is booted, a systemd unit started at boot can execute in an environment where the TPM will still release the LUKS key for the original encrypted root disk. The attacker can then retrieve the real disk's LUKS volume key and subsequently decrypt, access, or modify the original root disk offline, without needing to tamper with Secure Boot state or the kernel image.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a small standalone proof-of-concept exploit for CVE-2026-32606, demonstrating bypass of TPM2-bound LUKS disk protection on Linux systems, especially an IncusOS VM example. The repo contains 8 files: documentation (README.md, COPYING), a systemd unit (attack.service), a Go payload under exploit/, and two Bash orchestration scripts (prepare.sh and restore.sh). The core exploit logic is in exploit/main.go. That Go program writes a hardcoded password (H@xOr!!) to /tmp/key, invokes systemd-cryptenroll with --unlock-tpm2-device auto --password /dev/sda10 to add an attacker-controlled password to the TPM-unlocked LUKS device, then runs cryptsetup --dump-volume-key --key-file /tmp/key luksDump /dev/sda10 and prints the resulting volume key. In effect, once the target boots into a TPM-approved state, the implanted service can authorize itself, add a known credential, and extract the LUKS master/volume key. The attack workflow is implemented by prepare.sh. It assumes root access on the attacker side and a target disk image at /var/lib/incus/virtual-machines/test-incus-os/root.img. The script compiles the Go binary, backs up the GPT, copies the original EFI System Partition contents, deletes and recreates partitions, and creates attacker-controlled ext4 partitions intended as malicious /srv and root filesystems. It then copies the compiled exploit binary into the malicious /srv partition and installs attack.service into /etc/systemd/system/ on the malicious root partition. The service executes /srv/exploit at boot after incus-osd.service. The restore.sh script is an anti-forensics/cleanup helper. It restores the original GPT from backup, reformats the ESP, and copies back the saved ESP contents, aiming to remove evidence after the attacker has obtained the LUKS volume key. There are no network callbacks, C2 endpoints, or remote services in the code. The exploit is local/physical in nature and relies on offline disk image manipulation plus subsequent boot-time execution. Its main capability is credential enrollment plus extraction of the LUKS volume key, not remote code execution. Because it includes a working payload and automation but uses hardcoded values and environment assumptions, it is best classified as OPERATIONAL rather than fully weaponized.
3 sources tracked across advisories and community write-ups. News coverage will land here when it surfaces.
No news coverage yet. Advisories and community discussion only.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.