LXD CVE-2026-63298

Exploitation requires the attacker to hold an authenticated LXD identity with at minimum instance-creation or instance-configuration modification privileges - corresponding to PR:L in the CVSS vector (membership in the lxd group or equivalent API access). The target LXD host must have NVIDIA GPU passthrough support configured and must be running at least one instance (or allow the attacker to create one) that uses the nvidia.driver.capabilities or nvidia.require.* configuration keys. LXD deployments that do not use NVIDIA GPU passthrough at all are not vulnerable to this specific injection path, as the vulnerable code path is only triggered during NVIDIA config processing. Exploitation does not require administrator privileges, victim interaction, or non-standard network positioning - the LXD API endpoint is targeted directly over the network (AV:N). The primary limiting factor is the requirement for a valid, low-privilege LXD account; unauthenticated external attackers cannot exploit this vulnerability.

The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H scores 8.7 and is well-grounded in the attack mechanics: the LXD API is network-accessible, exploitation requires no special conditions beyond a valid low-privilege LXD identity, and injected lxc.conf directives affect the host rather than the container, producing the scope change (S:C) with full C/I/A impact. The low complexity and low privilege bar mean that even a mid-sized municipal IT team in tczew running shared LXD infrastructure for development workloads should treat this as urgent, particularly if NVIDIA GPU passthrough is enabled for ML or compute tenants. No CISA KEV entry has been identified, and no public POC has surfaced at time of analysis, which moderately lowers immediacy compared to actively-exploited container escapes. No EPSS score was provided in the input data, so probability-of-exploitation cannot be numerically assessed; however, the conceptual simplicity of the attack - injecting a known config file format via a single field - and the high-value outcome of host-level code execution as the LXD daemon (typically running with root or near-root privileges) argue for treating exploitation probability as non-trivial. The wildcard CPE version range suggests the fix version has not yet been confirmed, introducing additional residual exposure until the advisory is updated.

An authenticated LXD user with instance-creation rights sets nvidia.driver.capabilities to a value such as compute,utility\nlxc.apparmor.profile=unconfined\nlxc.cap.keep=sys_admin - embedding newlines to inject additional directives. When LXD generates lxc.conf and starts the instance, the LXC runtime processes the injected lxc.apparmor.profile=unconfined and capability directives as legitimate configuration, stripping the container's confinement. The attacker then uses the unconfined container to mount the host filesystem or exploit elevated capabilities to execute arbitrary commands on the host as the LXD daemon. No public POC has been identified, but the technique requires only knowledge of lxc.conf directive syntax.