CVE-2026-55621

Executive Summary

CVE-2026-55621 is an authorization bypass vulnerability in Incus, a system container and virtual machine manager, affecting versions prior to 7.2.0. The flaw resides in the custom volume copying mechanism, where missing authorization checks allow an authenticated attacker to copy custom volumes from projects to which they lack access, provided the attacker knows the target project name and custom volume name. Successful exploitation can expose confidential data — including secrets — stored within custom volumes, leading to unauthorized information disclosure with high confidentiality impact and a CVSS score of 7.7 (High).

Technical Analysis

Incus implements a project-based isolation model where custom volumes (storage volumes used by containers and VMs) are scoped to specific projects. This project scoping is intended to enforce access control boundaries, ensuring that a user with privileges in one project cannot interact with resources owned by another project.

The vulnerability exists in the custom volume copy functionality. When an authenticated user initiates a copy operation for a custom volume, the application fails to perform proper authorization checks to verify that the requesting user has access to the source project containing the volume. The NVD description indicates that the only prerequisites for exploitation are:

1. Knowledge of the target project name (which the attacker does not have access to).
2. Knowledge of the custom volume name within that project.

The missing authorization check (CWE-284 — Improper Access Control) allows the attacker to issue a copy request that transfers the source custom volume from the unauthorized project to a destination project under the attacker's control. The flaw is classified as an authentication-required, network-accessible vulnerability with low attack complexity:

• Attack Vector: Network (AV:N) — the vulnerable operation is exposed via the Incus API, which is remotely accessible.
• Attack Complexity: Low (AC:L) — no special conditions beyond valid credentials are required.
• Privileges Required: Low (PR:L) — any authenticated Incus user can exploit this, including users with the most basic privileges.
• User Interaction: None (UI:N) — no victim interaction is needed.
• Scope: Changed (S:C) — the compromised resource (custom volume) resides in a security scope (source project) outside the attacker's authorized security scope.
• Confidentiality Impact: High (C:H) — the copied volume may contain sensitive data including secrets, credentials, configuration files, or application data.
• Integrity Impact: None (I:N) — the attack is read-oriented; the attacker copies the data but does not modify the source.
• Availability Impact: None (A:N) — no disruption to service availability.

The vulnerability class is an authorization bypass on a data-copy operation, allowing cross-project data exfiltration through a legitimate API endpoint that lacks proper access control enforcement.

Exploitation Scenarios

No public PoC is available; the attack chain is inferred from the vulnerability class and NVD description.

Step 1 — Reconnaissance / Target Identification: The attacker must first authenticate to the Incus API. Being a low-privilege user, the attacker has a valid account but limited project access. Reconnaissance involves gathering two pieces of information: (a) the name of a project the attacker does not have access to, and (b) the name of a custom volume within that project. Project names and custom volume naming conventions may be discoverable through:

• Configuration files or documentation that leak project naming.
• Cross-user information sharing (e.g., logs, dashboards, or management interfaces).
• Guessing based on organizational naming conventions (e.g., prod, production, finance-app).
• Internal listings that partially expose project/volume names.

This is a knowledge-based attack requirement — the attacker must possess this naming information, but no deeper access to the target project's data is needed at this stage.

Step 2 — Triggering the Vulnerability: The attacker initiates a custom volume copy operation through the Incus API. The request specifies a source project (the unauthorized project name) and a source custom volume name (the known volume name within that project), with a destination being a project the attacker controls (or has permission to create volumes in). Due to the missing authorization checks, the API accepts the request without verifying the attacker's rights on the source project. The application proceeds to process the copy operation across the project boundary.

Step 3 — Payload / Execution Method: The attack is performed entirely through legitimate API calls for volume copying. No injection payload or remote code execution is involved. The "payload" in this context is the crafted API request itself — the correct combination of source project name, source volume name, and destination project name that the flawed authorization logic fails to reject. At the vulnerability-class level, this is an improper access control failure where the authorization check that should validate source resource ownership is missing or incomplete.

Step 4 — Post-Exploitation Impact: Once the copy operation succeeds, the attacker has a replica of the custom volume in a project they control. They can now:

• Mount the copied volume to a container or VM they manage.
• Extract all data from the volume, including secrets, credentials, private keys, encrypted data, application configuration, or any sensitive operational data stored in the volume.
• Perform offline analysis at their leisure, since the data is now in their security boundary.
• Potentially use extracted credentials to move laterally into the previously unauthorized project or other connected systems.

The confidentiality impact is high, though no integrity or availability compromise occurs. The attack is silent — the source volume remains intact and unmodified, and the attacker's actions may not trigger alarms in the source project's environment because the attacker never interacts with it directly beyond the API call.

Impact Assessment

Business Impact: High. Custom volumes in Incus are frequently used to persist sensitive data for containers and virtual machines — including database storage, application secrets, TLS certificates, API keys, and configuration files containing credentials. Exposure of such data can lead to:

• Credential theft and subsequent unauthorized access to downstream systems.
• Exfiltration of proprietary or personally identifiable information (PII).
• Regulatory/compliance violations (GDPR, HIPAA, PCI-DSS) if protected data is exposed.
• Reputational damage and potential legal liability.

Affected Systems: All Incus deployments running versions prior to 7.2.0 that utilize multi-project environments with custom volumes and expose the API to authenticated users. Installations with a single-project setup are effectively unaffected since the cross-project attack vector does not exist in that configuration.

Blast Radius: The CVSS vector indicates a Scope: Changed — meaning the attack crosses a security boundary (from the attacker's project to the victim's project). The Confidentiality impact is High. The low privilege requirement means even minimal-credential users pose a threat. If an organization operates many projects with sensitive data volumes, a single compromised low-privilege account could expose all custom volumes across all projects, provided the attacker can guess or learn the project and volume names.

CVSS Score: 7.7 (High) — The scoring reflects the high confidentiality impact, network exploitability, low complexity, and changed scope, despite the requirement for valid credentials and knowledge of target resource names.

Detection Guidance

Sigma Rule

title: Incus Custom Volume Cross-Project Copy Attempt
id: 4a7c9d2e-8f3b-4c5a-9e8d-1b2c3d4e5f6a
status: experimental
description: Detects attempts to copy custom volumes across project boundaries in Incus, potentially exploiting CVE-2026-55621
date: 2026/06/01
author: Valters IT Security Research
logsource:
    category: application
    product: incus
detection:
    selection:
        event_type: "custom_volume_copy"
        source_project:
            - "!=": "current_user_project"
    condition: selection
level: high
falsepositives:
    - Legitimate cross-project volume copies performed by administrators
    - Automation scripts with elevated privileges performing sanctioned copies
fields:
    - user
    - source_project
    - destination_project
    - volume_name
    - source_ip

YARA Rule

rule Incus_CVE_2026_55621_Volume_Copy_Abuse {
    meta:
        author = "Valters IT Security Research"
        description = "Detects Incus API requests indicating cross-project custom volume copy attempts"
        cve = "CVE-2026-55621"
        date = "2026-06-01"
    strings:
        $copy_endpoint = /\/1\.0\/projects\/[^\/]+\/custom\/volumes\/[^\/]+\/copy/i
        $operation = "copy"
        $custom_volume = "custom_volume"
        $source = "source"
        $destination = "destination"
        $target = "target"
    condition:
        uint16(0) == 0x7B7B and  // "{{" prefix for potential JSON template scans
        any of ($copy_endpoint) and
        any of ($operation, $custom_volume, $source, $destination, $target) and
        3 of them
}

Suricata IDS Rule

alert http any any -> any any (msg:"Incus CVE-2026-55621 - Cross-Project Custom Volume Copy Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/1.0/projects/"; distance:0; content:"/custom/volumes/"; distance:0; content:"/copy"; distance:0; content:"source"; http.request_body; content:""; metadata:created_at 2026-06-01; reference:cve,2026-55621; sid:202655621; rev:1;)

Elastic Detection

sequence by source.ip, user.name with maxspan=10m
  [network where network.direction == "egress" and 
   process.name == "incusd" and 
   destination.port == 8443 and
   http.request.method == "POST"]
  [file where event.action in ("copy", "create") and 
   file.name like "*custom*volume*"]

Splunk SPL Query

index=incus sourcetype=incus_api 
| where event_type="custom_volume_copy" 
| lookup incus_user_projects user as authenticated_user OUTPUT allowed_projects
| eval is_cross_project = if(mvfind(allowed_projects, source_project), "no", "yes")
| search is_cross_project="yes"
| table _time, authenticated_user, source_project, destination_project, volume_name, src_ip
| sort - _time

Wazuh OSSEC Rule

<rule id="100556" level="12">
    <decoded_as>json</decoded_as>
    <field name="event_type">custom_volume_copy</field>
    <regex>source_project</regex>
    <regex>destination_project</regex>
    <group>incus, improper_access_control, CVE-2026-55621,</group>
    <description>Incus: Potential cross-project custom volume copy - CVE-2026-55621</description>
    <mitre>
        <id>T1213</id>
    </mitre>
</rule>

Mitigation & Patch Guidance

Patch Confidence: 3/4 (LIKELY) — two independent sources confirm the fix in version 7.2.0.

1. Immediate Mitigations:

   • Upgrade to Incus version 7.2.0 or later immediately, as this is the confirmed patched version.
   • If immediate upgrade is not feasible, restrict API access to trusted networks only via firewall rules.
   • Audit all user accounts and permissions; remove or disable accounts that do not require API access.
   • Monitor API access logs for any cross-project volume copy operations, especially from low-privilege accounts.
   • Review existing custom volumes for sensitive data; consider encrypting volume contents so that even if copied, the data remains protected.

2. Patch/Upgrade Steps:

   • Follow the official Incus upgrade procedure to transition to version 7.2.0.
   • For Debian-based systems, obtain the patched package from the Debian repository.
   • After upgrading, verify the fix by testing a cross-project volume copy with a non-privileged account; the operation should fail with an authorization error.
   • Restart all Incus services to ensure the new version is fully loaded.

3. Long-Term Hardening:

   • Implement the principle of least privilege; ensure users only have access to projects and volumes required for their role.
   • Enable comprehensive audit logging for all Incus API operations and retain logs for forensic analysis.
   • Regularly review project and volume access control lists (ACLs) as part of security hygiene.
   • Consider implementing network segmentation so the Incus API is not exposed to untrusted networks.
   • Establish a patch management process with defined SLAs so critical security updates are applied promptly.
   • Evaluate the use of additional encryption layers (e.g., LUKS, dm-crypt) for volumes containing highly sensitive data.

References

1. NVD Entry — CVE-2026-55621: https://nvd.nist.gov/vuln/detail/CVE-2026-55621
2. Incus Official Website / Release Notes — Version 7.2.0: https://linuxcontainers.org/incus/
3. Debian Security Tracker — CVE-2026-55621: https://security-tracker.debian.org/tracker/CVE-2026-55621
4. MITRE ATT&CK — T1213 Data from Information Repositories: https://attack.mitre.org/techniques/T1213/
5. CWE-284 Improper Access Control: https://cwe.mitre.org/data/definitions/284.html

Known Exploitation Activity: No active exploitation campaigns, exploits-in-the-wild, or proof-of-concept code have been publicly reported for CVE-2026-55621 at the time of writing. The CVE is not listed on the CISA Known Exploited Vulnerabilities (KEV) catalog. Given the low attack complexity and high confidentiality impact, exploitation is considered likely as the patch begins to be reverse-engineered and the flaw becomes more widely known.