CVE-2026-12411 is a high-severity broken access control flaw (CVSS 8.4) in Canonical LXD. With security.devlxd.management.volumes enabled, an untrusted guest can mount, read and overwrite another guest's custom storage volume through the DevLXD API. It affects LXD 6.6 and later and is fixed in 6.9.
What's affected
From the CVE record and the Canonical GitHub security advisory GHSA-hhf9-qw4v-72xp:
- Product: Canonical LXD.
- Affected versions: 6.6 and later, up to the fix.
- Patched version: 6.9.
- Condition: the
security.devlxd.management.volumesoption must be enabled, so that guests can manage storage volumes through/dev/lxd. - Component: the DevLXD instance patch handler,
devLXDInstancePatchHandler. - Weakness classes: CWE-639 (authorization bypass through a user controlled key) and CWE-862 (missing authorization).
- Severity: CVSS 8.4 with a local attack vector and changed scope. GitHub rates the advisory high.
- Advisory date: 26 June 2026. The fix is in pull request 18585.
How to check if you're exposed
- Read the LXD server version. If you use the snap, the snap list shows it too.
lxd --version
snap list lxd
- For each instance, check whether volume management over DevLXD is turned on.
lxc config get INSTANCE security.devlxd.management.volumes
Replace INSTANCE with the instance name. A value of true means the option is enabled. Also check project and profile settings if you set options there.
- Count how many guests that belong to different owners share a project with that option on. The flaw crosses between guests in the same project.
- Make a list of custom storage volumes in those projects, because those are what a guest could reach.
What to do now
- Update LXD to 6.9 or later on every host.
- Until you can update, turn off
security.devlxd.management.volumeson instances that do not need it. The advisory does not list this as a workaround, but the flaw requires the option to be on. - Separate guests that belong to different tenants into different projects, so a guest cannot name a volume it should never see.
- Review which volumes contain sensitive data, and check for unexpected mounts or modification times on them.
- Review DevLXD identity and permission grants. Give a guest edit rights only on its own instance.
Why it matters
The DevLXD API lets code inside a guest talk to the host over /dev/lxd. When volume management is on, a guest can create and manage custom storage volumes. LXD records who created each volume and checks that owner on reads, writes and deletes. The advisory says the path that attaches a volume to an instance did not make the same check. It confirmed that the volume existed and had the shape of a disk device, but not that the caller owned it.
That is a classic missing authorization pattern: one code path enforces a rule, and a sibling path that reaches the same data does not. The impact in the advisory is that one tenant can get full read and write access to another tenant's volume data. The CVSS vector marks the scope as changed because the effect crosses a guest boundary, and it shows a local attack vector because the attacker must already be inside a guest.
If you run LXD for a single trusted team, the risk is smaller. If you run it for multiple tenants or for untrusted workloads, this is the kind of flaw that matters most, since isolation between guests is the point. The CVE is not in the CISA Known Exploited Vulnerabilities catalog.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Am I affected if I never enabled volume management?
The flaw needs security.devlxd.management.volumes to be enabled. If it is off for all instances, the described attack does not apply. Update anyway.
Why is the attack vector local?
The attacker must already control a guest, because the request goes through the /dev/lxd interface inside it.
Sources
- Gold entry and CVE record: CVE-2026-12411.
- Canonical LXD security advisory GHSA-hhf9-qw4v-72xp, published 26 June 2026.
- Fix: pull request 18585 in canonical/lxd, referenced in the record.
Last reviewed: 19 October 2026.
