CVE-2026-3351
Improper Authorization in Canonical LXD API Enables Certificate Enumeration
Publication date: 2026-03-03
Last updated on: 2026-03-11
Assigner: Canonical Ltd.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| canonical | lxd | 6.6 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-862 | The product does not perform an authorization check when an actor attempts to access a resource or perform an action. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-3351 is an authorization vulnerability in the Canonical LXD 6.6 API endpoint GET /1.0/certificates. It allows an authenticated but restricted user to enumerate all certificate fingerprints trusted by the LXD server. This happens because the non-recursive query to this endpoint improperly returns URLs for all certificates without checking if the user has permission to view them.
The issue arises from the API returning an unfiltered list of certificate URLs in the non-recursive mode, bypassing per-certificate authorization checks. As a result, restricted users can see certificate fingerprints they should not have access to, revealing the entire trust topology of the LXD deployment.
The vulnerability was fixed by modifying the API to enforce access control properly, filtering the certificate URLs returned to only those the user is authorized to access.
How can this vulnerability impact me? :
This vulnerability can impact you by allowing restricted authenticated users to enumerate all trusted certificate fingerprints in your LXD environment. This information leakage can be used for reconnaissance and identity enumeration.
- Identity enumeration: Attackers can discover all trusted certificate fingerprints, revealing the trust relationships within the system.
- Reconnaissance: Fingerprints can identify certificates used for privileged operations such as inter-cluster communication and administrative access.
- Role-Based Access Control (RBAC) bypass: The flaw circumvents fine-grained access controls intended to restrict certificate visibility.
- Information asymmetry: Administrators’ intended restrictions on certificate visibility are bypassed, potentially exposing sensitive trust information.
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': "CVE-2026-3351 is an authorization vulnerability in the Canonical LXD 6.6 API endpoint GET /1.0/certificates. It allows an authenticated but restricted user to enumerate all certificate fingerprints trusted by the LXD server. This happens because the non-recursive listing of certificates does not properly enforce per-certificate permission checks, returning URLs for all certificates regardless of the user's access rights."}, {'type': 'paragraph', 'content': "Specifically, the API endpoint returns a list of certificate URLs containing fingerprints without filtering based on the user's entitlements. This means restricted users can see certificate identifiers they should not have access to, exposing the trust topology of the LXD deployment."}, {'type': 'paragraph', 'content': "The vulnerability was fixed by modifying the certificate listing function to filter certificates according to the user's permissions, ensuring only authorized certificates are visible in the API response."}] [1, 2, 3]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability impact me? :
This vulnerability can impact you by allowing restricted authenticated users to enumerate all trusted certificate fingerprints in your LXD deployment. This information leakage can lead to several security concerns:
- Identity enumeration: Attackers can discover all trusted certificate fingerprints, revealing the entire trust topology.
- Reconnaissance: Fingerprints can identify certificates used for privileged operations such as inter-cluster communication and administrative access.
- Role-Based Access Control (RBAC) bypass: The flaw circumvents fine-grained RBAC mechanisms for the non-recursive certificate listing.
- Information asymmetry: Intended restrictions on certificate visibility by administrators are bypassed, potentially aiding attackers in planning further attacks.
However, the vulnerability does not disclose private keys or secrets, and the overall confidentiality impact is considered low.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by performing an authenticated GET request to the LXD API endpoint `/1.0/certificates` without recursion and comparing the results to a recursive query. If the non-recursive query returns certificate URLs or fingerprints beyond what the user is authorized to see, the system is vulnerable.'}, {'type': 'paragraph', 'content': 'A practical detection method is to use curl commands with an authenticated user token or client certificate to query the endpoint:'}, {'type': 'list_item', 'content': 'curl -H "Authorization: Bearer <token>" https://<lxd-server>/1.0/certificates'}, {'type': 'list_item', 'content': 'curl -H "Authorization: Bearer <token>" https://<lxd-server>/1.0/certificates?recursion=1'}, {'type': 'paragraph', 'content': 'If the first command returns a list of all certificate fingerprints regardless of permissions, while the second returns only authorized certificates, the vulnerability exists.'}] [3]
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade the LXD package to version 6.7 or later, where this vulnerability has been patched.
The patch enforces proper authorization checks on the `/1.0/certificates` API endpoint, ensuring that only certificates the user is authorized to view are returned.
If upgrading immediately is not possible, restrict access to the LXD API endpoint to trusted users only and monitor API usage for suspicious certificate enumeration attempts.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by performing authenticated GET requests to the LXD API endpoint `/1.0/certificates` and comparing the results of non-recursive and recursive queries.
Specifically, an authenticated user with restricted permissions can run the following commands to check if unauthorized certificate fingerprints are exposed:
- Use a curl command to send a non-recursive GET request to `/1.0/certificates` and observe if it returns all certificate fingerprints regardless of permissions.
- Use a curl command to send a recursive GET request to `/1.0/certificates?recursion=1` and compare the returned certificates to the non-recursive response.
If the non-recursive request returns more certificate fingerprints than the recursive one, this indicates the presence of the vulnerability.
Example commands (assuming appropriate authentication tokens or client certificates):
- curl -X GET --cert <client-cert.pem> --key <client-key.pem> https://<lxd-server>/1.0/certificates
- curl -X GET --cert <client-cert.pem> --key <client-key.pem> https://<lxd-server>/1.0/certificates?recursion=1
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability immediately, you should upgrade the LXD package to version 6.7 or later, where the issue has been patched.
The patch enforces proper authorization checks on the `/1.0/certificates` API endpoint, ensuring that users only see certificate URLs they are authorized to access.
If upgrading immediately is not possible, consider restricting access to the LXD API endpoint `/1.0/certificates` to trusted administrative users only, preventing restricted users from querying this endpoint.
Additionally, review and tighten role-based access controls (RBAC) and authentication mechanisms to limit exposure.