How severe is CVE-2025-54288?

No CVSS score has been assigned to CVE-2025-54288 yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by CVE-2025-54288?

CVE-2025-54288 affects the following packages: github.com/canonical/lxd (Go), github.com/canonical/lxd (Go), github.com/canonical/lxd (Go). Ecosystems affected: Go.

How do I fix CVE-2025-54288?

Update github.com/canonical/lxd to 5.21.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2025-54288 is resolved across your whole dependency graph.

How do I detect CVE-2025-54288 in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/canonical/lxd, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate CVE-2025-54288 if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Is CVE-2025-54288 actively exploited in the wild?

No public exploit code has been indexed for CVE-2025-54288 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for CVE-2025-54288?

CVE-2025-54288 has an EPSS (Exploit Prediction Scoring System) score of 0.4%, placing it in the 29th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2025-54288?

CVE-2025-54288 is classified as CWE-290 (CWE-290). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was CVE-2025-54288 published, and has it been updated?

CVE-2025-54288 was published on October 2, 2025 and was last updated on October 28, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹 Go

Not in CISA KEV

CVE-2025-54288 — lxd

CVE-2025-54288 is a CWE-290 vulnerability in github.com/canonical/lxd. A fix is available for github.com/canonical/lxd — see the affected versions and patch details below.

Source Container Identification Vulnerability via cmdline Spoofing in devLXD Server

Also known asGHSA-7232-97c6-j525GO-2025-4001

Published

Oct 2, 2025

Updated

Oct 28, 2026

Affected

3 pkgs

Patched

3 / 3

Exploits

None indexed

Exploitation data as of Nov 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for CVE-2025-54288.

EPSS Exploitation Probability

via FIRST.org ↗

0.4%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs29th percentile — riskier than 29% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

3 pkgs affected

🐹github.com/canonical/lxd🐹github.com/canonical/lxd🐹github.com/canonical/lxd

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Impact

In LXD's devLXD server, the source container identification process uses process cmdline (command line) information, allowing attackers to impersonate other containers by spoofing process names.

The core issue lies in the findContainerForPID function in lxd/api_devlxd.go. This function identifies senders through two steps as shown below:

cmdline-based identification: Check while tracing back through parent processes, and if it starts with [lxc monitor], extract the project name and container name from that process name in the format projectName_containerName.
PID namespace-based identification: If not found in Step 1, check against all containers' PID namespaces.

https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/api_devlxd.go#L166-L276

Attackers can exploit Step 1 processing to impersonate arbitrary containers across projects by spoofing process names.

Reproduction Steps

Access devLXD server from a normal container (e.g., EEEE):

root@EEEE:~# curl --unix-socket /dev/lxd/sock http://lxd-host/1.0/meta-data
instance-id: 9f928574-2561-4eff-af82-a68e57d3c68b
local-hostname: EEEE

Use exec -a to spoof process name and impersonate another container (DDDD):

root@EEEE:~# bash -c "exec -a '[lxc monitor]' curl --unix-socket /dev/lxd/sock http://lxd-host/1.0/meta-data -x 'test-project_DDDD'"
instance-id: 1bb2f1c3-3ad2-4cd6-9965-67b14c3582cc
local-hostname: DDDD

This attack successfully obtains metadata (instance-id, local-hostname) of another container DDDD from within container EEEE.

Risk

This vulnerability allows attackers to perform the following actions:

Theft of other containers' metadata information Obtaining other containers' information via devLXD API's /1.0/meta-data endpoint: https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/devlxd.go#L295-L304
Obtaining other containers' configuration information via devLXD API's /1.0/config and /1.0/config/{key} endpoints: https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/devlxd.go#L175-L221 https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/devlxd.go#L228-L267
Obtaining other containers' device information via devLXD API's /1.0/devices endpoint: https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/devlxd.go#L377-L395 Particularly in environments where multiple projects run containers on the same LXD host, inter-project information leakage may occur. The attack prerequisite is root privileges within any container.

Countermeasures

While containers basically run in separate PID namespaces, based on investigation, the [lxc monitor] process runs in the same PID namespace as the LXD execution process. Therefore, the problem can be resolved by modifying the implementation to use cmdline information only when the PID namespace of the target process matches the PID namespace of the process running LXD.

Patches

LXD Series	Status
6	Fixed in LXD 6.5
5.21	Fixed in LXD 5.21.4
5.0	Ignored - Not critical
4.0	Ignored - EOL and not critical

References

Reported by GMO Flatt Security Inc.

Affected Packages

3 total 3 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/canonical/lxd`	≥ 4.0&&< 5.21.4	5.21.4`go get github.com/canonical/lxd@v5.21.4`
🐹Go	`github.com/canonical/lxd`	≥ 6.0&&< 6.5	6.5`go get github.com/canonical/lxd@v6.5`
🐹Go	`github.com/canonical/lxd`	≥ 0.0.0-20200331193331-03aab09f5b5c&&< 0.0.0-20250827065555-0494f5d47e41	0.0.0-20250827065555-0494f5d47e41`go get github.com/canonical/lxd@v0.0.0-20250827065555-0494f5d47e41`

Affected Products

1 product · 2 configurations

Application

lxdcanonical

≥ 6.1 && < 6.5

range

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/canonical/lxd, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/canonical/lxd to 5.21.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2025-54288 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

### Impact In LXD's devLXD server, the source container identification process uses process cmdline (command line) information, allowing attackers to impersonate other containers by spoofing process names. The core issue lies in the findContainerForPID function in `lxd/api_devlxd.go`. This function identifies senders through two steps as shown below: 1. cmdline-based identification: Check while tracing back through parent processes, and if it starts with `[lxc monitor]`, extract the project name and container name from that process name in the format projectName_containerName. 2. PID namesp

O3 Security · Impact-Aware SCA

Is CVE-2025-54288 in your dependencies?

Find it across Go, including transitive dependencies.

Scan my dependencies How O3 SCA works