GHSA-xch9-h8qw-85c7
MEDIUMCanonical LXD Project Existence Determination Through Error Handling in Image Get Function
EPSS Exploitation Probability
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
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.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 dependencyDetect
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-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.
How O3 protects you
O3 pinpoints whether GHSA-xch9-h8qw-85c7 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-xch9-h8qw-85c7. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-xch9-h8qw-85c7 in your dependencies?
O3 detects GHSA-xch9-h8qw-85c7 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.