Skip to main content

Boteraser | Website and Server Security Solutions

🛡️ CVE-2026-3351 — lxd

🟡 CVSS 4.3 — Medium ✅ No Known Exploit CWE-862 NVD
4.3
CVSS Score
0 Low4 Medium7 High9 Critical10

Description

lxd's non-recursive certificate listing bypasses per-object authorization and leaks all fingerprints

Summary

The GET /1.0/certificates endpoint (non-recursive mode) returns URLs containing fingerprints for all certificates in the trust store, bypassing the per-object can_view 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.gocertificatesGet (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:

```go

// lxd/certificates.go:139-193

func certificatesGet(d *Daemon, r *http.Request) response.Response {

recursion := util.IsRecursionRequest(r)

s := d.State()

userHasPermission, err := s.Authorizer.GetPermissionChecker(r.Context(), auth.EntitlementCanView, entity.TypeCertificate)

// ...

for _, baseCert := range baseCerts {

if !userHasPermission(entity.CertificateURL(baseCert.Fingerprint)) {

continue // Correctly filters unauthorized certs

}

if recursion {

// ... builds filtered certResponses ...

}

// NOTE: when !recursion, nothing is recorded — the filter result is discarded

}

if !recursion {

body := []string{}

for _, baseCert := range baseCerts { // <-- iterates UNFILTERED baseCerts

certificateURL := api.NewURL().Path(version.APIVersion, "certificates", baseCert.Fingerprint).String()

body = append(body, certificateURL)

}

return response.SyncResponse(true, body) // Returns ALL certificate fingerprints

}

return response.SyncResponse(true, certResponses) // Recursive path is correctly filtered

}

```

Inconsistency with other list endpoints confirms the bug

Five other list endpoints in the same codebase correctly filter results in both recursive and non-recursive paths:

| Endpoint | File | Filters non-recursive? |

|----------|------|----------------------|

| Instances | lxd/instances_get.goinstancesGet | Yes — filters before either path |

| Images | lxd/images.godoImagesGet | Yes — checks hasPermission for both paths |

| Networks | lxd/networks.gonetworksGet | Yes — filters outside recursion check |

| Profiles | lxd/profiles.goprofilesGet | Yes — separate filter in non-recursive path |

| Certificates | lxd/certificates.gocertificatesGet | No — unfiltered |

The certificates endpoint is the sole outlier, confirming this is an oversight rather than a design choice.

Access handler provides no defense

The endpoint uses allowAuthenticated as its AccessHandler (certificates.go:45), which only checks requestor.IsTrusted():

```go

// lxd/daemon.go:255-267

// allowAuthenticated is an AccessHandler which allows only authenticated requests.

// This should be used in conjunction with further access control within the handler

// (e.g. to filter resources the user is able to view/edit).

func allowAuthenticated(_ *Daemon, r *http.Request) response.Response {

requestor, err := request.GetRequestor(r.Context())

// ...

if requestor.IsTrusted() {

return response.EmptySyncResponse

}

return response.Forbidden(nil)

}

```

The comment explicitly states that allowAuthenticated should be "used in conjunction with further access control within the handler" — which the non-recursive path fails to do.

Execution chain

1. Restricted authenticated user sends GET /1.0/certificates (no recursion parameter)

2. allowAuthenticated access handler passes because user is trusted (daemon.go:263)

3. certificatesGet creates permission checker for EntitlementCanView on TypeCertificate (line 143)

4. Loop at lines 163-176 filters baseCerts by permission — but only populates certResponses for recursive mode

5. Since !recursion, control reaches lines 185-192

6. New loop iterates ALL baseCerts (unfiltered) and builds URL list with fingerprints

7. Full list of certificate fingerprints returned to restricted user

Proof of Concept

```bash

# Preconditions: restricted (non-admin) trusted client certificate

HOST=target.example

PORT=8443

# 1) Non-recursive list: returns ALL certificate fingerprints (UNFILTERED)

curl -sk --cert restricted.crt --key restricted.key \

"https://${HOST}:${PORT}/1.0/certificates" | jq '.metadata | length'

# 2) Recursive list: re

How this vulnerability can be exploited

This issue can be reached over the network, attack complexity is low, an attacker needs low-level privileges on the target. No user interaction is required. The scope is unchanged, so the impact stays within the vulnerable component. Rated impact: confidentiality low, integrity none, availability none.

CVSS metrics in full

The score comes from this vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

  • Attack vector: Network — reachable from anywhere that can route to the service.
  • Attack complexity: Low — the attack works reliably, with no preparation.
  • Privileges required: Low — an ordinary user account is enough.
  • User interaction: None — nobody has to be tricked into anything.
  • Scope: Unchanged — the damage stays inside the vulnerable component.
  • Confidentiality impact: Low — limited, and the attacker does not choose what is affected.
  • Integrity impact: None.
  • Availability impact: None.

Weakness class

CVE-2026-3351 is classified as CWE-862: Missing Authorization. No authorisation check is performed before carrying out a restricted action.

Affected software

CVE-2026-3351 is recorded against 2 packages.

  • github.com/canonical/lxd
  • lxd

Timeline and source

Published on 4 March 2026 and last revised on 23 March 2026. No public exploit is currently recorded for this entry. A vendor advisory or fix has been published. Record sourced from NVD.

References

github.com (Web)
nvd.nist.gov (Advisory)
github.com (Web)
github.com (Web)
github.com (Package)

Other advisories for this package

github.com/canonical/lxd has other advisories on record. If you are patching this one, these are worth checking on the same host:

Same weakness in other software

These advisories are the same class of weakness (CWE-862: Missing Authorization) in other software:

CVE-2026-3351 on other distributions

Each distribution ships its own build and its own fixed version. Pick the one you run:

Details

Severity Medium
CVSS Score 4.3
CVSS Vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
CWE CWE-862
Public Exploit ✅ No
Source NVD
Published 2026-03-04
Updated 2026-08-20
Modified 2026-03-23

Affected Packages

Software From version Fixed in
github.com/canonical/lxd
lxd

Similar Threats

Vulnerability Monitoring

Track new vulnerabilities in lxd

CVE-2026-3351 is rated CVSS 4.3 Medium. BotEraser monitors your WordPress installation and notifies you when software you use appears in our vulnerability database.

Set Up Free Alerts →

No credit card required  ·  Results in minutes

ⓘ Data Notice: The information presented above has been compiled from publicly available internet sources. Boteraser aggregates this data solely for informational purposes and does not independently classify, evaluate, or endorse any findings about the vulnerabilities listed. The accuracy and completeness of this information is the sole responsibility of the original publishers. Boteraser and its operators accept no liability for any decisions made based on this data.

Browse related advisories

All advisoriesCVECVE 2026