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

Introduction

A single unvalidated field in Canonical LXD's certificate management API lets any restricted TLS user silently promote themselves to cluster admin, and from there to full host compromise through privileged containers. With a CVSS score of 9.1 and a publicly available exploit, CVE-2026-34179 is 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, and it provides a unified API for Linux system management. Because LXD acts as a hypervisor layer, 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 is in the doCertificateUpdate function in lxd/certificates.go, which processes PUT and PATCH requests to the /1.0/certificates/{fingerprint} endpoint.

The access handler for this endpoint is allowAuthenticated, so any trusted TLS user, including one with a restricted certificate, can reach this code path. That 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 mechanisms are meant to prevent unauthorized field modification. Neither protects the Type field:

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

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

The official patch fixes 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. The attacker, who holds a restricted TLS client certificate, queries the LXD API for their own certificate fingerprint.

2. 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 changes from client to server in the database.

3. Once the identity cache refreshes, LXD treats the attacker's certificate as a server certificate, which grants cluster admin privileges. The escalation persists, and the change in permissions is not logged anywhere.

4. With cluster admin access, the attacker can unrestrict their project, create privileged containers, or pass raw LXC configurations. Privileged containers give root-level access to the host, so a user who started with restricted container access ends up with full host control.

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

Affected Systems and Versions

The vulnerability affects Canonical LXD versions 4.12 through 6.7. Any LXD deployment in this version range that uses restricted TLS certificates for authentication is vulnerable.

Canonical has released patched versions across multiple series:

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

Vendor Security History

Canonical responded well 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 for all supported LTS and current series. The associated pull request (#17936) added comprehensive test cases to make sure restricted clients cannot edit certificate types, names, restrictions, or projects. Those tests cover the broader class of field tampering issues on this endpoint as well as the immediate bug.

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