Canonical LXD CVE-2026-34179: Brief Summary of a Critical Privilege Escalation via Certificate Type Tampering

Introduction

A single unauthenticated API field in Canonical LXD's certificate management endpoint allows any restricted TLS user to silently promote themselves to cluster admin, opening a direct path to full host compromise through privileged containers. With a CVSS score of 9.1 and a publicly available exploit, CVE-2026-34179 represents a serious risk for any organization running LXD clusters with restricted certificate based access control.

LXD is Canonical's open source platform for managing system containers and virtual machines at scale. It is widely used in cloud infrastructure, CI/CD pipelines, and development environments, providing a unified API for Linux system management. Its role as a hypervisor layer means that a compromise at the LXD admin level translates directly into root level access on the underlying host.

Technical Information

Root Cause: Missing Type Field Validation in doCertificateUpdate

The vulnerability is classified under CWE-915 (Improperly Controlled Modification of Dynamically Determined Object Attributes). It resides in the doCertificateUpdate function within lxd/certificates.go, which processes PUT and PATCH requests to the /1.0/certificates/{fingerprint} endpoint.

The access handler for this endpoint is allowAuthenticated, which means any trusted TLS user, including those with restricted certificates, can reach this code path. This is the first prerequisite: the attacker needs only a valid restricted TLS certificate to interact with the vulnerable endpoint.

How the Validation Fails

For unprivileged callers, two defensive mechanisms are intended to prevent unauthorized field modification. Both fail to protect the Type field:

1. The guard block validates that Restricted, Name, and Projects match the original database record. It explicitly does not check the Type field. A restricted user can submit a request with "type": "server" and this guard will not reject it.

2. The reset block rebuilds the dbCert struct using original values from the database for most fields. However, it uses the caller supplied reqDBType for the Type field instead of the original dbInfo type from the database. This means even after the guard passes, the attacker controlled type value is persisted to the database.

The official patch corrects this by using the original database type:

origDBType, err := certificate.FromAPIType(dbInfo.Type)
if err != nil {
 return response.InternalError(err)
}

dbCert = dbCluster.Certificate{
 Certificate: dbInfo.Certificate,
 Fingerprint: dbInfo.Fingerprint,
 Restricted: dbInfo.Restricted,
 Name: dbInfo.Name,
 Type: origDBType,
}

Attack Flow

The exploitation path is straightforward and requires only a single API request:

1. Obtain certificate fingerprint. The attacker, who holds a restricted TLS client certificate, queries the LXD API to retrieve their own certificate fingerprint.

2. Send a PATCH request to modify the certificate type. The attacker sends a PATCH request to /1.0/certificates/{fingerprint} with the body {"type": "server"}. Because the guard block does not validate the Type field and the reset block uses the attacker supplied value, the certificate type is changed from client to server in the database.

3. Privilege escalation takes effect. After the identity cache refreshes, the attacker's certificate is now treated as a server certificate, granting cluster admin privileges. This escalation is persistent and, critically, the change in permissions is not logged anywhere.

4. Host compromise. With cluster admin access, the attacker can unrestrict their project, create privileged containers, or pass raw LXC configurations. Privileged containers provide root level access to the host, completing the escape from a restricted container user to full host control.

The entire attack requires network access to the LXD API, a valid restricted TLS certificate, and one HTTP request. There is no user interaction required and the attack complexity is low.

Affected Systems and Versions

The vulnerability affects Canonical LXD versions 4.12 through 6.7. Specifically, any LXD deployment within this version range that uses restricted TLS certificate based authentication is vulnerable.

Canonical has released patched versions across multiple series:

LXD Series	Patched Version
Series 6	6.8
Series 5.21 LTS	5.21.5
Series 5.0 LTS	5.0.7

Organizations should verify their LXD version and confirm whether restricted TLS certificates are in use. Environments that rely solely on other authentication mechanisms may have reduced exposure, but upgrading remains the recommended course of action.

Vendor Security History

Canonical demonstrated a strong response to this vulnerability. The security advisory (GHSA-c3h3-89qf-jqm5) was published on April 9, 2026, with clear technical details, a working Proof of Concept, and immediate interim snap releases covering all supported LTS and current series. The associated pull request (#17936) included comprehensive test cases to ensure restricted clients cannot edit certificate types, names, restrictions, or projects, addressing not just the immediate bug but the broader class of field tampering issues on this endpoint.

References

• GitHub Security Advisory: GHSA-c3h3-89qf-jqm5
• Pull Request #17936: Improve validation on certificate edit
• Pull Request #17936: File changes
• Canonical LXD Product Page
• LXD Documentation (Stable 5.21)
• LXD 6.7 Interim Snap Release Notes
• LXD 5.21.4 LTS Interim Snap Release Notes
• LXD 5.0.6 LTS Interim Snap Release Notes