External risk intelligence

LXD Broken Access Control Allows Guest Storage Manipulation

CVE advisorySeverity: CRITICAL (CVSS 9.6)

CVE-2026-12411

The vulnerability exists within the devLXDInstancePatchHandler component, which communicates via a local socket interface (/dev/lxd) inside the guest environment. This interface is inherently internal to the container lifecycle and requires local guest access to interact, making it not reachable from the public internet in typical deployments.

Canonical Lxd

6.6 to before 6.9

Halo Surface Signal: 1 out of 5 — much less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A critical vulnerability has been identified in the Canonical LXD component, specifically within its device management. This issue could allow an unauthorized user within a virtual environment to access and modify the storage volumes of other virtual environments sharing the same LXD instance, provided a specific security setting is enabled. The primary concern at this stage is to confirm if this specific configuration is in use within your environment.

Access control flaw allows unauthorized storage access.
Matters if custom storage volumes are in use.
Confirm relevance and exposure to affected systems.

Attack Path

How an attacker could exploit the issue

An attacker who has already gained access to one LXD guest can exploit this vulnerability by sending a specially crafted device PATCH request. This request targets the devLXDInstancePatchHandler component over the /dev/lxd interface, provided that security.devlxd.management.volumes is enabled. Successful exploitation allows the attacker to mount, read, and overwrite another guest's storage volumes, potentially leading to data compromise and unauthorized modification.

Requires existing guest access.
Triggered by a malicious device PATCH request.
Risk of unauthorized storage access and modification.

Live Threat

Current exploitation, exposure, and threat context

When the `security.devlxd.management.volumes` setting is enabled, an attacker within a guest environment could potentially access, read, or modify the storage volumes of other guests. This could occur through a specially crafted device PATCH request sent to the `/dev/lxd` interface.

Guest storage volumes.
Crafted PATCH request to `/dev/lxd`.
Unauthorized access to other guests.

Operational Fix

Recommended remediation, mitigation, and detection steps

The direct impact of this vulnerability requires an untrusted guest to already have access to the host system and specifically to the `/dev/lxd` interface with `security.devlxd.management.volumes` enabled. Responsibility for addressing this typically falls to platform or infrastructure teams managing the LXD environment, in coordination with security teams for exposure assessment. The first practical step is to identify all LXD instances, confirm if the affected configuration is present and reachable from within guest environments, and then ascertain the owner responsible for each instance to plan remediation.

Platform and infrastructure teams own the issue.
Verify `security.devlxd.management.volumes` status.
Remediate in the next maintenance window.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Canonical LXD and how is it used?

Canonical LXD is a system container and virtual machine manager. It provides a lightweight way to run multiple isolated Linux environments on a single host. Users typically employ it to manage infrastructure, host web services, or create sandboxed development environments where efficient resource sharing and fast startup times are required.

What is the vulnerability in CVE-2026-12411?

This issue is a Broken Access Control vulnerability, specifically categorized under CWE-639 and CWE-862. It means the software fails to properly verify if a user has permission to perform an action. In this case, the `devLXDInstancePatchHandler` does not correctly check authorization, allowing a user in one container to interact with storage volumes that should be restricted to other containers.

How can this LXD vulnerability be triggered?

An attacker needs existing access as an untrusted guest within an LXD instance. The bug is triggered by sending a specially crafted device PATCH request to the internal /dev/lxd interface. Crucially, this only occurs when the specific configuration setting `security.devlxd.management.volumes` is enabled. If this setting is disabled, the specific handler component is not susceptible to this unauthorized access.

Is my system at risk according to Halo Surface Signal?

Halo Surface Signal indicates that this risk is very unlikely to be internet-facing. Because the vulnerability resides in a local socket interface (/dev/lxd) inside the guest, it is not reachable from the public internet. It requires local access within the guest environment, meaning the primary danger is limited to environments where untrusted guests are intentionally placed on shared infrastructure.

What should I do if I run LXD in my environment?

Start by identifying all your active LXD instances to map where this software is deployed. Check whether the setting `security.devlxd.management.volumes` is enabled on any of your containers. If you find this configuration is active, coordinate with your infrastructure team to evaluate the risk of your current guest isolation strategy and plan a timely update to a patched version.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.