CVE-2026-16033: LXD Path Traversal Vulnerability

CVE-2026-16033 Overview

CVE-2026-16033 is a path traversal vulnerability [CWE-22] in LXD, the system container and virtual machine manager maintained by Canonical. The flaw resides in how LXD processes image metadata templates. When handling template file paths, LXD fails to restrict directives from escaping the instance templates directory. The issue specifically affects virtual machine and QEMU driver execution paths. An authenticated attacker who supplies a crafted image archive can traverse outside the templates directory, reading arbitrary host files or creating files at unintended locations.

Critical Impact
A network-adjacent attacker with low privileges can read sensitive host files or write arbitrary files outside the LXD instance templates directory, resulting in host confidentiality loss and integrity compromise across a scope-changed trust boundary.

Affected Products

Canonical LXD (system container and virtual machine manager)
LXD virtual machine driver path (QEMU execution)
Deployments accepting user-supplied image archives with metadata templates

Discovery Timeline

2026-08-12 - CVE-2026-16033 published to the National Vulnerability Database
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-16033

Vulnerability Analysis

LXD image archives include a metadata.yaml file and a templates/ directory. Templates are Pongo2 files that LXD renders inside instances at defined trigger points such as create, copy, or start. The vulnerability arises when LXD resolves template file paths supplied in image metadata without enforcing containment within the intended templates directory.

The QEMU driver execution path processes these templates when provisioning or starting virtual machines. An attacker who can import or supply an image archive controls the template path directives. Crafted values containing ../ sequences or absolute paths cause LXD to operate on files outside the templates directory scope on the host filesystem.

The result is two-fold. LXD can be coerced into reading host files that should be inaccessible to the tenant workflow, exposing credentials, keys, or configuration. LXD can also be coerced into writing files at attacker-chosen locations, enabling tampering with host configuration or staging follow-on execution.

Root Cause

The root cause is missing path canonicalization and containment enforcement on template file references parsed from user-controlled image metadata. LXD trusts the archive-provided template path and joins it against the templates directory without validating that the resolved path remains a descendant of that directory.

Attack Vector

Exploitation requires the attacker to submit a malicious image archive to a target LXD instance. The attacker embeds template directives referencing paths such as ../../../../etc/shadow or absolute host paths. When LXD processes the image, typically during VM creation or start under the QEMU driver, the traversal executes with LXD daemon privileges. The vulnerability crosses the container-to-host trust boundary, which accounts for the scope-changed impact.

No verified exploit code is publicly available. Technical details are described in the GitHub Security Advisory GHSA-9hcm-hxh5-7xxh.

Detection Methods for CVE-2026-16033

Indicators of Compromise

Files appearing outside the LXD instance templates directory under /var/lib/lxd/ or /var/snap/lxd/common/lxd/ with recent modification timestamps tied to image import or VM start events.
LXD daemon log entries referencing template rendering with unexpected absolute paths or paths containing ../ sequences.
Image archives whose metadata.yaml template stanza references paths outside the archive's own templates/ directory.

Detection Strategies

Inspect submitted image tarballs before import and reject archives whose template entries contain .., symbolic links, or absolute path prefixes.
Monitor the LXD daemon process for file access outside expected instance directories using auditd or eBPF-based file access telemetry.
Correlate image import and instance start events with unexpected host filesystem writes performed by the LXD daemon UID.

Monitoring Recommendations

Enable verbose LXD logging around image processing and template rendering to capture resolved file paths for later review.
Alert on any read of sensitive host files such as /etc/shadow, /root/.ssh/, or cloud credential paths by the LXD daemon.
Baseline expected file creation locations for LXD and flag deviations, particularly writes under /etc, /root, or /usr/local.

How to Mitigate CVE-2026-16033

Immediate Actions Required

Upgrade LXD to the fixed release listed in the Canonical security advisory.
Restrict LXD API and remote endpoint access to trusted operators until patches are applied.
Audit recent image imports for archives sourced from untrusted parties and review templates for traversal sequences.

Patch Information

Canonical published the fix through GitHub Security Advisory GHSA-9hcm-hxh5-7xxh. Refer to the advisory for the exact patched LXD versions and snap channels. Snap-based deployments should confirm the channel receives the updated revision and refresh accordingly.

Workarounds

Disallow image imports from untrusted sources and require review of metadata.yaml template entries prior to import.
Limit which users hold the LXD client permissions required to create instances or push images.
Where feasible, avoid running the affected QEMU driver code path for images of unknown provenance until patched builds are deployed.

bash

# Configuration example: restrict LXD trust and refresh to the patched snap channel
sudo lxc config trust list
sudo lxc config trust remove <untrusted-fingerprint>
sudo snap refresh lxd --channel=latest/stable
sudo snap info lxd | grep installed