Canonical LXD CVE-2025-54288

Exploitation requires the attacker to already have root privileges inside an existing LXD container and local access to the devLXD endpoint (/dev/lxd/sock), which is exposed to containers by default. The specific technique is overriding the process command line via a shell exec -a '[lxc monitor]' wrapper so the findContainerForPID function in lxd/api_devlxd.go matches the attacker's forged projectName_containerName string. Limiting factors that reduce real-world risk: it is meaningful only on multi-container / multi-project hosts where other containers hold data worth stealing; it is read-only (metadata, config via /1.0/config, and devices via /1.0/devices - no modification); and it confers no benefit on single-tenant hosts since root in one container there is already fully trusted. Not remotely exploitable without first compromising a container to root.

This is a genuine but moderate-priority issue, not an urgent emergency. The input CVSS 4.0 vector scores 5.1 (Medium) and requires PR:H - the attacker must already hold root inside a container - so this is a privilege/isolation-boundary weakness rather than a remote entry point. EPSS is very low (0.06%, 17th percentile), the CVE is NOT in CISA KEV (no active-exploitation signal), and impact is confidentiality-only (VC:L/SC:L; no integrity or availability effect). Counterbalancing this, a fully working proof-of-concept with copy-paste reproduction steps is published in the vendor GHSA advisory, which raises practical exploitability for anyone already on a shared host. CONFLICTING SIGNAL: the vendor vector sets AV:N, but the described attack is executed against the local devLXD unix socket (/dev/lxd/sock) from inside a container using exec -a - that is a local vector, not network-reachable, so AV:N appears overstated; verify adjacency assumptions with the vendor. Net: prioritize patching on multi-tenant / multi-project LXD hosts where cross-container confidentiality matters; deprioritize on single-tenant hosts where all containers already share one trust domain.

On a shared LXD host running containers for multiple tenants/projects, an attacker who has obtained root inside one container runs bash -c "exec -a '[lxc monitor]' curl --unix-socket /dev/lxd/sock http://lxd-host/1.0/meta-data -x 'otherproject_victim'" to make the devLXD server misidentify the request as coming from a different container. The server then returns the victim container's metadata, configuration, and device information. A publicly available proof-of-concept with exact reproduction steps exists in the Canonical GHSA advisory.