CVE-2026-34179
Privilege Escalation in Canonical LXD TLS Certificate Handling
Publication date: 2026-04-09
Last updated on: 2026-04-22
Assigner: Canonical Ltd.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| canonical | lxd | From 4.12 (inc) to 5.0.6 (inc) |
| canonical | lxd | From 5.21.0 (inc) to 5.21.4 (inc) |
| canonical | lxd | From 6.0 (inc) to 6.7 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-915 | The product receives input from an upstream component that specifies multiple attributes, properties, or fields that are to be initialized or updated in an object, but it does not properly control which attributes can be modified. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-34179 is a critical privilege escalation vulnerability in Canonical LXD versions 4.12 through 6.7. It arises from improper validation of the "Type" field in TLS certificates when restricted users update their certificates via the API endpoint `/1.0/certificates/{fingerprint}`.
Specifically, the `doCertificateUpdate` function in `lxd/certificates.go` does not validate the "Type" field for restricted TLS certificate users during PUT or PATCH requests. This allows a remote authenticated attacker with a restricted TLS certificate to change the certificate's type from "client" to "server".
Since server certificates have cluster admin privileges, this change escalates the attacker's privileges to full cluster admin, enabling them to disable project restrictions and gain root-level access to the host.
How can this vulnerability impact me? :
This vulnerability allows a remote authenticated attacker with a restricted TLS certificate to escalate their privileges to cluster admin on the LXD host.
- Privilege escalation from restricted user to cluster admin.
- Ability to disable project restrictions and launch privileged containers.
- Potential to use raw LXC configurations to gain root-level access to the host.
- Full compromise of confidentiality, integrity, and availability of the host system.
- Exploitation is possible remotely over the network with low complexity and no user interaction.
The impact is immediate and persistent after the identity cache refresh, with no logging of the permission change.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves improper validation of the "Type" field in TLS certificate updates via the LXD API endpoint `/1.0/certificates/{fingerprint}`. Detection would involve monitoring or inspecting API requests to this endpoint, especially PUT or PATCH requests that attempt to change certificate details.
Specifically, detection could focus on identifying requests where the "Type" field is changed from "client" (restricted) to "server", which indicates an attempt to escalate privileges.
Commands or methods to detect this might include:
- Using network monitoring tools (e.g., tcpdump, Wireshark) to capture and filter HTTP requests to the LXD API endpoint `/1.0/certificates/`.
- Inspecting LXD API logs or audit logs for PUT or PATCH requests modifying certificates, focusing on changes to the "Type" field.
- Using curl or similar tools to query certificate details and verify if any certificate's "Type" field has been unexpectedly changed to "server".
Example command to check certificate details (replace <fingerprint> with actual value):
- curl --unix-socket /var/snap/lxd/common/lxd/unix.socket -X GET https://localhost/1.0/certificates/<fingerprint>
Note: The resources do not provide explicit detection commands but imply monitoring API requests and certificate states to detect exploitation attempts.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include updating LXD to a patched version where this vulnerability is fixed.
- Upgrade LXD to one of the patched versions: 5.0.7, 5.21.5, 6.8, or any version >= 6.23.0.
- For interim and LTS releases, apply patches available in versions 6.7, 5.21.4, 5.0.6, or 4.0.10.
These updates include validation fixes that ensure the "Type" field cannot be improperly changed by restricted TLS certificate users, preventing privilege escalation.
Additionally, review and restrict access to the LXD API endpoint `/1.0/certificates/{fingerprint}` to trusted users only, and monitor certificate changes closely.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows a remote authenticated attacker with a restricted TLS certificate to escalate privileges to cluster admin, resulting in full confidentiality, integrity, and availability compromise of the host.
Such a compromise can lead to unauthorized access to sensitive data and systems, which may violate compliance requirements under common standards and regulations like GDPR and HIPAA that mandate strict access controls and protection of sensitive information.
Because the vulnerability enables privilege escalation without logging and allows attackers to disable project restrictions and gain root-level host access, it undermines security controls essential for regulatory compliance.