LXD patches backup-import restriction bypass enabling host compromise

TL;DR — A config-source mismatch in LXD backup import lets restricted-project users smuggle privileged instance settings via a crafted archive, bypassing project restrictions and enabling host compromise.

What happened

LXD is Canonical’s system container/VM manager, commonly used to run multi-tenant Linux containers and virtual machines with project-level isolation controls. Canonical’s advisory for CVE-2026-34178 describes a project restriction bypass in the instance backup import path: LXD checks restrictions against backup/index.yaml inside the tar archive, but creates the instance from backup/container/backup.yaml extracted to the storage volume.

Because both files are attacker-controlled content within the same archive, an attacker with instance-creation rights in a restricted=true project can craft a backup where index.yaml is “clean” for validation, while backup.yaml contains restricted settings (for example security.privileged=true and raw.lxc directives). The instance is then created from the unchecked backup.yaml, bypassing restriction enforcement.

This is a high-impact class because “import/restore” features routinely cross trust boundaries (CI artifacts, user-provided images, backup migration workflows). In multi-tenant container hosts, a restriction bypass effectively turns “can create instances” into a practical escalation path toward host-level control.

Who is impacted

• LXD deployments that use projects with restricted=true as a tenant boundary.
• Environments where non-admin users can create instances and can trigger instance backup import into a restricted project.
• Higher-risk cases where admins rely on project restrictions to prevent dangerous settings such as security.privileged=true, raw.lxc / raw.apparmor, or restricted device types (GPU/USB/PCI/unix-char).

What to do now

• Follow vendor remediation guidance and apply a patched release.

  "Patched versions 5.0.7, 5.21.5, 6.8"

• Inventory LXD clusters/hosts and map where restricted=true is used as a security boundary; prioritize patching multi-tenant infrastructure first.
• Treat backup archives as untrusted input: tighten who can import backups (and who has instance creation rights) in restricted projects.
• If compromise is suspected, audit for recent backup imports and review project/instance configuration changes that introduce privileged settings or raw.* directives.