Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go

GHSA-crmg-9m86-636r

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

Also known asCVE-2026-3351GO-2026-4595
Published
Mar 4, 2026
Updated
Mar 23, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

EPSS Exploitation Probability

via FIRST.org ↗
0.1%probability of exploitation in next 30 days
Lower Risk4th percentile+0.11%
0.00%0.21%0.43%0.64%0.0%0.0%0.0%0.1%Apr 26Jun 26Jun 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

1 pkg affected
🐹github.com/canonical/lxd

Real-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

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:

// 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:

EndpointFileFilters non-recursive?
Instanceslxd/instances_get.goinstancesGetYes — filters before either path
Imageslxd/images.godoImagesGetYes — checks hasPermission for both paths
Networkslxd/networks.gonetworksGetYes — filters outside recursion check
Profileslxd/profiles.goprofilesGetYes — separate filter in non-recursive path
Certificateslxd/certificates.gocertificatesGetNo — 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():

// 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

# 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:

// 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:

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.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/canonical/lxdall versions0.0.0-20260224152359-d936c90d47cf

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/canonical/lxd. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update github.com/canonical/lxd to 0.0.0-20260224152359-d936c90d47cf or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-crmg-9m86-636r is resolved across your whole dependency graph.

  3. 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.

  4. How O3 protects you

    O3 pinpoints whether GHSA-crmg-9m86-636r is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-crmg-9m86-636r. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## 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**:
O3 Security · Impact-Aware SCA

Is GHSA-crmg-9m86-636r in your dependencies?

O3 detects GHSA-crmg-9m86-636r across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.