CVE-2026-55621 in Incus
Summary
by MITRE • 08/21/2026
Incus is a system container and virtual machine manager. Prior to version 7.2.0, missing authorization checks exist for custom volume copying where an attacker knowing the name of a project that they don't have access to and the name of a custom volume in that project can copy the custom volume to a new project. This issue could allow an attacker to access secrets in custom volumes they are not authorized to access. Version 7.2.0 patches the issue.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/21/2026
Incus serves as a robust system container and virtual machine manager, facilitating the orchestration of isolated computing environments for developers and enterprises alike. Within this architecture, projects function as logical partitions that isolate resources, users, and configurations to enforce security boundaries between different teams or applications. A critical flaw was identified in versions prior to 7.2.0 regarding the authorization mechanisms governing custom volume operations. Specifically, the system failed to perform adequate access control checks when a user initiated a copy operation for a custom volume belonging to another project. This vulnerability stems from an improper restriction of resource-level permissions, allowing actions that should be restricted by project boundaries to proceed without verifying if the initiating actor possesses sufficient privileges within the source project.
The technical nature of this flaw constitutes a broken access control issue where the application relies on insufficient validation of user entitlements against specific resources. An attacker who has valid credentials for one or more projects can exploit this gap by identifying the name of a target project to which they do not have direct access, along with the identifier of a custom volume residing within that restricted project. By leveraging these known identifiers, the attacker can invoke the copy functionality to duplicate the unauthorized volume into a new project under their control. This bypasses the intended isolation mechanisms because the backend logic accepts the operation based on the existence of the source and destination projects rather than validating whether the current session has read or administrative permissions for the specific custom volume in question.
The operational impact of this vulnerability is significant, primarily revolving around data confidentiality and unauthorized information disclosure. Custom volumes often store sensitive application data, configuration files, database dumps, or cryptographic keys that are not meant to be accessible outside their designated project scope. By successfully copying such a volume, an attacker gains persistent read access to these secrets without needing to compromise the underlying host system or escalate privileges within the target project itself. This effectively neutralizes the security benefits of multi-tenancy and logical isolation provided by Incus projects, allowing lateral movement across organizational boundaries defined at the container management layer. The ability to exfiltrate data in this manner can lead to severe compliance violations and compromise the integrity of dependent services relying on those secrets.
This vulnerability aligns with Common Weakness Enumeration (CWE) category CWE-269, which describes Improper Privilege Management, specifically where a user is granted privileges they should not have for a specific resource. In terms of offensive security frameworks, this behavior maps to MITRE ATT&CK technique T1530, Data from Cloud Storage Object or Bucket Discovery and Exfiltration, as the attacker locates and copies data objects across isolated storage partitions within a cloud-native infrastructure management tool. The exploitation does not require complex buffer overflows or injection attacks but rather relies on logical errors in access control lists and API endpoint validation logic.
To mitigate this risk, organizations running Incus must upgrade to version 7.2.0 or later immediately, as the patch explicitly addresses these missing authorization checks by enforcing strict permission verification during volume copy operations. Until an upgrade is feasible, administrators should implement network-level restrictions to limit access to the Incus API endpoints and enforce strong identity management practices. Additionally, auditing logs for unusual volume creation patterns across different projects can help detect potential exploitation attempts in real-time. Regular security assessments of container orchestration tools are essential to ensure that logical isolation boundaries remain intact against evolving attack vectors targeting permission logic flaws.