CVE-2026-63293: LXD Path Traversal Vulnerability

CVE-2026-63293 Overview

CVE-2026-63293 is a link following vulnerability in LXD, the system container and virtual machine manager maintained by Canonical. The flaw resides in the image import and unpacking logic, where LXD fails to validate whether the metadata.yaml file inside an image archive is a symbolic link. An attacker with permission to import images can supply a crafted archive containing a symlinked metadata.yaml that points to arbitrary paths on the host filesystem. Successful exploitation yields arbitrary file read and write operations on the host, breaking container isolation and enabling escalation to the underlying system. The issue is tracked under CWE-59: Improper Link Resolution Before File Access.

Critical Impact
Attackers with image import privileges can read or overwrite arbitrary files on the LXD host, leading to full host compromise from a container context.

Affected Products

Canonical LXD (system container and VM manager)
LXD deployments accepting image imports from untrusted or semi-trusted users
Refer to the GitHub Security Advisory GHSA-j825-cg34-5fr5 for specific fixed versions

Discovery Timeline

2026-08-12 - CVE-2026-63293 published to NVD
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-63293

Vulnerability Analysis

LXD distributes container and VM images as compressed archives that contain a root filesystem alongside a metadata.yaml manifest describing the image. During import or unpack, LXD opens and processes metadata.yaml from the extracted archive to determine image properties. The unpacking routine treats metadata.yaml as a regular file without verifying its file type after extraction.

When the archive entry for metadata.yaml is a symbolic link, the link is written to disk pointing wherever the attacker specifies. Subsequent read or write operations by the LXD daemon follow that symlink and act on the target path with the daemon's privileges, typically root on the host. This confuses the security boundary between the untrusted archive content and trusted host filesystem, matching the classic [CWE-59] link-following pattern.

Because LXD runs privileged operations while handling images, an attacker can both exfiltrate sensitive host files, such as /etc/shadow or private keys, and overwrite security-critical files, such as authorized_keys, systemd unit files, or cron entries. Overwriting an executable path or configuration file yields code execution as root on the host.

Root Cause

The root cause is missing validation of file types in the image import path. LXD does not use lstat-based checks or safe extraction primitives to reject symbolic links named metadata.yaml before opening them. The archive unpacking logic implicitly trusts filenames within the tarball and follows symbolic links during file I/O.

Attack Vector

An authenticated user with permission to import or push images to an LXD instance crafts a malicious image archive. The archive contains a metadata.yaml entry that is a symlink to a chosen host path, such as /root/.ssh/authorized_keys or /etc/passwd. When LXD unpacks the archive and processes metadata.yaml, the daemon reads from or writes to the symlinked host location. Exploitation requires only low privileges within the LXD API surface and no user interaction. See the Canonical advisory for exploitation constraints and fixed versions.

Detection Methods for CVE-2026-63293

Indicators of Compromise

Image archives containing a metadata.yaml entry whose tar header type indicates a symbolic link rather than a regular file.
LXD daemon file access to host paths outside its normal storage pool directories, such as /etc, /root, or /home, during image import or image copy operations.
Unexpected modification timestamps on sensitive host files, including authorized_keys, sudoers, cron directories, and systemd unit files, correlated with image import activity.
New or altered image records in the LXD API originating from non-administrative accounts.

Detection Strategies

Inspect LXD daemon logs at /var/log/lxd/lxd.log for image import, image copy, and unpack operations, correlating them with subsequent writes to sensitive host paths.
Enable Linux audit rules (auditd) on the LXD daemon process to record open, openat, and readlink syscalls that resolve outside the LXD storage pool.
Scan retained image tarballs for symlink entries using tar -tvf and alert on any archive where metadata.yaml is not a regular file.

Monitoring Recommendations

Alert on any process running as lxd or root that opens files under /etc, /root/.ssh, or /var/spool/cron outside expected maintenance windows.
Track LXD API calls for POST /1.0/images and correlate the source certificate or account with the resulting host filesystem activity.
Monitor integrity of host authentication files using file integrity monitoring, flagging any modification not tied to a known change ticket.

How to Mitigate CVE-2026-63293

Immediate Actions Required

Upgrade LXD to the fixed version listed in GHSA-j825-cg34-5fr5 on all hosts.
Audit the list of clients and certificates authorized to call the LXD image API and revoke any that are not strictly required.
Review recent image imports and inspect the host filesystem for unauthorized modifications to sensitive files.

Patch Information

Canonical has published a security advisory and patched releases for LXD. Apply the vendor-supplied packages via snap refresh lxd for snap installations or through the distribution package manager for Debian and Ubuntu builds. Confirm the running version with lxd --version after upgrade and restart the daemon to ensure the patched binary is active. See the GitHub Security Advisory for exact fixed version numbers.

Workarounds

Restrict image import permissions to trusted administrators until the patch is applied, using LXD role-based access controls on the API.
Reject third-party image archives and use only images built in-house or fetched from the trusted Canonical image server over authenticated channels.
Pre-validate any imported tarball by extracting to a scratch directory with tar --no-overwrite-dir and rejecting archives that contain symlink entries for metadata.yaml.

bash

# Inspect an image archive for symlink entries before import
tar -tvf suspicious-image.tar.xz | grep -E '^l|metadata.yaml'

# Upgrade LXD via snap
sudo snap refresh lxd
lxd --version

# Restrict image import to admin projects (example)
lxc auth group permission add <group> server can_create_storage_volumes=false