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

CVE-2026-55622: Incus Project Restriction Bypass in Instance Copy

Rohit Hatagale
AI Security Researcher, SecureLayer7

A restricted Incus user who knows the name of a project and instance they should not be able to access can copy that instance into a project they do control, exposing any secrets stored inside it.

Packagegithub.com/lxc/incus/v7/cmd/incusd
Ecosystemgo
Affected< 7.2.0
Fixed in7.2.0
CVE-2026-55622: Incus Project Restriction Bypass in Instance Copy

The problem

Incus restricts TLS clients to specific projects using a certificate trust configuration. When a client POSTs to /1.0/instances to create an instance via copy, the server checks only whether the caller can create in the *target* project.

The source instance is loaded from req.Source.Project in cmd/incusd/instances_post.go with no check that the caller has read access to that source project. Any restricted user who can guess a project name and instance name can exfiltrate that instance.

Proof of concept

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

http
POST /1.0/instances?project=default HTTP/1.1
Host: 192.0.2.1:8443
Content-Type: application/json

{
  "name": "copy-secret",
  "source": {
    "type": "copy",
    "source": "secret",
    "project": "secrets",
    "instance_only": false
  },
  "start": false
}

The authorization gate in cmd/incusd/instances.go calls CanViewInstance (or equivalent) only for the target project. In the copy branch of instances_post.go, the code immediately fetches the source instance using req.Source.Project before any access check on that project is performed.

The fix in commit 1e3ffc53 (PR #3542, released in v7.2.0) adds an explicit authorization check against the source project and instance before the copy proceeds, closing the TOCTOU-style gap. CWE-284 (Improper Access Control) is the root cause: the copy subpath simply did not inherit the same authz logic applied to other read operations.

The fix

Upgrade to Incus 7.2.0 or later. The fix is in commit 1e3ffc53a10950e55de62ac1e0d612be597b84eb (PR #3542), which adds a source-instance authorization check in cmd/incusd/instances_post.go before the copy is executed. Incus 7.0 LTS users should apply the backport available from their distribution.

No workaround exists short of disabling cross-project copy or ensuring project names and instance names are unguessable.

Reported by stgraber (Stéphane Graber).

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

Related research