Summary
Incus contains an authorization bypass in the custom volumes API that can allow a project-restricted client to copy volumes from another project by omitting the source type.
An attacker with access to the affected API may read other projects' volumes, snapshots, and configuration when the request's project context is not enforced correctly.
Incus contains an authorization bypass in the custom volumes API that can allow a project-restricted client to copy volumes from another project by omitting the source type.
An attacker with access to the affected API may read other projects' volumes, snapshots, and configuration when the request's project context is not enforced correctly.
Affected context
The issue occurs in Incus deployments where project-restricted clients can access the custom volumes endpoint and the request handler accepts an omitted source.type value. Under those conditions, authorization checks may fail to bind the requested source volume to the caller's permitted project, allowing resources from a chosen project to be copied or exposed.
The issue occurs in Incus deployments where project-restricted clients can access the custom volumes endpoint and the request handler accepts an omitted source.type value. Under those conditions, authorization checks may fail to bind the requested source volume to the caller's permitted project, allowing resources from a chosen project to be copied or exposed.
Exploit preconditions
- Attack surface: Incus API custom volumes endpoint
- Required access: An authenticated client with project-restricted access
- Trigger point: A crafted POST request that omits
source.typeand specifies a source project - Why exploitation is possible: The request is processed without correctly enforcing the source resource's project authorization, allowing cross-project volume operations
- Attack surface: Incus API custom volumes endpoint
- Required access: An authenticated client with project-restricted access
- Trigger point: A crafted POST request that omits
source.typeand specifies a source project - Why exploitation is possible: The request is processed without correctly enforcing the source resource's project authorization, allowing cross-project volume operations
Why this happens
The underlying bug is an authorization decision based on incomplete or ambiguous request attributes. When source.type is omitted, the endpoint can follow a code path that does not consistently validate whether the selected source volume belongs to a project the caller may access.
This maps to CWE-284: Improper Access Control, in which a protected resource or operation is not adequately constrained by the caller's permissions and resource ownership.
The underlying bug is an authorization decision based on incomplete or ambiguous request attributes. When source.type is omitted, the endpoint can follow a code path that does not consistently validate whether the selected source volume belongs to a project the caller may access.
This maps to CWE-284: Improper Access Control, in which a protected resource or operation is not adequately constrained by the caller's permissions and resource ownership.
Potential impact
- An attacker may copy volumes belonging to other projects.
- Sensitive data stored in volumes may be disclosed.
- Snapshots and associated configuration may be exposed.
- Unauthorized copies could persist beyond the original access request.
- Project isolation may be weakened, enabling broader information gathering.
- An attacker may copy volumes belonging to other projects.
- Sensitive data stored in volumes may be disclosed.
- Snapshots and associated configuration may be exposed.
- Unauthorized copies could persist beyond the original access request.
- Project isolation may be weakened, enabling broader information gathering.
General mitigation guidance
Mitigation generally focuses on making authorization decisions independent of optional or ambiguous request fields.
Common defensive patterns include:
- Require explicit, validated source types and reject incomplete requests by default.
- Re-check source-project ownership and caller permissions for every volume and snapshot operation.
- Apply deny-by-default authorization at the API and storage layers.
- Treat project identifiers supplied by clients as untrusted selectors rather than proof of access.
- Minimize service and project privileges so a compromised client cannot access unrelated resources.
- Add regression tests for omitted fields, cross-project identifiers, and alternate request paths.
Mitigation generally focuses on making authorization decisions independent of optional or ambiguous request fields.
Common defensive patterns include:
- Require explicit, validated source types and reject incomplete requests by default.
- Re-check source-project ownership and caller permissions for every volume and snapshot operation.
- Apply deny-by-default authorization at the API and storage layers.
- Treat project identifiers supplied by clients as untrusted selectors rather than proof of access.
- Minimize service and project privileges so a compromised client cannot access unrelated resources.
- Add regression tests for omitted fields, cross-project identifiers, and alternate request paths.
How teams detect issues like this
Organizations can look for:
- Static analysis and code review findings where authorization depends on optional fields or implicit defaults.
- API handlers that construct resource queries from client-supplied project identifiers before performing permission checks.
- Tests that cover only valid request shapes and omit malformed or incomplete authorization inputs.
- Audit logs showing project-restricted identities copying volumes or snapshots across project boundaries.
- Policy checks requiring explicit resource ownership validation for every cross-resource operation.
Automated API security testing and authorization-focused review tools can help identify inconsistent enforcement across request variants.
Organizations can look for:
- Static analysis and code review findings where authorization depends on optional fields or implicit defaults.
- API handlers that construct resource queries from client-supplied project identifiers before performing permission checks.
- Tests that cover only valid request shapes and omit malformed or incomplete authorization inputs.
- Audit logs showing project-restricted identities copying volumes or snapshots across project boundaries.
- Policy checks requiring explicit resource ownership validation for every cross-resource operation.
Automated API security testing and authorization-focused review tools can help identify inconsistent enforcement across request variants.
