Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/canonical/lxd < 0.0.0-20260224152359-d936c90d47cf
Fixed in
0.0.0-20260224152359-d936c90d47cf· Vendor fix available
Issue
The GET /1.0/certificates endpoint (non-recursive mode) returns URLs containing fingerprints for all certificates in the trust store, bypassing the per-object canview authorization check that is correctly applied in the recursive path. Any authenticated identity — including restricted, non-admin users — can enumerate all certificate fingerprints, exposing the full set of trusted identities in the LXD deployment. Affected Component - lxd/certificates.go — certificatesGet (lines 185–192) — Non-recursive code path returns unfiltered certificate list. CWE - CWE-862: Missing Authorization Description Core vulnerability: missing permission filter in non-recursive listing path The certificatesGet handler obtains a permission checker at line 143 and correctly applies it when building the recursive response (lines 163-176). However, the non-recursive code path at lines 185-192 creates a fresh loop over the unfiltered baseCerts slice, completely bypassing the authorization check:…
Recommended action: Upgrade to 0.0.0-20260224152359-d936c90d47cf (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/canonical/lxd < 0.0.0-20251110144034-698854d0164f
Fixed in
0.0.0-20251110144034-698854d0164f· Vendor fix available
Issue
Impact This 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. The 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. Patches Patches for this issue are available: - LXD 6 series: https://github.com/canonical/lxd/pull/16904 - LXD 5.21 LTS series: https://github.com/canonical/lxd/pull/16922 - LXD 5.0 LTS series: https://github.com/canonical/lxd/pull/16923 - LXD 4.0 LTS series:…
Recommended action: Upgrade to 0.0.0-20251110144034-698854d0164f (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/canonical/lxd < 0.0.0-20240708073652-5a492a3f0036
Fixed in
0.0.0-20240708073652-5a492a3f0036· Vendor fix available
Issue
If a server.ca file is present in LXDDIR at LXD start up, LXD is in "PKI mode". In this mode, only TLS clients that have a CA-signed certificate should be able to authenticate with LXD. We have discovered that if a client that sends a non-CA signed certificate during the TLS handshake, that client is able to authenticate with LXD if their certificate is present in the trust store. - The LXD Go client (and by extension lxc) does not send non-CA signed certificates during the handshake. - A manual client (e.g. cURL) might send a non-CA signed certificate during the handshake. Versions affected LXD 4.0 and above. Details When PKI mode was added to LXD it was intended that all client and server certificates must be signed by the certificate authority (see https://github.com/canonical/lxd/pull/2070/commits/84d917bdcca6fe1e3191ce47f1597c7d094e1909). In PKI mode, the TLS listener configuration is altered to add the CA certificate but the ClientAuth field of tls.Config is not…
Recommended action: Upgrade to 0.0.0-20240708073652-5a492a3f0036 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/canonical/lxd < 0.0.0-20240403103450-0e7f2b5bf4d2
Fixed in
0.0.0-20240403103450-0e7f2b5bf4d2· Vendor fix available
Issue
If a server.ca file is present in LXDDIR at LXD start up, LXD is in "PKI mode". In this mode, all clients must have certificates that have been signed by the CA. The LXD configuration option core.trustcacertificates defaults to false. This means that although the client certificate has been signed by the CA, LXD will additionally add the certificate to the trust store and verify it via mTLS. When a restricted certificate is added to the trust store in this mode, it's restrictions are not honoured, and the client has full access to LXD. Details When authorization was refactored to allow for generalisation (at the time for TLS, RBAC, and OpenFGA, see https://github.com/canonical/lxd/pull/12313), PKI mode did not account for the core.trustcacertificates configuration option. When this option is enabled, all CA-signed client certificates are given full access to LXD. This cherry-pick from Incus was added to LXD to fix the issue. The cherry-pick fixed the immediate issue and…
Recommended action: Upgrade to 0.0.0-20240403103450-0e7f2b5bf4d2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/canonical/lxd >= 5.19.0, <= 5.19.0; >= 0.0.0-20230920084527-cbe39c5d3f14, < 0.0.0-20240118092008-ce1bd0dd37bb
Fixed in
5.20.00.0.0-20240118092008-ce1bd0dd37bb· Vendor fix available
Issue
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: PoC 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
Recommended action: Upgrade to 5.20.0 or 0.0.0-20240118092008-ce1bd0dd37bb (pre-release) by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.