Incus CVE-2026-115376

Requires a valid, authenticated client that is restricted to a project but holds can_create_storage_volumes permission in at least one project on the Incus server (PR:L). The attacker must send a crafted POST to /1.0/storage-pools/{pool}/volumes/custom that supplies a source volume with an attacker-chosen source.project while omitting source.type, which routes the request to the copy code path without the source-volume can_view check. Key limiting factors: the attacker needs legitimate low-privilege credentials with volume-create rights; the condition is NOT reachable through the official Incus client (which always sets source.type=copy), so a raw/hand-crafted API request is required; and impact is only meaningful on servers hosting multiple projects where project isolation is the security boundary.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/SC:H, base 8.3 High) describes a network-reachable, low-complexity authorization bypass requiring only low privileges - specifically an already-authenticated, project-restricted client that can create custom volumes. The confidentiality impact is high on both the vulnerable system (VC:H) and a subsequent system (SC:H), reflecting that the flaw breaks project isolation and lets a tenant read data belonging to other projects. No CISA KEV listing and no EPSS score were supplied, and no public exploit code was identified, so there is no evidence of active or widespread exploitation; the vuln.today priority is 'this_week' rather than act_now/emergency. The real-world weight of this issue is therefore concentrated in multi-tenant / multi-project Incus deployments where project restriction is the trust boundary - in such environments this is a genuine priority because it defeats the isolation control directly and needs only valid low-privilege credentials, whereas single-tenant or single-project deployments face materially lower exposure. One data point to verify: the Description states fixed versions 7.0.2 and 7.5.0 across two branches, while the GitHub advisory's package metadata lists only 'fixed in >= v7.5.0' - confirm whether a 7.0.2 backport fix exists for the 7.0.x branch before relying on it.

A tenant who legitimately holds permission to create custom volumes in their own project sends a crafted POST to the custom-volumes API that names a source volume but omits source.type and sets source.project to a victim project. Because the source-volume access (can_view) check lives only in the explicit 'copy' arm of the type switch, the empty-type request reaches the copy helper unchecked, copying the victim's volume, snapshots, and configuration into the attacker's project where their contents can be read. No public exploit code was identified, but the official client cannot trigger this (it always sets source.type=copy), so a raw/crafted API request is required.