How severe is GHSA-7232-97c6-j525?

GHSA-7232-97c6-j525 has a CVSS score of 4.1/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-7232-97c6-j525?

GHSA-7232-97c6-j525 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 GHSA-7232-97c6-j525?

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 GHSA-7232-97c6-j525 is resolved across your whole dependency graph.

How do I detect GHSA-7232-97c6-j525 in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/canonical/lxd. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-7232-97c6-j525 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.

How does O3 Security protect against GHSA-7232-97c6-j525?

O3 pinpoints whether GHSA-7232-97c6-j525 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-7232-97c6-j525 actively exploited in the wild?

No public exploit code has been indexed for GHSA-7232-97c6-j525 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 GHSA-7232-97c6-j525?

GHSA-7232-97c6-j525 has an EPSS (Exploit Prediction Scoring System) score of 0.3%, placing it in the 23th 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 GHSA-7232-97c6-j525?

GHSA-7232-97c6-j525 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 GHSA-7232-97c6-j525 published, and has it been updated?

GHSA-7232-97c6-j525 was published on October 2, 2025 and was last updated on February 4, 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

GHSA-7232-97c6-j525

MEDIUM

Canonical LXD Source Container Identification Vulnerability via cmdline Spoofing in devLXD Server

Also known asCVE-2025-54288GO-2025-4001

Published

Oct 2, 2025

Updated

Feb 4, 2026

Affected

3 pkgs

Patched

3 / 3

Exploits

None indexed

EPSS Exploitation Probability

via FIRST.org ↗

0.3%probability of exploitation in next 30 days

Lower Risk23th percentile+0.26%

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

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	`github.com/canonical/lxd`	≥ 6.0&&< 6.5	6.5
🐹Go	`github.com/canonical/lxd`	≥ 0.0.0-20200331193331-03aab09f5b5c&&< 0.0.0-20250827065555-0494f5d47e41	0.0.0-20250827065555-0494f5d47e41

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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 GHSA-7232-97c6-j525 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.
How O3 protects you
O3 pinpoints whether GHSA-7232-97c6-j525 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-7232-97c6-j525. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

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 GHSA-7232-97c6-j525 in your dependencies?

O3 detects GHSA-7232-97c6-j525 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works