CVE-2026-12411 with a CVSS score of 8.4 is a broken access control vulnerability in the LXD container engine that enables cross-guest volume hijacking. The flaw affects versions of github.com/canonical/lxd from 0.0.0-20250721152936-fe86ceb2c3fa up to, but not including, 0.0.0-20260626085133-7cb96ac80a6d. The vulnerability exists within the instance device-update path, specifically the devLXDInstancePatchHandler, which fails to verify ownership when attaching custom storage volumes to a container. While the DevLXD storage API correctly enforces ownership checks for standard read, write, and delete operations, the device-attach mechanism bypasses these controls. An attacker with a valid DevLXD identity scoped to their own instance can exploit this by issuing a PATCH request to attach a disk device pointing to a custom volume owned by another tenant. This action mounts the foreign volume into the attacker's container, granting full read and write access to the victim's data. The attack requires the project to have security.devlxd.management.volumes enabled and does not require elevated privileges beyond standard instance editing rights. The business impact is severe, as it allows any guest in a shared project to compromise the confidentiality and integrity of other tenants' storage. Attackers can exfiltrate sensitive data or overwrite critical files, effectively breaking the isolation boundaries that secure multi-tenant LXD deployments rely upon.
The following reports contain further technical details:[/subscribe_to_unlock_form]
CVE-2026-12411 with a CVSS score of 8.4 is a broken access control vulnerability in the LXD container engine that enables cross-guest volume hijacking. The flaw affects versions of github.com/canonical/lxd from 0.0.0-20250721152936-fe86ceb2c3fa up to, but not including, 0.0.0-20260626085133-7cb96ac80a6d. The vulnerability exists within the instance device-update path, specifically the devLXDInstancePatchHandler, which fails to verify ownership when attaching custom storage volumes to a container. While the DevLXD storage API correctly enforces ownership checks for standard read, write, and delete operations, the device-attach mechanism bypasses these controls. An attacker with a valid DevLXD identity scoped to their own instance can exploit this by issuing a PATCH request to attach a disk device pointing to a custom volume owned by another tenant. This action mounts the foreign volume into the attacker's container, granting full read and write access to the victim's data. The attack requires the project to have security.devlxd.management.volumes enabled and does not require elevated privileges beyond standard instance editing rights. The business impact is severe, as it allows any guest in a shared project to compromise the confidentiality and integrity of other tenants' storage. Attackers can exfiltrate sensitive data or overwrite critical files, effectively breaking the isolation boundaries that secure multi-tenant LXD deployments rely upon.
The following reports contain further technical details:[emaillocker id="1283"]
[/emaillocker]