Canonical LXD CVE-2026-9640

Exploitation requires three concrete conditions drawn from the description: (1) LXD must be deployed as a restricted multi-tenant environment with project-restriction policies in force - single-tenant or unrestricted installs are not affected; (2) the attacker must already hold an authenticated project operator account in such a restricted project (PR:H), so this is not anonymous; and (3) the attacker must be able to import an instance backup and restore a snapshot, with the backup maliciously crafted to embed restricted configuration keys inside a snapshot definition. Exploitation is limited to these restricted-project deployments and to the createFromBackup/snapshot-restore code path, and the final step of gaining host root requires actually starting the modified instance after restore.

The vendor CVSS 3.1 vector (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H, base 7.2 High) reflects a network-reachable LXD API, low attack complexity, and full host compromise, but is gated behind high privileges (an existing project operator account) and, critically, a non-default deployment: this is only exploitable where LXD is configured for restricted multi-tenant projects. No EPSS score was provided in the input and the CVE is not in CISA KEV, so there is no evidence of active or widespread exploitation; treat the AV:N as 'reachable by anyone with an operator token,' not anonymous internet exposure. One signal to flag: the vendor scored scope unchanged (S:U) even though the impact is escaping a confined project to host root, which is arguably a scope change - defenders should treat the real-world impact as full host takeover regardless. This is a genuine priority for organizations running LXD as a multi-tenant container host (the threat model it is sold against), and low priority for single-tenant LXD installs where no restricted projects exist.

A tenant operator on a shared LXD host crafts an instance backup whose snapshot definition contains restricted configuration keys (for example security/privilege or restricted volatile keys) that project policy would normally reject. They import the backup into their restricted project and restore the snapshot; LXD applies the restricted keys to the live instance without policy validation, and starting that instance yields root on the underlying host. No public proof-of-concept is identified at time of analysis, and the low attack complexity (AC:L) means the only real barrier is already holding an operator account.