CVE-2026-85526 in LXD
Summary
by MITRE • 09/28/2026
Path traversal in the Btrfs storage driver (unpackVolume) in Canonical LXD on Linux allows an authenticated user with instance creation privileges to delete or replace arbitrary files and directories on the host filesystem as root via a crafted subvolumes[].path entry in backup/optimized_header.yaml during a btrfs optimized backup import.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/28/2026
The vulnerability identified within Canonical's LXC container management platform, specifically affecting the Btrfs storage driver’s unpackVolume function, represents a critical path traversal flaw that compromises host-level integrity. This security issue arises from insufficient validation of user-supplied input during the process of importing optimized backups for containers managed via Btrfs subvolumes. An attacker who possesses authenticated access and privileges to create instances can exploit this weakness by manipulating specific configuration files associated with the backup structure, particularly within the backup/optimized_header.yaml file. By crafting a malicious entry in the subvolumes[].path field, the adversary can inject directory traversal sequences that bypass intended isolation boundaries. This allows the attacker to direct file operations outside of the designated container storage directories and into arbitrary locations on the underlying host filesystem.
From a technical perspective, the flaw stems from how the LXD daemon processes path strings when unpacking volume data for Btrfs-backed instances. The system fails to adequately sanitize or canonicalize the paths provided in the backup metadata before applying them during file extraction operations. Consequently, sequences such as ../ are interpreted literally rather than being rejected or normalized, enabling write access to sensitive host directories that should remain inaccessible to container workloads and their management interfaces. This behavior effectively breaks the security model of containerization, which relies on strict separation between guest environments and the host operating system kernel and filesystem hierarchy. The ability to overwrite or delete arbitrary files as root is particularly severe because it grants full control over the host machine, potentially leading to complete system compromise.
The operational impact of this vulnerability extends far beyond simple data loss within a single container. Since the exploitation occurs with root privileges on the host, an attacker can modify critical system binaries, install persistent backdoors, or alter security configurations such as firewall rules and user accounts. This level of access facilitates lateral movement across other containers hosted on the same infrastructure and enables privilege escalation to control all services running on the physical server. In multi-tenant environments where LXD is used for hosting multiple isolated workloads, this vulnerability poses a significant risk of cross-instance attacks, allowing one compromised tenant to disrupt or exfiltrate data from others by manipulating shared host resources.
This flaw aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, as the application does not properly restrict file operations to an expected directory structure. Furthermore, it relates to CWE-732 in contexts where improper permission assignment allows unauthorized access to sensitive files due to flawed logic rather than explicit permission misconfigurations. In terms of adversary tactics, this vulnerability supports techniques described in MITRE ATT&CK under Command and Control or Defense Evasion, specifically those involving file system manipulation for persistence or disruption. The exploitation vector is classified as local with authentication requirements, meaning the threat actor must first gain valid credentials to an LXD user account capable of creating instances before they can trigger this path traversal condition.
Mitigation strategies should prioritize immediate patching through official Canonical channels to update LXD to a version where input validation for backup import operations has been hardened. Administrators should also enforce strict least-privilege principles, ensuring that users with instance creation privileges are trusted and monitored closely. Additionally, implementing file integrity monitoring on host directories can help detect unauthorized modifications resulting from such exploits. Network segmentation and restricting API access to LXD services further reduce the attack surface by limiting who can interact with the management interface. Regular audits of backup import procedures and validation logic within storage drivers remain essential for maintaining robust container security postures against evolving path traversal techniques.