CVE-2026-12411 in lxd
Summary
by MITRE • 06/26/2026
Broken Access Control in the devLXDInstancePatchHandler component of Canonical LXD allows an untrusted guest to mount, read, and overwrite another guest's custom storage volume via a crafted device PATCH request over /dev/lxd when security.devlxd.management.volumes is enabled.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 06/26/2026
The vulnerability identified in Canonical LXD represents a critical broken access control flaw within the devLXDInstancePatchHandler component that enables unauthorized guest users to manipulate storage volumes belonging to other guests. This issue manifests specifically when the security.devlxd.management.volumes configuration parameter is enabled, creating a privilege escalation pathway that violates fundamental security principles of isolation and resource protection.
The technical exploitation occurs through a crafted device PATCH request sent to the /dev/lxd interface, which allows an untrusted guest to mount, read, and overwrite custom storage volumes owned by different guest instances. This vulnerability stems from insufficient input validation and access control checks within the device management handler, enabling malicious actors to bypass normal security boundaries that should separate guest environments. The flaw operates at the kernel level where device management interfaces are exposed to guest operating systems, creating an attack surface that directly undermines the containerization security model.
From an operational impact perspective, this vulnerability compromises the fundamental isolation guarantees that containerized environments rely upon for security. An attacker with access to a single guest instance can potentially access sensitive data belonging to other guests, perform unauthorized data modifications, and potentially escalate privileges within the shared infrastructure. The attack vector is particularly concerning because it requires minimal privileges from the attacking guest, making it accessible to low-privilege users who should normally be restricted from accessing other containers' resources. This breach of isolation can lead to data leakage, integrity compromise, and potential lateral movement within multi-tenant environments.
The vulnerability maps directly to CWE-284 which describes improper access control in software systems, specifically targeting the weakness where insufficient controls allow unauthorized access to protected resources. According to ATT&CK framework, this represents a privilege escalation technique under T1068 and potentially falls under T1566 for initial access through compromised guest environments. The exploitation pattern aligns with container escape methodologies that target hypervisor or daemon interfaces, leveraging exposed management APIs to gain unauthorized access to underlying storage resources.
Mitigation strategies should focus on immediate configuration changes including disabling the security.devlxd.management.volumes parameter when not required, implementing strict network segmentation between guest instances, and applying mandatory access controls through kernel security modules. Organizations should also consider deploying intrusion detection systems monitoring for anomalous device management requests and implement regular security audits of container configurations. The most effective long-term solution involves upgrading to patched versions of LXD where proper access controls have been implemented to validate all device management requests against the requesting guest's authorized resource boundaries, ensuring that each guest can only manipulate its own storage volumes regardless of the management interface exposure level.
The vulnerability demonstrates how seemingly benign configuration options can create dangerous attack vectors when combined with insufficient access validation mechanisms. Security practitioners should treat this as a high-priority issue requiring immediate remediation in production environments and implement comprehensive monitoring to detect potential exploitation attempts. Regular security assessments of containerized environments are essential to identify similar misconfigurations that could enable privilege escalation and data compromise across virtualized workloads.