CVE-2026-3351: 
NixOS vulnerability analysis and mitigation

CVE-2026-3351 is a missing authorization vulnerability in the GET /1.0/certificates API endpoint of Canonical LXD 6.6 on Linux, allowing any authenticated, restricted (non-admin) user to enumerate all certificate fingerprints trusted by the LXD server. The flaw was discovered and reported by bugbunny.ai, with the fix merged on February 24, 2026, and the advisory published on March 3, 2026. Only LXD version 6.6 is affected; version 6.7 contains the patch. It carries a CVSS v3.1 base score of 4.3 (Medium) and a CVSS v4.0 base score of 2.1 (Low) (Github Advisory, LXD Security Advisory).

The root cause is CWE-862 (Missing Authorization) in lxd/certificates.go within the certificatesGet handler. The handler correctly obtains a userHasPermission checker and applies it when building the recursive response (lines 163–176), but the non-recursive code path (lines 185–192) iterates over the unfiltered baseCerts slice in a separate loop, completely discarding the permission check results. The allowAuthenticated access handler only verifies that the requestor is trusted (i.e., has a valid certificate), explicitly deferring per-object authorization to the handler itself — which the non-recursive path fails to perform. All five comparable list endpoints (instances, images, networks, profiles) correctly filter both recursive and non-recursive paths, confirming this is a coding oversight (LXD Security Advisory, Github Advisory).

Successful exploitation allows a restricted, authenticated user to enumerate the SHA-256 fingerprints of all certificates in the LXD trust store, including those for admin access, inter-cluster communication, and other privileged operations. In deployments using fine-grained RBAC (OpenFGA or built-in TLS authorization), this completely bypasses intended per-object visibility controls, creating information asymmetry where restricted users gain knowledge of the full trust topology that administrators explicitly intended to hide. There is no integrity or availability impact; the vulnerability is limited to confidentiality disclosure of certificate metadata (fingerprints), not private keys or certificate content (LXD Security Advisory).

A proof-of-concept exploit is publicly available via the GitHub security advisory, demonstrating exploitation with a simple curl command using a restricted client certificate. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.026% (0.000210 per Feedly), placing it in the 8th percentile for exploitation likelihood. The vulnerability is not listed in the CISA KEV catalog (Github Advisory, LXD Security Advisory).

1. Obtain restricted credentials: Acquire a valid but restricted (non-admin) trusted client certificate and key for the target LXD server — this could be a legitimately provisioned low-privilege account or a compromised restricted identity.
2. Identify target: Locate an LXD 6.6 server's API endpoint (default port 8443) using network scanning or prior knowledge.
3. Send non-recursive GET request: Issue a GET /1.0/certificates request (without the recursion=1 parameter) using the restricted certificate:

   curl -sk --cert restricted.crt --key restricted.key \
     "https://target.example:8443/1.0/certificates" | jq '.metadata[]'

4. Collect fingerprints: The response returns URLs containing SHA-256 fingerprints for ALL trusted certificates in the trust store, including those the restricted user is not authorized to view.
5. Compare with recursive response: Optionally confirm the bypass by comparing the non-recursive response count against the filtered recursive response (?recursion=1), which returns only authorized certificates.
6. Use fingerprints for reconnaissance: Use the enumerated fingerprints to identify admin certificates, inter-cluster communication certificates, and other privileged identities for targeted follow-on attacks (LXD Security Advisory, Github Advisory).

• Network: Repeated or anomalous GET /1.0/certificates requests (without recursion=1) from restricted/low-privilege client certificates to the LXD API (default port 8443); comparison requests pairing non-recursive and recursive certificate listing from the same source.
• Logs: LXD API access logs showing GET /1.0/certificates requests from authenticated identities that do not normally enumerate certificates; unusual frequency of certificate listing from a single restricted identity.
• Behavioral: A restricted user account issuing certificate enumeration requests followed by targeted requests to specific certificate endpoints (e.g., GET /1.0/certificates/<fingerprint>) for certificates they should not have visibility into.

Canonical has released LXD version 6.7 which contains the fix (commit d936c90), applying the userHasPermission check to the non-recursive code path in lxd/certificates.go. Organizations should upgrade from LXD 6.6 to 6.7 as the primary remediation. No configuration-based workaround is available; the only mitigation short of patching is to ensure no untrusted or restricted users have access to the LXD API. After patching, administrators should audit which restricted users had API access during the vulnerable period and review whether certificate trust topology was exposed (LXD PR #17738, Patch Commit).

The vulnerability was discovered and reported by bugbunny.ai and credited in the official Canonical advisory. The fix was reviewed and merged by Canonical maintainers (tomponline) on February 24, 2026, with a follow-up test suite PR (#17745) merged the next day to ensure certificate listing restrictions are properly validated. The Go vulnerability database (golang/vulndb) tracked the issue, and it was also noted as potentially relevant to the Juju project (LXD PR #17738, Github Advisory).