How severe is GHSA-x9qq-236j-gj97?

No CVSS score has been assigned to GHSA-x9qq-236j-gj97 yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-x9qq-236j-gj97?

GHSA-x9qq-236j-gj97 affects the following packages: github.com/canonical/lxd (Go), github.com/canonical/lxd (Go). Ecosystems affected: Go.

How do I fix GHSA-x9qq-236j-gj97?

Update github.com/canonical/lxd to 5.20.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-x9qq-236j-gj97 is resolved across your whole dependency graph.

How do I detect GHSA-x9qq-236j-gj97 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-x9qq-236j-gj97 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-x9qq-236j-gj97?

O3 pinpoints whether GHSA-x9qq-236j-gj97 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-x9qq-236j-gj97 actively exploited in the wild?

No public exploit code has been indexed for GHSA-x9qq-236j-gj97 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.

When was GHSA-x9qq-236j-gj97 published, and has it been updated?

GHSA-x9qq-236j-gj97 was published on December 5, 2023 and was last updated on July 22, 2025. 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-x9qq-236j-gj97

Canonical LXD documentation improvement to make clear restricted.devices.disk=allow without restricted.devices.disk.paths also allows shift=true

Published

Dec 5, 2023

Updated

Jul 22, 2025

Affected

2 pkgs

Patched

2 / 2

Exploits

None indexed

Blast Radius

2 pkgs affected

🐹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

Summary

If a user has restricted access to a project that is configured with restricted=true, they can gain root access on the system by creating a disk device with shift=true and creating a setuid root executable. This is possible because the shift property is not restricted unless restricted.devices.disk.paths is set.

Details

The following patch shows the offending code with a possible fix:

--- a/lxd/device/disk.go
+++ b/lxd/device/disk.go
@@ -429,17 +429,19 @@ func (d *disk) validateEnvironmentSourcePath() error {
        if instProject.Name != api.ProjectDefaultName {
                // If restricted disk paths are in force, then check the disk's source is allowed, and record the
                // allowed parent path for later user during device start up sequence.
-               if shared.IsTrue(instProject.Config["restricted"]) && instProject.Config["restricted.devices.disk.paths"] != "" {
-                       allowed, restrictedParentSourcePath := project.CheckRestrictedDevicesDiskPaths(instProject.Config, d.config["source"])
-                       if !allowed {
-                               return fmt.Errorf("Disk source path %q not allowed by project for disk %q", d.config["source"], d.name)
+               if shared.IsTrue(instProject.Config["restricted"]) {
+                       if instProject.Config["restricted.devices.disk.paths"] != "" {
+                               allowed, restrictedParentSourcePath := project.CheckRestrictedDevicesDiskPaths(instProject.Config, d.config["source"])
+                               if !allowed {
+                                       return fmt.Errorf("Disk source path %q not allowed by project for disk %q", d.config["source"], d.name)
+                               }
+
+                               d.restrictedParentSourcePath = shared.HostPath(restrictedParentSourcePath)
                        }

                        if shared.IsTrue(d.config["shift"]) {
                                return fmt.Errorf(`The "shift" property cannot be used with a restricted source path`)
                        }
-
-                       d.restrictedParentSourcePath = shared.HostPath(restrictedParentSourcePath)
                }
        }

PoC

$ lxc project create restricted -c restricted=true -c restricted.devices.disk=allow
$ lxc project switch restricted
$ lxc profile device add default root disk path=/ pool=default
$ lxc init ubuntu:22.04 c1
$ lxc config device add c1 d1 disk source=/ path=/mnt shift=true
$ lxc start c1  # no error

$ lxc project set restricted restricted.devices.disk.paths=/  # explicitly allow mounting /
$ lxc restart c1
Error: Failed to start device "d1": The "shift" property cannot be used with a restricted source path

Created https://github.com/canonical/lxd/issues/12606 to improve the documentation as per https://github.com/canonical/lxd/security/advisories/GHSA-x9qq-236j-gj97#advisory-comment-91918

Affected Packages

2 total 2 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/canonical/lxd`	≥ 5.19.0&&< 5.20.0	5.20.0
🐹Go	`github.com/canonical/lxd`	≥ 0.0.0-20230920084527-cbe39c5d3f14&&< 0.0.0-20240118092008-ce1bd0dd37bb	0.0.0-20240118092008-ce1bd0dd37bb

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.20.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-x9qq-236j-gj97 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-x9qq-236j-gj97 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-x9qq-236j-gj97. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary If a user has restricted access to a project that is configured with `restricted=true`, they can gain root access on the system by creating a disk device with `shift=true` and creating a setuid root executable. This is possible because the `shift` property is not restricted unless `restricted.devices.disk.paths` is set. ### Details The following patch shows the offending code with a possible fix: ```patch --- a/lxd/device/disk.go +++ b/lxd/device/disk.go @@ -429,17 +429,19 @@ func (d *disk) validateEnvironmentSourcePath() error { if instProject.Name != api.ProjectDefault

O3 Security · Impact-Aware SCA

Is GHSA-x9qq-236j-gj97 in your dependencies?

O3 detects GHSA-x9qq-236j-gj97 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