Canonical LXD CVE-2025-54293

Requires an authenticated LXD account with access to the instance log retrieval/deletion endpoints (reachable via the LXD API or LXD-UI). The attacker supplies a log filename beginning with the snapshot_ or migration_ prefix whose trailing portion is insufficiently validated by validLogFileName in lxd/instance_logs.go, or a symbolic link; traversal succeeds specifically because Go's filepath.Join normalizes the path before kernel-level path checks would reject it. Exploitation is LIMITED to the LXD 5.0 LTS series and versions below 5.21.4 (6.x below 6.5); it needs valid authentication (PR:L, no unauthenticated path) but no user interaction, and the root-privileged daemon means successful reads expose any host file.

This is a genuine but moderate-priority issue, not a top-tier emergency. The CVSS 4.0 base score of 7.1 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) reflects a network-reachable, low-complexity attack that nonetheless requires authentication (PR:L) and yields confidentiality-only impact (arbitrary host file read, no integrity or availability loss). Multiple signals point AWAY from mass exploitation: EPSS is very low at 0.07% (20th percentile), and the CVE is NOT listed in CISA KEV, indicating no confirmed active exploitation. Counterbalancing this, a public proof-of-concept with full reproduction steps exists in the Canonical GHSA advisory, lowering the skill barrier. The requirement for a valid authenticated LXD account (LXD-UI or API access) is the key risk-limiter - this is a privilege-escalation/information-disclosure flaw usable by an already-trusted-but-restricted user, not an unauthenticated internet-facing RCE. Note a data tension worth verifying: the public description scopes the flaw to 'LXD 5.0 LTS,' while the EUVD/Go vulnerability database list the vulnerable ranges as >=4.0 <5.21.4 and >=6.0 <6.5 - the GHSA further states no dedicated security patch was backported to LXD 5.0 and earlier, so 5.0 LTS operators may remain exposed despite fixes existing in 5.21.4/6.5. Overall: a real, patch-worthy flaw for anyone running multi-tenant or restricted-user LXD, but low likelihood of opportunistic widespread exploitation.

An attacker holding a restricted but authenticated LXD account (for example a limited LXD-UI user) sends a crafted instance log-retrieval request whose filename abuses the snapshot_/migration_ prefix handling or a symbolic link to traverse out of the log directory. Because Go's filepath.Join normalizes the path before OS-level checks apply, the traversal succeeds and the root-privileged LXD daemon returns arbitrary host files such as /etc/shadow or TLS keys. A public proof-of-concept with step-by-step reproduction (including a browser DevTools script against LXD 5.0) is published in the Canonical GHSA advisory.