{"answers":{"affected":"3 open source packages ship an affected version, including github.com/canonical/lxd.","exploited":"There is no known exploitation of GHSA-3g2j-vm47-x4mj in the wild and no public exploit code.","fix":"Upgrade github.com/canonical/lxd to 0.0.0-20251110144034-698854d0164f or later.","what":"GHSA-3g2j-vm47-x4mj is a vulnerability in github.com/canonical/lxd, published on 13 Nov 2025. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for GHSA-3g2j-vm47-x4mj and fix it if it is affected.\n\nWhat it is: GHSA-3g2j-vm47-x4mj is a vulnerability in github.com/canonical/lxd, published on 13 Nov 2025. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of GHSA-3g2j-vm47-x4mj in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- github.com/canonical/lxd (Go): affected all versions; no fix listed\n- github.com/canonical/lxd (Go): affected all versions; fixed in 0.0.0-20251110144034-698854d0164f\n- github.com/canonical/lxd (Go): affected all versions; fixed in 0.0.0-20251110144034-698854d0164f\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/GHSA-3g2j-vm47-x4mj/ (Markdown: https://insights.sbomify.com/GHSA-3g2j-vm47-x4mj/index.md)","id":"GHSA-3g2j-vm47-x4mj","markdown":"https://insights.sbomify.com/GHSA-3g2j-vm47-x4mj/index.md","name":"GHSA-3g2j-vm47-x4mj","record":{"aliases":["GO-2025-4121"],"analysis":{"component_type":"container_or_infrastructure","fix_type":"patch","impacts":["privilege_escalation"],"network_reachable":"adjacent_or_local","non_default_config":true,"product_category":"LXD container manager","requires_auth":"low_privilege","summary":"An unprivileged user with container access can escalate to root on the host by exploiting custom storage volume permissions.","user_interaction":"not_required","vuln_class":"privilege_escalation"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"**Impact**\n\nThis affects any LXD user in an environment where an unprivileged user may have root access to a container with an attached custom storage volume that has the `security.shifted` property set to `true` as well as access to the host as an unprivileged user.\n\nThe most common case for this would be systems using `lxd-user` with the less privileged lxd group to provide unprivileged users with an isolated restricted access to LXD. Such users may be able to create a custom storage volume with the necessary property (depending on kernel and filesystem support) and can then write a setuid binary from within the container which can be executed as an unprivileged user on the host to gain root privileges.\n\n**Patches**\n\nPatches for this issue are available: \n\n- LXD 6 series: https://github.com/canonical/lxd/pull/16904\n- LXD 5.21 LTS series: https://github.com/canonical/lxd/pull/16922\n- LXD 5.0 LTS series: https://github.com/canonical/lxd/pull/16923\n- LXD 4.0 LTS series: https://github.com/canonical/lxd/pull/16924 \n\nThe first commit changes the permissions for any new storage pool, the later commit adds a patch that applies it on startup to all existing storage pools.\n\nThese fixes are also available in the associated candidate snap channels for each LTS series:\n\n- 5.21/candidate (5.21.4-8a3cf61)\n- 5.0/candidate (5.0.5-5c60378)\n- 4.0/candidate (4.0.10-35a8127)\n\nWe will be preparing intermediate releases to the associated stable snap channels shortly.\n\n**Workarounds**\n\nPermissions can be manually restricted until a patched version of LXD is deployed.\n\nThis is done with:\n\n```\nsudo nsenter --mount=/run/snapd/ns/lxd.mnt -- chmod 0700 /var/snap/lxd/common/lxd/storage-pools/*/{custom*,virtual-machines*,images}\nsudo nsenter --mount=/run/snapd/ns/lxd.mnt -- chmod 0711 /var/snap/lxd/common/lxd/storage-pools/*/{containers*,buckets*}\n```\n\nThose are the same permissions which will be applied by the patched LXD for both new and existing storage pools.\n\n**References**\n\nThis was reported to Incus publicly on Github here: \n\n- https://github.com/lxc/incus/security/advisories/GHSA-56mx-8g9f-5crf\n- https://github.com/lxc/incus/issues/2641","ecosystems":["Go"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"LXD vulnerable to a local privilege escalation through custom storage volumes","id":"GHSA-3g2j-vm47-x4mj","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"Go","product":null,"products":[],"type":"privilege_escalation","year":"2025"},"n_packages":3,"n_references":null,"packages":[{"ecosystem":"Go","fixed":[],"introduced":["0"],"last_affected":[],"package":"github.com/canonical/lxd","purl":"pkg:golang/github.com/canonical/lxd","source":"GO-2025-4121"},{"ecosystem":"Go","fixed":["0.0.0-20251110144034-698854d0164f"],"introduced":["0"],"last_affected":[],"package":"github.com/canonical/lxd","purl":null,"source":"GHSA-3g2j-vm47-x4mj"},{"ecosystem":"Go","fixed":["0.0.0-20251110144034-698854d0164f"],"introduced":["0"],"last_affected":[],"package":"github.com/canonical/lxd","purl":"pkg:golang/github.com/canonical/lxd","source":"GHSA-3g2j-vm47-x4mj"}],"products":null,"published":"2025-11-13","related":[],"sources":[{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"},{"class":"attribution","licence":"CC BY 4.0","name":"Go Vulnerability Database","prefix":"GO"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"An unprivileged user with container access can escalate to root on the host by exploiting custom storage volume permissions.","url":"https://insights.sbomify.com/GHSA-3g2j-vm47-x4mj/"}