Canonical LXD CVE-2026-86335

Requires a multi-tenant LXD deployment using project isolation where the attacker holds a valid but project-restricted client credential (PR:L, not remote-unauthenticated). Exploitation is limited to image/instance import operations and depends on reusing the local fingerprint of a private image already cached in another project on the same host - a narrow, timing/state-dependent condition (AC:H). It only yields read access to other projects' private images (confidentiality); it does not grant authentication bypass, code execution, or write/DoS impact, and single-project or non-shared LXD hosts are not exposed.

This is a genuine but moderate-severity access-control flaw, not a critical one. The vendor CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N = 6.3) is internally consistent with the description: exploitation requires an already-authenticated, project-restricted client (PR:L), succeeds only under specific race/reuse conditions around fingerprint reuse during import (AC:H), crosses a project trust boundary (S:C), and leaks confidential image contents with no integrity or availability impact (C:H/I:N/A:N). No EPSS score, no CISA KEV listing, and no public POC were provided, so all three exploitation-likelihood signals are absent - meaning no public exploit identified at time of analysis. The combination of high attack complexity, required prior authentication, and the narrow, information-disclosure-only impact (private images from other projects on the same LXD host) places this firmly in the 'real but low-urgency' band rather than a high-CVSS-but-hollow issue or an emergency. Note the CVSS is vendor/Canonical self-assessed; the AC:H rating hinges on the fingerprint-reuse timing described, which is plausible given the patch adds explicit cached-image source binding and TOCTOU-safe file handling.

An attacker who already holds a project-restricted LXD client credential on a shared multi-tenant LXD host triggers an image or instance import and supplies (or races) a fingerprint that matches a private image already cached in another project. Because LXD's imageDownload path resolved the fingerprint against any project without authorization, the attacker's project receives a record and file for the other tenant's private image, disclosing its contents. No public exploit code was identified, and success depends on the high-complexity fingerprint-reuse timing described by the vendor.