4.1

CVSS Score

3.1

Basic Information

CVE ID

CVE-2025-54288

GHSA ID

GHSA-7232-97c6-j525

EPSS Score

0.09466%

CWE

CWE-290

Published

10/2/2025

Updated

10/2/2025

KEV Status

Technology

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2025-54288

CVE-2025-54288: Canonical LXD Source Container Identification Vulnerability via cmdline Spoofing in devLXD Server

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.

(GitHub Advisory)

4.1

CVSS Score

3.1

Basic Information

CVE ID

CVE-2025-54288

GHSA ID

GHSA-7232-97c6-j525

EPSS Score

0.09466%

CWE

CWE-290

Published

10/2/2025

Updated

10/2/2025

KEV Status

Technology

Technical Details

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
github.com/canonical/lxd	go	>= 4.0, < 5.21.4	5.21.4
github.com/canonical/lxd	go	>= 6.0, < 6.5	6.5
github.com/canonical/lxd	go	>= 0.0.0-20200331193331-03aab09f5b5c, < 0.0.0-20250827065555-0494f5d47e41	0.0.0-20250827065555-0494f5d47e41

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability, as described, is a container identification spoofing issue in Canonical's LXD. The root cause is the reliance on process command-line information (cmdline) to identify a container, without sufficient verification of the process's actual origin. An attacker with root in one container could launch a process with a spoofed name, making it appear to be the monitor process for a different container.

The analysis of the provided patches confirms this. The key change is the replacement of the loadContainerFromLXCMonitorPID function, which only parsed the command line, with a new function getLXCMonitorContainer. This new function adds a critical security check: it verifies the PID namespace of the process by reading the NSpid field from /proc/<pid>/status. If a process is running in a different PID namespace, it cannot be the legitimate monitor process, even if its name is spoofed.

Two primary vulnerable functions were identified that used this flawed logic:

devlxdFindContainerForPID in lxd/api_devlxd.go: This was the main function responsible for mapping a process ID to a container for devLXD API requests. The patch shows the removal of the loop that walked the process tree and called the insecure loadContainerFromLXCMonitorPID.
An anonymous function within (*Daemon).init() in lxd/daemon.go: This function serves as a seccomp handler and also used loadContainerFromLXCMonitorPID to identify containers from PIDs. This provided a second vector for the same attack.

By exploiting these functions, an attacker could bypass container isolation and access sensitive information from other containers on the same host, including metadata, configuration, and device information. The fix, applied in both locations, mitigates this by ensuring the process's PID namespace is validated, preventing the spoofing attack. Security teams should ensure they have patched to LXD 5.21.4 or 6.5 to remediate this vulnerability.

Vulnerable functions

devlxdFindContainerForPID

lxd/api_devlxd.go

This function was the primary entry point for the vulnerability. It attempted to find the container for a given process ID by walking up the process tree and inspecting the command line of parent processes. It used the `loadContainerFromLXCMonitorPID` function, which was insecure because it trusted the process name (`cmdline`) to identify the container. An attacker with root privileges in one container could spoof the process name to impersonate another container and gain access to its metadata, configuration, and devices via the devLXD API. The fix involves using `getLXCMonitorContainer` which adds a crucial check of the PID namespace to prevent this spoofing.

(*Daemon).init.func1

lxd/daemon.go

This anonymous function, used as a seccomp handler, was another entry point for the vulnerability. It directly called the insecure `loadContainerFromLXCMonitorPID` function to identify a container based on a PID from the seccomp listener. This made it vulnerable to the same command line spoofing attack as `devlxdFindContainerForPID`. The patch replaces the call with `getLXCMonitorContainer` to ensure the PID namespace is verified.

WAF Protection Rules

WAF Rule

### Imp**t In LX*'s **vLX* s*rv*r, t** sour** *ont*in*r i**nti*i**tion pro**ss us*s pro**ss *m*lin* (*omm*n* lin*) in*orm*tion, *llowin* *tt**k*rs to imp*rson*t* ot**r *ont*in*rs *y spoo*in* pro**ss n*m*s. T** *or* issu* li*s in t** *in**ont*in*r*or

Reasoning

T** vuln*r**ility, *s **s*ri***, is * *ont*in*r i**nti*i**tion spoo*in* issu* in **noni**l's LX*. T** root **us* is t** r*li*n** on pro**ss *omm*n*-lin* in*orm*tion (`*m*lin*`) to i**nti*y * *ont*in*r, wit*out su**i*i*nt v*ri*i**tion o* t** pro**ss's

4.1

Basic Information

Concerned about an active attack path?

CVE-2025-54288: Canonical LXD Source Container Identification Vulnerability via cmdline Spoofing in devLXD Server

Impact

Reproduction Steps

Risk

Countermeasures

Patches

References

4.1

Basic Information

Technical Details

Vulnerability IntelligenceMiggo AI

Root Cause Analysis

Vulnerable functions

WAF Protection Rules

WAF Rule

Reasoning

Vulnerability Intelligence
Miggo AI