CVE-2026-115372 in Incus
Summary
by MITRE • 10/22/2026
Incus from 7.3.0 before 7.5.0 contains a project restriction bypass that allows restricted project users to set block.create_options through volume update, copy, and move operations. Attackers can set the option on a custom volume and trigger a copy or move onto a formatting pool to inject arguments into mkfs executed as root.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Incus versions prior to 7.5.0 represents a critical privilege escalation flaw rooted in insufficient access control mechanisms within the container management system's project isolation model. Specifically, this is an Access Control Bypass that allows users assigned to restricted projects to manipulate configuration parameters intended for privileged operations. The core technical failure lies in how Incus handles volume update, copy, and move operations across different storage backends. While the software correctly restricts certain administrative actions from unprivileged users, it fails to validate or sanitize specific input fields related to block creation options during these data movement tasks. This oversight enables a restricted user to inject arbitrary arguments into system-level commands that are executed with root privileges on the host machine.
The operational impact of this flaw is severe, as it effectively neutralizes the security boundaries established by Incus projects. In a typical deployment, project restrictions are designed to limit what users can do within their allocated resources, preventing them from affecting other tenants or the underlying infrastructure. However, by exploiting the block.create_options parameter during volume copy or move operations targeting a formatting pool, an attacker can force the system to execute mkfs with custom arguments. Since these commands run as root, this constitutes a Remote Code Execution vulnerability where the attacker gains full control over the host operating system. This bypass undermines the multi-tenancy security model, allowing lateral movement from a compromised container or restricted user account directly to the hypervisor level.
From an industry standards perspective, this vulnerability aligns with CWE-269 Improper Privilege Management and CWE-78 OS Command Injection. The failure to properly isolate project-level permissions reflects a breakdown in access control logic, while the ability to inject arguments into mkfs is a classic instance of command injection via unsafe input handling. In terms of threat modeling, this aligns with MITRE ATT&CK techniques such as T1068 Exploitation for Privilege Escalation and potentially T1548 Abuse Elevation Control Mechanism if the attacker leverages specific configuration states to maintain access. The attack vector is particularly dangerous because it can be triggered through standard API calls or CLI operations that appear benign, making detection by traditional security monitoring tools difficult without deep inspection of parameter values during volume management tasks.
Mitigation strategies must prioritize immediate patching to version 7.5.0 or later where these validation checks have been implemented. In environments where upgrading is not immediately feasible, administrators should enforce strict network segmentation to limit access to the Incus API endpoint from untrusted networks. Additionally, implementing robust input validation at the application layer for all volume-related operations can provide a temporary defense-in-depth measure. Security teams should also audit existing project configurations to ensure that no restricted users have been inadvertently granted elevated permissions or access to storage pools that utilize formatting backends susceptible to this injection technique. Regular security assessments focusing on API parameter sanitization are recommended to prevent similar logic flaws in container orchestration platforms.