CVE-2026-12411: LXD Container Escape via Broken Access Control in Device Handler

Technical summary

The vulnerability exists in LXD's device PATCH request handler within the devLXDInstancePatchHandler component. The flaw stems from insufficient authorization checks (CWE-862) when processing device management requests over the /dev/lxd socket interface. When security.devlxd.management.volumes is enabled, the handler fails to properly validate that a requesting guest container has permission to access storage volumes outside its own context. This allows an authenticated container to craft a malicious PATCH request that references another container's custom storage volume, bypassing the intended access control boundaries. The vulnerability is rooted in broken access control logic (CWE-639) that does not properly enforce per-container volume permissions.

Business impact

This vulnerability undermines the fundamental security model of containerized deployments. In multi-tenant environments using LXD, a compromised or untrusted container can read sensitive data from other containers' storage volumes and corrupt or destroy data belonging to adjacent workloads. For organizations using LXD to isolate customer workloads or separate production and development environments, this creates a serious cross-container data breach and integrity risk. The ability to overwrite another container's storage could enable lateral movement, privilege escalation through persistent backdoors, or denial of service through data destruction. Affected deployments must assume guest isolation is compromised until patched.

Affected systems

Canonical LXD is affected by this vulnerability. The flaw is only exploitable when the security.devlxd.management.volumes configuration option is enabled; the default state of this setting should be verified against the vendor advisory. Any LXD deployment running a vulnerable version with this feature enabled is at risk. Affected systems are those hosting multiple containers with varying trust levels or multi-tenant scenarios where guest isolation is a security requirement.

Exploitability

Exploitation requires local access to a container on the target LXD host and does not require elevated privileges within that container (PR:L in the CVSS vector). The attack is straightforward—an attacker submits a crafted device PATCH request through the /dev/lxd interface—and does not depend on timing, user interaction, or complex environmental configuration (AC:L, UI:N). No exploit code has been added to public vulnerability databases. The scope is changed (S:C), meaning the attack can impact confidentiality and integrity of sibling containers beyond the attacker's container. This is a local attack with high impact but moderate effort to execute for an attacker already inside a container.

Remediation

Upgrade Canonical LXD to a patched version that fixes the authorization logic in devLXDInstancePatchHandler. Consult the official Canonical LXD security advisory for the specific patch version and release notes. As an interim mitigation, disable the security.devlxd.management.volumes feature in LXD configurations if it is not required for your workload. This can be done via LXD profile or instance-level configuration settings. Review container isolation policies and consider restricting which containers run on shared LXD hosts until patching is complete.

Patch guidance

Canonical will provide a patch addressing the broken access control logic in the devLXDInstancePatchHandler. Administrators should monitor Canonical's security announcements and LXD release notes for the fixed version. Patches should be applied to all LXD hosts in your environment, with particular urgency for systems running untrusted or multi-tenant workloads. Test patches in a non-production environment first to ensure compatibility with your container configurations. If security.devlxd.management.volumes is not required, consider disabling it before patching as an additional defense layer.

Detection guidance

Monitor LXD daemon logs for unusual device PATCH requests originating from guest containers, particularly those targeting volumes not belonging to the requesting container. Look for patterns of repeated failed or suspicious device management API calls through /dev/lxd. Network-based detection is limited due to the local nature of the attack, but host-based logging and container audit trails may reveal exploitation attempts. Check LXD configurations to identify which instances have security.devlxd.management.volumes enabled. Implement container runtime monitoring to detect processes within containers attempting to access /dev/lxd with suspicious parameters or frequency.

Why prioritize this

This vulnerability merits high priority patching due to its CVSS 8.4 (HIGH) score, the severity of breaking container isolation in multi-tenant environments, and the low barrier to exploitation for an attacker already inside a container. The change in scope (impacting other containers) and high impact on confidentiality and integrity elevate risk beyond a single-container compromise. Organizations running LXD with untrusted or semi-trusted workloads should treat this as critical. Even though the flaw requires local container access, the ease of exploitation and the fundamental nature of the breach (container isolation) justify urgent remediation.

Risk score, explained

The CVSS 3.1 score of 8.4 reflects the combination of local attack vector (AV:L), low attack complexity (AC:L), low privilege requirement (PR:L), no user interaction (UI:N), and high impact on confidentiality and integrity across container boundaries (S:C, C:H, I:H). The absence of availability impact (A:N) prevents a critical rating, but the score correctly captures the serious nature of a flaw that enables guest-to-guest container escape and data theft. The vulnerability does not appear on CISA's Known Exploited Vulnerabilities (KEV) list, suggesting active exploitation in the wild has not yet been confirmed, though organizations should assume capability exists once the advisory is public.

Frequently asked questions