CVE-2026-3351: Authorization Bypass in Canonical LXD Certificates API

Canonical LXD, a system container manager, exposes a REST API for management and orchestration. The API includes an endpoint, /1.0/certificates, designed to list the certificates currently trusted by the LXD server (e.g., for client authentication or cluster communication). Access to this endpoint is guarded by authentication and an authorization model that supports restricted tokens with granular permissions.

In LXD version 6.6, a vulnerability exists in the logic handling this endpoint. While the system correctly enforces granular visibility permissions when a client requests a recursive list (detailed object data), it fails to apply these same checks when serving a standard, non-recursive list (URLs and fingerprints only). Consequently, an attacker possessing a valid but restricted authentication token can enumerate the entire set of trusted certificates, identifying entities that should be invisible to them based on their entitlement scope.

The root cause lies in the control flow implementation within lxd/certificates.go inside the certificatesGet handler. The handler retrieves the complete list of certificates (baseCerts) from the cluster database and is intended to filter this list based on the requestor's permissions. The filtering logic utilizes a helper function, userHasPermission, to verify if the caller has EntitlementCanView for a specific certificate.

The logic diverged based on the recursion query parameter:

1. Recursive Path (?recursion=1): The code iterated through baseCerts, explicitly called userHasPermission for each item, and only included authorized certificates in the response.
2. Non-Recursive Path (Default): The code entered a separate block that iterated through the raw baseCerts slice. Crucially, this block lacked the userHasPermission check entirely. It unconditionally constructed the resource URL (containing the SHA-256 fingerprint) for every certificate in the database and returned the list.

This inconsistency allowed the non-recursive path to act as a side-channel for enumeration, leaking the existence and fingerprints of certificates that were otherwise protected by the authorization layer.

The vulnerability was addressed by consolidating the response generation logic. The patch removes the divergent path for non-recursive requests and forces all iterations to pass through the authorization check.

Vulnerable Logic (Conceptual):

// Logic prior to fix
if recursion {
    for _, cert := range baseCerts {
        if !userHasPermission(cert) { continue }
        // Add full details
    }
} else {
    // VULNERABILITY: No permission check here
    for _, cert := range baseCerts {
        urls = append(urls, "/1.0/certificates/" + cert.Fingerprint)
    }
}

Patched Logic:

The fix ensures that userHasPermission guards the addition of any data to the response, regardless of the recursion mode. The URL construction is moved inside the authorized block.

// Fixed logic in d936c90d47cf0be1e9757df897f769e9887ebde1
for _, baseCert := range baseCerts {
    // Unified authorization check
    if !userHasPermission(baseCert.Fingerprint) {
        continue
    }
 
    if recursion {
        // Add full details for recursive response
        // ...
    } else {
        // Only append URL if authorized
        url := api.NewURL().Path(version.APIVersion, "certificates", baseCert.Fingerprint)
        certURLs = append(certURLs, url.String())
    }
}

This change guarantees that if a user cannot view a certificate object, they cannot see its URL or fingerprint in the list, aligning the behavior of both API modes.

Exploitation of CVE-2026-3351 requires a valid authentication token. This could be a restricted certificate or a bearer token issued with limited scopes. The attacker does not need high privileges; a token with zero explicit permissions is sufficient to trigger the leak.

Attack Scenario:

1. Prerequisites: The attacker obtains a restricted bearer token.
2. Execution: The attacker sends a GET request to the /1.0/certificates endpoint without the recursion parameter.

# Example using the LXD command line tool alias
export LXD_AUTH_BEARER_TOKEN="<restricted_token>"
lxc query /1.0/certificates

Result:

The server returns a JSON array containing the URLs of all trusted certificates, revealing their SHA-256 fingerprints:

[
    "/1.0/certificates/75329c73266fc8f36581ae5508ef4347e4eaa696eed09089c4dc7be68198bf7a",
    "/1.0/certificates/a1b2c3d4..."
]

This output confirms the presence of these certificates in the trust store. If the fix were applied, an empty list [] (or only the certificates the user explicitly owns) would be returned.

The impact of this vulnerability is classified as Low (CVSS 2.1) because it involves information leakage of non-secret identifiers rather than direct compromise of confidentiality or integrity.

• Confidentiality (Low): The specific data leaked consists of certificate fingerprints (hashes). While fingerprints are unique identifiers, they do not inherently expose the private key or the certificate contents (Subject, SANs, etc.). However, knowing the fingerprint allows an attacker to map trust relationships or verify if a specific known certificate is trusted by the server.
• Authorization Bypass: The core issue is the failure of the security model. The system fails to enforce "Can View" entitlements, allowing lateral visibility that should be restricted.
• Attack Vector: Network-based (AV:N), requiring low privileges (PR:L). It is not exploitable by unauthenticated users.

This vulnerability is primarily useful for reconnaissance, helping an attacker understand the cluster's topology or identity management structure before attempting further lateral movement.