Skip to main content
CVE Vulnerability Database

CVE-2026-9640: Canonical LXD Privilege Escalation Flaw

CVE-2026-9640 is a privilege escalation vulnerability in Canonical LXD that allows authenticated operators to bypass restrictions and gain root access. This article covers technical details, affected versions, and mitigations.

Published:

CVE-2026-9640 Overview

CVE-2026-9640 is an authorization vulnerability in Canonical LXD, a system container and virtual machine manager. The flaw resides in how LXD handles project-restriction policies during snapshot restoration. An authenticated project operator in a restricted multi-tenant environment can import a maliciously crafted instance backup that contains restricted configuration keys inside a snapshot. When the snapshot is restored, LXD applies these keys to the live instance without re-validating them against project policy. Starting the modified instance grants the operator host root access. The vulnerability is tracked as CWE-863: Incorrect Authorization and affects LXD versions 6.0 through 6.9, 5.21.0 through 5.21.5, and 5.0.0 through 5.0.7.

Critical Impact

A restricted project operator can escape multi-tenant isolation and obtain root on the LXD host by restoring a crafted snapshot.

Affected Products

  • Canonical LXD 6.0 before 6.9
  • Canonical LXD 5.21.0 before 5.21.5
  • Canonical LXD 5.0.0 before 5.0.7

Discovery Timeline

  • 2026-06-26 - CVE-2026-9640 published to NVD
  • 2026-07-02 - Last updated in NVD database

Technical Details for CVE-2026-9640

Vulnerability Analysis

LXD supports multi-tenant deployments through projects. Projects enforce restrictions that prevent operators from setting privileged configuration keys such as security.privileged, security.nesting, raw.idmap, or raw.lxc. These keys, if applied to a container, allow the workload to break out of user-namespace confinement and interact with the host as root.

The project-restriction check runs when an operator sets configuration on an instance directly. It does not run consistently along the snapshot restoration path. An attacker with the project operator role can create an instance under normal restrictions, export it as a backup, edit the embedded backup.yaml to inject restricted keys into a snapshot definition, and re-import the archive. Restoring that snapshot writes the restricted keys onto the live instance. The subsequent instance start uses the elevated configuration.

Root Cause

The snapshot restoration code path in LXD applies configuration deltas from the snapshot to the parent instance without invoking the same policy validation used for direct configuration updates. This is a classic missing-authorization-on-alternate-path issue, matching CWE-863. Because backup archives are attacker-controlled input, any restricted key encoded in the snapshot payload is trusted and merged into the runtime configuration.

Attack Vector

Exploitation requires an authenticated account with project operator privileges on the LXD server, so the attacker is already inside the trust boundary of a shared tenancy. The attacker crafts an instance backup with restricted keys embedded in a snapshot section, imports the backup through the standard LXD API or CLI, restores the snapshot to overwrite the running instance configuration, and starts the container. The started instance runs with security.privileged=true or equivalent, giving the operator root on the host and access to other tenants sharing the same LXD node.

No verified public exploit code is available. Technical mechanics are described in GitHub Security Advisory GHSA-ppq7-4492-5552.

Detection Methods for CVE-2026-9640

Indicators of Compromise

  • Instance backup imports (lxc import) followed shortly by snapshot restore operations against the same instance within a restricted project.
  • Running instances in a restricted project whose live configuration contains keys the project policy forbids, such as security.privileged, security.nesting, raw.idmap, or raw.lxc.
  • Unexpected host-level processes spawned by containerized workloads owned by non-admin project operators.

Detection Strategies

  • Audit the LXD event log and API access log for the sequence POST /1.0/instances (backup import), POST /1.0/instances/<name>/snapshots/<snap> (restore), then PUT /1.0/instances/<name>/state (start).
  • Compare each instance's effective configuration against the enclosing project's restricted.* policy and alert on any key that violates the policy.
  • Flag any backup archive whose embedded backup.yaml declares restricted configuration keys inside a snapshot block.

Monitoring Recommendations

  • Forward LXD daemon logs and audit events to a centralized analytics tier for correlation with host-level process telemetry.
  • Monitor Linux hosts for container processes running with effective UID 0 or with capabilities such as CAP_SYS_ADMIN where policy dictates unprivileged operation.
  • Track privilege changes on instances in restricted projects and treat any post-restore configuration drift as high priority.

How to Mitigate CVE-2026-9640

Immediate Actions Required

  • Upgrade LXD to 6.9, 5.21.5, or 5.0.7 or later depending on the deployed branch.
  • Review all restricted projects for instances whose current configuration contains keys the project policy forbids, and revert them.
  • Restrict which accounts hold the project operator role in multi-tenant clusters until patches are applied.
  • Disable backup import functionality for untrusted operators where feasible.

Patch Information

Canonical addressed the flaw through three pull requests: canonical/lxd#18301, canonical/lxd#18303, and canonical/lxd#18304. The fixes enforce project-restriction validation on the snapshot restoration code path so that restricted keys cannot be applied through a restored backup. Details are published in GHSA-ppq7-4492-5552.

Workarounds

  • Prevent project operators from importing backups by removing the corresponding permission from their role until upgraded.
  • Manually inspect any backup archive before import and reject archives whose backup.yaml contains restricted keys within snapshot sections.
  • Isolate multi-tenant LXD hosts so that a host-root compromise does not extend to shared storage or management networks.
bash
# Verify installed LXD version and upgrade on Ubuntu with snap
snap info lxd | grep tracking
sudo snap refresh lxd --channel=6.9/stable
# Or for the LTS 5.21 track
sudo snap refresh lxd --channel=5.21/stable
# Or for the LTS 5.0 track
sudo snap refresh lxd --channel=5.0/stable

# List restricted projects and audit running instance configuration
lxc project list
lxc project show <project> | grep -E 'restricted'
lxc config show <instance> --expanded | \
  grep -E 'security.privileged|security.nesting|raw.idmap|raw.lxc'

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.