Incus CVE-2026-33945

Incus versions prior to 6.23.0 with systemd credentials enabled for containers. Requires authenticated attacker with local container management privileges to set malicious configuration keys containing path traversal sequences (e.g., systemd.credential.../../../../../../root/.bashrc) to write arbitrary files outside the credentials directory.

This vulnerability presents a nuanced risk profile requiring careful analysis of multiple signals. The CVSS 9.9 Critical score reflects maximum impact: network-accessible (AV:N), low complexity (AC:L), scope change indicating container escape (S:C), and complete compromise of confidentiality, integrity, and availability (C:H/I:H/A:H). However, the PR:L requirement means attackers need low-privileged authenticated access to the Incus management interface, not just network connectivity. The EPSS score of 0.06% (18th percentile) suggests security researchers assess real-world exploitation probability as very low, potentially because Incus deployments are less common than Docker/Kubernetes, and the attack requires pre-existing container management credentials. No public exploit identified at time of analysis, and absence from CISA KEV confirms no observed active exploitation. SSVC factors favor monitoring over immediate emergency response: exploitation status is none, technical impact is total (host compromise from container), but the authentication barrier and specialized target environment reduce automatability. The primary risk scenario involves malicious insiders or compromised accounts with legitimate container provisioning access, rather than opportunistic mass exploitation. Organizations running Incus in multi-tenant environments or where container users have configuration API access should prioritize patching, while those with strict access controls around container creation may treat this as high severity rather than critical emergency.

An attacker with authenticated low-privilege access to the Incus management API creates a new container or modifies an existing container configuration, setting a systemd credential key like 'systemd.credential.../../../../../../etc/cron.d/malicious' with payload content containing a cron job specification. When Incus processes this configuration, it writes the attacker-controlled content to /etc/cron.d/malicious on the host system instead of the intended container credentials directory, achieving container escape. The malicious cron job executes with root privileges on the host at the next scheduled interval, granting the attacker full host system compromise from an initially containerized position. Alternatively, the attacker could target critical system files like /root/.ssh/authorized_keys or systemd unit files to establish persistence or /etc/shadow for credential manipulation, or trigger denial of service by overwriting essential system binaries or configuration files.