Canonical LXD EUVD-2026-57516

Exploitation requires all of the following: (1) a valid LXD user account with at minimum operator-level rights to create or update instances within a target project (PR:L - unauthenticated exploitation is not possible); (2) the target LXD project must have restricted.containers.privilege=isolated explicitly configured by an administrator - this is a non-default setting; projects without this restriction are unaffected by this specific bypass; (3) the attacker must submit an instance configuration that omits security.idmap.isolated rather than setting it explicitly. Exploitation is bounded by: authenticated access requirement, the non-default project restriction configuration, and the attacker needing existing project membership. Default LXD deployments and projects without privilege restriction policies are not affected.

The vendor-assigned CVSS score of 4.3 (Medium) reflects authenticated access (PR:L) and scoped impact. However, the assigned vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) warrants scrutiny: the A:L (Availability Low) impact is inconsistent with the described behavior, which is fundamentally an integrity and isolation bypass - there is no availability degradation described. An independent assessment suggests I:L is the correct impact dimension. Depending on the privileged container's capabilities post-bypass, a scope change (S:C) may also be warranted if the container can access host namespaces. No EPSS data was provided, and no KEV or POC exists, so automated or widespread exploitation is not confirmed. Real-world priority is elevated in multi-tenant LXD environments where untrusted users share project access; in single-tenant or trusted-user deployments the practical risk is minimal. CVSS vector anomaly (A:L vs. expected I:L) should be verified with Canonical.

An authenticated LXD user with instance-creation rights in a project that enforces restricted.containers.privilege=isolated submits a crafted lxc launch or instance update request that omits the security.idmap.isolated key entirely - causing LXD to skip the isolation enforcement check. The resulting container runs with a non-isolated UID/GID mapping, potentially sharing UID ranges with the host or other containers in violation of the project's security policy. No public proof-of-concept code has been identified at time of analysis, but the bypass mechanism is straightforward for any user familiar with LXD's instance configuration API.