Canonical LXD EUVD-2026-39805

Exploitation requires an authenticated LXD API session with the can_create_images entitlement granted to the user or group - this entitlement is not held by all authenticated users by default and must be explicitly assigned. The LXD server must be reachable over the network (core.https_address must be configured), or the attacker must have local access to the Unix socket. The vulnerability is most impactful when the LXD host has network access to cloud metadata endpoints or internal management interfaces (e.g., Kubernetes API, internal HTTP services), which is common in cloud VM deployments. Exploitation is limited to read-side reconnaissance (error-based SSRF with partial confidentiality impact); no integrity or availability impact has been identified. The can_create_images entitlement requirement limits exploitation to users trusted enough to import container images, reducing but not eliminating risk in multi-tenant environments.

The CVSS 3.1 base score of 5.0 (Medium) with vector AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N accurately reflects the threat model: network-accessible, low complexity, but gated behind authenticated access with the can_create_images entitlement. The Scope:Changed flag elevates significance by acknowledging cross-boundary impact to internal services. In cloud environments where the LXD host can reach the instance metadata service, even error-based SSRF can yield sensitive information such as IAM credentials or user-data scripts, meaningfully increasing real-world impact beyond the nominal C:L score. There is no CISA KEV listing and no known public exploit code, which lowers operational urgency for most deployments. EPSS data was not provided in source intelligence; absence of KEV and POC suggests this is a newly disclosed vulnerability without active mass exploitation. The primary risk concentrates in multi-tenant LXD deployments (e.g., hosting providers, CI/CD platforms) where the can_create_images entitlement is granted to semi-trusted users who could use it to pivot from the LXD API toward internal infrastructure.

An attacker with a valid LXD API credential and can_create_images entitlement submits a POST request to the /images endpoint specifying a URL such as http://169.254.169.254/latest/meta-data/ or an internal RFC1918 address with varying port numbers. The LXD daemon initiates the connection from the host's network stack; the nature of the HTTP error response (connection refused, timeout, HTTP status code) discloses whether a port is open and what service may be running, enabling systematic internal port scanning and potential exfiltration of cloud instance metadata. No public POC has been identified, but the technique requires no special tooling beyond standard HTTP API calls.