Canonical LXD Project Existence Determination Through Error Handling in Image Get FunctionGHSA-xch9-h8qw-85c7
MEDIUMGHSA-xch9-h8qw-85c7 is a medium-severity (CVSS 5.3) CWE-209 vulnerability in github.com/canonical/lxd. A fix is available for github.com/canonical/lxd — see the affected versions and patch details below.
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 GHSA-xch9-h8qw-85c7.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
github.com/canonical/lxd🐹github.com/canonical/lxd🐹github.com/canonical/lxdReal-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
The LXD /1.0/images endpoint is implemented as an AllowUntrusted API that requires no authentication, making it accessible to users without accounts. This API allows determining project existence through differences in HTTP status codes when accessed with the project parameter.
https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/images.go#L63-L69
This configuration allows access without authentication:
This API returns a 404 error when accessing existing projects and a 403 error when accessing non-existent projects, allowing confirmation of project existence through this difference.
The problematic implementation is shown below.
First, in the error handling implementation of the imagesGet function below, project existence is checked within the projectutils.ImageProject function, and the err returned by the ImageProject function is directly returned to the user.
https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/i mages.go#L1781-L1788
When the project doesn't exist, the error is 404 (http.StatusNotFound), which is returned to the user:
On the other hand, when the project exists but the user lacks viewing permissions, the imagesGet function returns 403 (response.Forbidden):
Reproduction Steps
- Send the following request without authentication to a non-existent project:
curl -k "https://lxd-host:8443/1.0/images?project=XXX-project"
Response:
{"type":"error","status":"","status_code":0,"operation":"","error_code":404,"error":"fetch project: Project not found","metadata":null}
- Send a request without authentication to an existing project (if a public project exists, it will be included in the response):
curl -k "https://lxd-host:8443/1.0/images?project=exist-project"
Reponse:
{"type":"error","status":"","status_code":0,"operation":"","error_code":403,"error":"Untrusted callers may only access public images in the default project","metadata":null}
Risk
The attack requires only network access to the LXD API endpoint, with no authentication needed.
The attack allows confirming the existence of projects within the LXD system by exploiting differences in HTTP status codes. This could potentially increase the exploitability of othervulnerabilities.
Additionally, since project IDs often use meaningful names set by users, this could lead to leakage of unpublished product information. However, resource information within projects cannot be obtained, limiting the impact to existence confirmation only.
Countermeasures
It is recommended to modify the error handling in the imagesGet function to return consistent responses regardless of project existence. Specifically, when an error occurs during project existence verification, the implementation should be changed to always return a 403 (Untrusted callers may only access public images in the default project) error to unauthenticated users.
This ensures that the same error response is returned for both existing and non-existing projects, preventing determination of project existence.
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
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/canonical/lxd | ≥ 4.0&&< 5.21.4 | 5.21.4go get github.com/canonical/lxd@v5.21.4 |
| 🐹Go | github.com/canonical/lxd | ≥ 6.0&&< 6.5 | 6.5go 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-0494f5d47e41go get github.com/canonical/lxd@v0.0.0-20250827065555-0494f5d47e41 |
Affected Products
lxdcanonicalDetection & mitigation playbook
Open-source dependencyDetect
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 GHSA-xch9-h8qw-85c7 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
Is GHSA-xch9-h8qw-85c7 in your dependencies?
Find it across Go, including transitive dependencies.