VulnerabilityPublished 18 Mar 2026

CVE-2026-32606: lxc incus-os · Insufficiently Protected Credentials

Affects lxc incus-osSource CVE Database V5

Compare

Not known to be exploited · CVSS 7.7 High : upgrade to 202603142010 soon.

Data as of 30 Oct 2026, 06:59 UTC

CVSS 3.1 base score

7.7High

How severe the flaw is on the 0–10 CVSS scale.

EPSS: 0.1% chance of exploitation in 30 days – higher than 3% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch: Available – fixed in 202603142010

CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Attack Vector: Physical
Attack Complexity: Low
Privileges Required: None
User Interaction: None
Scope: Changed
Confidentiality: High
Integrity: High
Availability: High

Bold values are the worst case: easiest to exploit or largest impact.

Attack Vector: Physical: The attack requires the attacker to physically touch or manipulate the vulnerable component. Physical interaction may be brief or persistent.
Attack Complexity: Low: Specialized access conditions or extenuating circumstances do not exist. An attacker can expect repeatable success against the vulnerable component.
Privileges Required: None: The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files to carry out an attack.
User Interaction: None: The vulnerable system can be exploited without any interaction from any user.
Scope: Changed: An exploited vulnerability can affect resources beyond the security scope managed by the security authority of the vulnerable component. In this case, the vulnerable component and the impacted component are different and managed by different security authorities.
Confidentiality: High: There is total loss of confidentiality, resulting in all resources within the impacted component being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact.
Integrity: High: There is a total loss of integrity, or a complete loss of protection. For example, the attacker is able to modify any/all files protected by the impacted component. Alternatively, only some files can be modified, but malicious modification would present a direct, serious consequence to the impacted component.
Availability: High: There is total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the impacted component (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable).

Definitions: FIRST CVSS v3.1 specification.

Exploitation evidence

Disclosed: evidence found.
CVE published 18 Mar 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: evidence found.
Public exploit code: GitHub proofs of concept
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), GitHub proofs of concept, the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponized: A Metasploit exploit module or Exploit-DB entry exists (Metasploit scanner modules do not count), or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade lxc/incus-os to 202603142010.

Affected software

Product	Affected	Fixed in
lxcincus-os	Affected =< 202603142010	Fixed in–
GitHublxc/incus-os`pkg:github/lxc/incus-os`Other threats	Affected <202603142010	Fixed in 202603142010

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

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.

Description

IncusOS is an immutable OS image dedicated to running Incus. Prior to 202603142010, the default configuration of systemd-cryptenroll as used by IncusOS through mkosi allows for an attacker with physical access to the machine to access the encrypted data without requiring any interaction by the system's owner or any tampering of Secure Boot state or kernel (UKI) boot image. That's because in this configuration, the LUKS key is made available by the TPM so long as the system has the expected PCR7 value and the PCR11 policy matches. That default PCR11 policy importantly allows for the TPM to release the key to the booted system rather than just from the initrd part of the signed kernel image (UKI). The attack relies on the attacker being able to substitute the original encrypted root partition for one that they control. By doing so, the system will prompt for a recovery key on boot, which the attacker has defined and can provide, before booting the system using the attacker's root partition rather than the system's original one. The attacker only needs to put a systemd unit starting on system boot within their root partition to have the system run that logic on boot. That unit will then run in an environment where the TPM will allow for the retrieval of the encryption key of the real root disk, allowing the attacker to steal the LUKS volume key (immutable master key) and then use it against the real root disk, altering it or getting data out before putting the disk back the way it was and returning the system without a trace of this attack having happened. This is all possible because the system will have still booted with Secure Boot enabled, will have measured and ran the expected bootloader and kernel image (UKI). The initrd selects the root disk based on GPT partition identifiers making it possible to easily substitute the real root disk for an attacker controlled one. This doesn't lead to any change in the TPM state and therefore allows for retrieval of the LUKS key by the attacker through a boot time systemd unit on their alternative root partition. IncusOS version 202603142010 (2026/03/14 20:10 UTC) includes the new PCR15 logic and will automatically update the TPM policy on boot. Anyone suspecting that their system may have been physically accessed while shut down should perform a full system wipe and reinstallation as only that will rotate the LUKS volume key and prevent subsequent access to the encrypted data should the system have been previously compromised. There are no known workarounds other than updating to a version with corrected logic which will automatically rebind the LUKS keys to the new set of TPM registers and prevent this from being exploited.

Impact

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.

Summary

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.

CWE-522Insufficiently Protected Credentials (opens in a new tab)
Class weaknessOWASP Top 10 A06:2025: Insecure Design (opens in a new tab)
The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.
Architecture and Design
Use an appropriate security mechanism to protect the credentials.
Architecture and Design
Make appropriate use of cryptography to protect the credentials.
Implementation
Use industry standards to protect the credentials (e.g. LDAP, keystore, etc.).
OWASP Cheat Sheets
Secure Design Principles (opens in a new tab)
OWASP ASVS 4.0.3
V2.10.3 (opens in a new tab)
V2.8.5 (opens in a new tab)
V2.8.4 (opens in a new tab)
Attack patterns
Session Sidejacking (opens in a new tab)
Signature Spoofing by Key Theft (opens in a new tab)
Password Recovery Exploitation (opens in a new tab)
Kerberoasting (opens in a new tab)
Modify Existing Service (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

References

Community reviews

Loading reviews…

Exploitation evidence

What to do

Affected software

Description

AI analysisMachine-generated, updated 18 Mar 2026, 16:27 UTC

Public exploits and detectionGitHub proofs of concept

WeaknessesCWE-522

Technical details

References

Community reviews

Related threats