Description

An improper validation vulnerability in the instancePostMigration function in lxd/instance_post.go of LXD allows an authenticated attacker with can_create_instances permissions on a restricted project to bypass project-level security restrictions. When migrating an instance between projects, LXD fails to validate the instance's configuration against the target project's enforced restrictions (such as restricted.containers.lowlevel, restricted.devices.*, and restricted.networks.access). An attacker can exploit this by creating a disallowed or high-privilege instance in an unrestricted project and subsequently moving it into the restricted project.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-08-12T20:17:47.953Z",
  "pubdate": "2026-08-12T20:17:47.953Z",
  "executiveSummary": "An improper validation vulnerability exists in LXD, specifically within the instancePostMigration function in lxd/instance_post.go. This security flaw allows an authenticated attacker possessing can_create_instances permissions on a restricted project to entirely bypass enforced project-level security restrictions.\nThe core impact of this vulnerability is the circumvention of administrative security boundaries, enabling the introduction of disallowed, unvalidated, or high-privilege workloads into environments explicitly configured to block them. Affected systems include LXD deployments utilizing project-level security configurations such as restricted.containers.lowlevel, restricted.devices.*, and restricted.networks.access.\nThe risk implication is severe, as it undermines multi-tenancy and isolation guarantees within LXD clusters, granting low-privileged users the capability to execute arbitrary or restricted configurations through migration mechanisms.\nExploitation requires authentication, specifically the ability to create instances within an unrestricted project, alongside the capability to initiate an instance migration into a target restricted project where the validation checks are improperly bypassed.",
  "technicalDetails": "The vulnerability resides in the instancePostMigration function located within the lxd/instance_post.go file of LXD. The root cause of the issue is an absence of adequate validation logic during the instance migration process between distinct LXD projects.\nUnder normal operational conditions, LXD enforces strict security boundaries via project settings such as restricted.containers.lowlevel, restricted.devices.*, and restricted.networks.access to prevent users from deploying low-level, privileged, or unauthorized network and device configurations within restricted projects. However, the instancePostMigration implementation fails to validate the incoming instance's existing configuration against these target project restrictions during a migration operation.\nThe attack flow proceeds in a sequential manner. First, an authenticated attacker with can_create_instances permissions targeting a restricted project identifies or creates an unrestricted project where these security policies are absent. Second, the attacker crafts or provisions a disallowed or high-privilege instance within this unrestricted project, incorporating configurations—such as low-level container options, restricted device mappings, or unauthorized network access—that would normally be blocked by the target restricted project's policy engine.\nThird, the attacker initiates a migration operation to move the newly created instance from the unrestricted source project into the restricted target project. Because the vulnerable instancePostMigration function processes the migration without verifying the instance configuration against the target project's enforced restrictions, the migration succeeds.\nPost-exploitation, the attacker successfully establishes a high-privilege or otherwise disallowed instance within the restricted project, effectively breaching isolation guarantees, escalating operational capabilities beyond authorized boundaries, and violating the multi-tenant security model enforced by the LXD daemon."
}