Canonical LXD CVE-2026-63297

Exploitation requires an authenticated LXD client (TLS certificate or equivalent) holding permission to create instances and to perform cross-project instance copies into a target project that enforces restrictions - this maps to the CVSS PR:L. The specific trigger is the cross-project instance-copy operation combined with a source instance that carries high-privilege configuration disallowed by the target project's restriction policy; without a restriction-enabled target project there is nothing to bypass. Limiting factors: the attacker must already have valid LXD API access and copy rights, and the deployment must actually use LXD projects with restrictions as a security boundary - single-tenant or unrestricted-project setups derive no security benefit from the check and are not meaningfully harmed by its bypass.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C, C:H/I:H/A:H) describes a low-complexity, network-reachable attack requiring only low privileges, with a scope change reflecting that a low-privileged actor in one project escalates control into a restricted project - this is the primary driver of the 9.9 score. Real-world risk is moderated by the prerequisite that the attacker already hold authenticated LXD access with rights to create and copy instances, so this is a privilege-escalation/guardrail-bypass rather than a pre-auth internet-facing RCE. No EPSS score, SSVC decision, POC, or KEV entry was provided, so exploitation probability cannot be quantified from the input; the absence of a public exploit and KEV listing suggests this is not yet under active exploitation. The most likely threat model is a multi-tenant LXD deployment where projects are used as a security boundary - there the impact is genuinely high because it collapses tenant isolation.

An authenticated tenant with rights only in an unrestricted project crafts an instance whose configuration enables a high-privilege feature (e.g. a privileged or nested container), then issues a cross-project copy into a project that is supposed to forbid such settings. Because LXD checks the restriction before the merged configuration is finalized, the copy succeeds and the privileged instance runs inside the restricted project, giving the attacker capabilities the project policy was meant to deny. No public POC is identified at time of analysis, and the low attack complexity means a knowledgeable tenant could reproduce it reliably.