CVE-2026-3351

mediumPriorität · verfolgen · 17OT-Risiko · erhöhtEPSS 0.001 · 4. PerzentilEUUS
grimoire priorityP3 · Track
Exploitable?
—
no known exploitation
Likely / severe?
0.14% (4th) EPSS
CVSS 4.3 · medium
Is it mine?
4 products
Prüfe deine Angriffsfläche
Who says so?
4 sources
cnnvd · enisa_euvd · osv · nvd

EPSS · bewertet 2026-10-27

Improper authorization in the API endpoint GET /1.0/certificates in Canonical LXD 6.6 on Linux allows an authenticated, restricted user to enumerate all certificate fingerprints trusted by the lxd server.

01

cvss

Technischer Schweregrad, 0–10. Eine Zeile je Quelle.

4.3
010

Basiswert 0–10 · höher = schwerwiegender · Vektor überfahren zum Auflösen⚠ Quellen uneinig · low–medium · 1.3–4.3

v3.14.3mediumCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:Nprimary · NVD / NIST USAusnutzbarkeit 2.8 · Auswirkung 1.4
v4.02.1lowCVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N/E:Psecondary · ENISA EU
v4.02.1lowCVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Xsecondary · security@ubuntu.com
v4.01.3lowCVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Xsecondary · CVSS-BT (t0sche)
02

SSVC

Eine Handlungsentscheidung — aus Ausnutzung und Auswirkung.

Trackcoordinatorcisa_ssvcUS
03

schwächen

Die CWE-Schwächeklassen, zu denen dies gehört.

04

betroffene Produkte (4)

Betroffene Produkte und Versionsbereiche.

05

Advisories (2)

Hersteller- und Ökosystem-Meldungen dazu.

  • GHSA-crmg-9m86-636rlxd's non-recursive certificate listing bypasses per-object authorization and leaks all fingerprints2026-03-04ghsa · osvUS

    ## 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.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: ```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.go` — `instancesGet` | Yes — filters before either path | | Images | `lxd/images.go` — `doImagesGet` | Yes — checks `hasPermission` for both paths | | Networks | `lxd/networks.go` — `networksGet` | Yes — filters outside recursion check | | Profiles | `lxd/profiles.go` — `profilesGet` | Yes — separate filter in non-recursive path | | **Certificates** | **`lxd/certificates.go` — `certificatesGet`** | **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: returns only authorized certificates (FILTERED) curl -sk --cert restricted.crt --key restricted.key \ "https://${HOST}:${PORT}/1.0/certificates?recursion=1" | jq '.metadata | length' # Expected: (1) returns MORE fingerprints than (2), proving the authorization bypass. # The difference reveals fingerprints of certificates the restricted user should not see. ``` ## Impact - **Identity enumeration**: A restricted user can discover the fingerprints of all trusted certificates, revealing the complete set of identities in the LXD trust store. - **Reconnaissance for targeted attacks**: Fingerprints identify specific certificates used for inter-cluster communication, admin access, and other privileged operations. - **RBAC bypass**: In deployments using fine-grained RBAC (OpenFGA or built-in TLS authorization), the non-recursive path completely bypasses the intended per-object visibility controls. - **Information asymmetry**: Restricted users gain knowledge of the full trust topology, which the administrator explicitly intended to hide via per-certificate `can_view` entitlements. ## Recommended Remediation ### Option 1: Apply the permission filter to the non-recursive path (preferred) Replace the unfiltered loop with one that checks `userHasPermission`, matching the pattern used in the recursive path and in all other list endpoints: ```go // lxd/certificates.go — replace lines 185-192 if !recursion { body := []string{} for _, baseCert := range baseCerts { if !userHasPermission(entity.CertificateURL(baseCert.Fingerprint)) { continue } certificateURL := api.NewURL().Path(version.APIVersion, "certificates", baseCert.Fingerprint).String() body = append(body, certificateURL) } return response.SyncResponse(true, body) } ``` ### Option 2: Build both response types in a single filtered loop Restructure the function to build both the URL list and the recursive response in the same permission-checked loop, eliminating the possibility of divergent filtering: ```go err = d.State().DB.Cluster.Transaction(r.Context(), func(ctx context.Context, tx *db.ClusterTx) error { baseCerts, err = dbCluster.GetCertificates(ctx, tx.Tx()) if err != nil { return err } certResponses = make([]*api.Certificate, 0, len(baseCerts)) certURLs = make([]string, 0, len(baseCerts)) for _, baseCert := range baseCerts { if !userHasPermission(entity.CertificateURL(baseCert.Fingerprint)) { continue } certURLs = append(certURLs, api.NewURL().Path(version.APIVersion, "certificates", baseCert.Fingerprint).String()) if recursion { apiCert, err := baseCert.ToAPI(ctx, tx.Tx()) if err != nil { return err } certResponses = append(certResponses, apiCert) urlToCertificate[entity.CertificateURL(apiCert.Fingerprint)] = apiCert } } return nil }) ``` Option 2 is structurally safer as it prevents the two paths from diverging in the future. ## Credit This vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).

  • GO-2026-4595Non-recursive certificate listing bypasses per-object authorization and leaks all fingerprints in github.com/canonical/lxd2026-03-10vendor · osvUS

    Non-recursive certificate listing bypasses per-object authorization and leaks all fingerprints in github.com/canonical/lxd

06

auch bekannt als (5)

Weitere Namen und Kennungen dieser Entität.

07

quellen

Welche Quellen diesen Datensatz belegen und wann.

veröffentlicht 2026-03-03geändert 2026-06-17
08

Referenzen (11)

Externe Belege — Patches, Meldungen, Analysen.

scry

Angreifer nutzen Schwachstellen wie diese gegen im Internet exponierte Dienste aus. Sehen Sie mit einem kostenlosen Passiv-Scan, was exponiert ist.

Kostenloser Scan