Canonical LXD CVE-2026-12411

The host must have security.devlxd.management.volumes explicitly enabled - this is a non-default configuration setting and is the single most important prerequisite. The attacker must already control a guest instance on that host and be able to send device PATCH requests to the local /dev/lxd management socket, and a victim guest with a custom storage volume must exist on the same host to be targeted. Exploitation is limited by all of these factors: no valid path exists on hosts that leave devLXD volume management disabled, the attacker needs an existing foothold as a guest (PR:L, not unauthenticated), and SSVC rates the attack as not automatable, so it is targeted rather than mass-scalable.

Signals conflict and must be weighed carefully. The CVSS 9.6 is driven by S:C (crossing from the attacker's guest to a victim guest's data) plus C:H/I:H, and the SSVC 'total' technical impact agrees the confidentiality/integrity damage is severe. However, several signals temper real-world priority: EPSS is only 0.11% (1st percentile), the vulnerability is NOT in CISA KEV, SSVC marks it Automatable=no (each target needs the right conditions rather than mass, hands-off exploitation), and exploitation depends on a non-default setting (security.devlxd.management.volumes) that most deployments do not enable. There is also a vector discrepancy worth verifying: Canonical scored AV:N, yet the attack is performed from inside a guest against a local /dev/lxd Unix socket, which is more consistent with AV:L - verify with the vendor advisory before treating this as a remotely reachable network flaw. Net: a genuinely high-impact isolation break for the subset of hosts that opt into devLXD volume management, but not a broad, spray-and-pray internet threat.

An attacker who controls one guest instance on a shared LXD host (for example a low-trust tenant container) crafts a device PATCH request to /dev/lxd referencing another tenant's custom storage volume identifier. Because the handler does not check ownership, the volume is mounted into the attacker's guest, allowing it to read confidential data and overwrite the victim's data. SSVC rates a proof-of-concept as available; the attack requires only local low-privilege access from within a guest, though the target host must have security.devlxd.management.volumes enabled.