CVE-2026-81501
Published:October 12, 2026
Updated:October 13, 2026
Summary A project-restricted TLS client that cannot "GET /1.0/images/{fingerprint}" for a private image in another project can still import that same fingerprint into their own project. "imageDownload" reuses any matching local image via "GetImageFromAnyProject" without checking "Public" or "CanView". Image blobs are stored globally under "var/images/<fingerprint>", so the caller receives the private image properties and files. This is the image-object counterpart of GHSA-c9f5-j9c3-mhrg (instance copy from "req.Source.Project" without "CanView"). It is not a privileged-container escape. ### Affected - Runtime reproduction: Ubuntu 24.04 package Incus 6.0.0 ("6.0.0-1ubuntu0.3") in an isolated Docker environment. - Same unguarded call is present on "lxc/incus" at "v7.3.0-432-gf216a6d46" in "cmd/incusd/daemon_images.go". - Full release range should be confirmed by maintainers. ### Contrast (same restricted client, same fingerprint) | Request | Result | | --- | --- | | "GET /1.0/images/<fp>?project=default" | 404 ("imageGet" requires "CanView" or public/secret) | | "POST /1.0/images?project=hunt-b" with "source.type=image" pulling from an attacker HTTPS server that only echoes "<fp>" | operation Success; image now listed in "hunt-b" with the victim "properties" | The attacker server never supplies image bytes. Incus clones the local private record and files. A harmless marker ("INCUS-HUNT-MARKER") in the victim image properties appears in the attacker project. ### Impact A restricted client with "CanCreateImages" (or the ability to create an instance from an image) in their own project, who already knows a private image fingerprint from another project, can: - copy that image's properties and global blob into their project; - then view, export, or launch instances from it inside their project. This breaks Incus project isolation for private images. Limitation: the 64-hex fingerprint is not returned by "GET" / list to a caller without "CanView". The attacker must obtain it out of band (logs, backups, a former project membership, a predictable custom image, etc.). No victim interaction is required after that. ### Root cause "imageGet" / "imagesGet" / "imageExport" apply "CheckPermission(ObjectImage, CanView)" and hide private images behind 404. "imageDownload", after a dest-project miss, does: "go _, imgInfo, err = tx.GetImageFromAnyProject(ctx, fp) // then CreateImage into the caller project — no Public / CanView check " Reachable from: - "POST /1.0/images" with "source.type=image" - "POST /1.0/instances" when "source.server != """ "AllowImageDownload" only enforces "restricted.images.servers" (remote host allowlist). It is not an object-level "CanView" check. ### Suggested fix After "GetImageFromAnyProject" succeeds, only reuse the local image if: 1. "imgInfo.Public" is true, or 2. "CheckPermission" on "ObjectImage(imgInfo.Project, fingerprint)" with "EntitlementCanView" succeeds. Otherwise continue with a real remote download. Do not copy the private local image. ### Dedup Not a duplicate of: - GHSA-mq9x-prm8-3vpw / GHSA-c9f5-j9c3-mhrg — instance copy "Source.Project" without "CanView" (same class, different object and entry point) - GHSA-p8mm-23gg-jc9r — simplestreams concatenated fingerprint - GHSA-f6m5-xw2g-xc4x / GHSA-p2v3-6wvc-cv3p — fingerprint used as a filesystem path - GHSA-8gw4-p4wq-4hcv — URL import HEAD SSRF - Incus 7.3 leftover name-as-path / OpenRoot issues ### PoC Isolated Docker environment attached as "incus-private-image-anyproject.zip". "bash unzip incus-private-image-anyproject.zip cd incus-private-image-anyproject ./run.sh " Expected: "all_checks_passed: true", "verdict=private_image_cross_project_reuse_reproduced_at_runtime". The container starts Ubuntu 24.04 + distro Incus 6.0.0, creates a private image in "default" (marker in "properties.description"), a project "hunt-b", and a restricted TLS cert bound only to "hunt-b". It then runs the contrast above. Harmless marker only; no instance is launched. "results/runtime.json" from our run is included. ### Severity Medium. Suggested: "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N" = 6.3. | Metric | Value | Reason | | --- | --- | --- | | AV | N | HTTPS API | | AC | H | 64-hex fingerprint required; not enumerable via GET/list (404) | | PR | L | project-restricted TLS client with image-create rights, not admin | | UI | N | no victim interaction | | S | C | breaks project isolation (same Scope as GHSA-c9f5) | | C | H | full private image (properties + rootfs blob) | | I | N | victim image is not modified | | A | N | no availability impact | If maintainers treat fingerprint knowledge like instance-name knowledge in GHSA-c9f5, the matching vector is "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N" = 7.7. I am reporting 6.3. ### Credit Yuliang Xiao
Affected Packages
https://github.com/lxc/incus.git (GITHUB):
Affected version(s) >=v0.1.0 <v7.4.0Fix Suggestion:
Update to version v7.4.0github.com/lxc/incus/v7 (GO):
Affected version(s) >=v7.1.0 <v7.4.0Fix Suggestion:
Update to version v7.4.0github.com/lxc/incus (GO):
Affected version(s) >=v0.1.0 <v7.4.0Fix Suggestion:
Update to version v7.4.0Related Resources (3)
Do you need more information?
Contact UsCVSS v4
Base Score:
7
Attack Vector
NETWORK
Attack Complexity
HIGH
Attack Requirements
NONE
Privileges Required
LOW
User Interaction
NONE
Vulnerable System Confidentiality
HIGH
Vulnerable System Integrity
NONE
Vulnerable System Availability
NONE
Subsequent System Confidentiality
HIGH
Subsequent System Integrity
NONE
Subsequent System Availability
NONE
CVSS v3
Base Score:
6.3
Attack Vector
NETWORK
Attack Complexity
HIGH
Privileges Required
LOW
User Interaction
NONE
Scope
CHANGED
Confidentiality
HIGH
Integrity
NONE
Availability
NONE
Weakness Type (CWE)
Improper Access Control