Canonical LXD CVE-2026-63300

Exploitation requires an authenticated LXD account (PR:L) that (1) can create an instance in at least one project without the target restrictions and (2) holds can_create_instances / migration rights on the restricted target project. The specific enabling condition is that the target project enforces restrictions (e.g. restricted.containers.lowlevel, restricted.devices.*, restricted.networks.access) that differ from the source project - with no such restricted project there is nothing to bypass. It is triggered specifically through the cross-project instance migration path (instancePostMigration); same-project operations are unaffected. Limiting factors: it is not anonymous (requires valid credentials and instance-creation privileges) and it only matters in multi-tenant / restricted-project deployments, so single-project or single-tenant LXD installs are not meaningfully exposed.

The signals are largely one-directional toward high priority: CVSS 9.9 with AV:N/AC:L/PR:L/UI:N and a scope change (S:C) reflecting that escaping project confinement can affect the host and other tenants. The one meaningful gating factor is PR:L - the attacker must already be an authenticated LXD user with can_create_instances on a restricted project, and must also be able to create the malicious instance in some unrestricted project, so this is primarily an insider or compromised-credential / privilege-escalation scenario rather than anonymous internet exploitation. No EPSS score, no CISA KEV listing, and no public POC are present in the provided data, so real-world exploitation is not evidenced; however, the flaw is logically simple and reliable once the prerequisite access exists, which is why any multi-tenant LXD operator - even a modest, resource-constrained team running shared LXD hosts - should treat patching as urgent. The primary residual uncertainty is the exact fixed release version, which the input does not specify.

An authenticated LXD user who is allowed to create instances in a permissive project builds a low-level/privileged container with disallowed devices or unrestricted network access there. They then issue an instance move (POST migration) targeting a restricted project where such a configuration should be forbidden; because the target project's restrictions are not re-checked, the privileged instance lands inside the restricted project and runs with capabilities the tenant was never supposed to have. No public POC is noted, but the attack requires only ordinary LXD API calls and low complexity.