CVE-2026-34179: 
NixOS vulnerability analysis and mitigation

CVE-2026-34179 is a privilege escalation vulnerability in Canonical LXD affecting versions 4.12 through 6.7 (specifically 4.12–5.0.6, 5.21.0–5.21.4, and 6.0–6.7). The flaw resides in the doCertificateUpdate function in lxd/certificates.go, which fails to validate the Type field when processing PUT/PATCH requests to /1.0/certificates/{fingerprint}, allowing a remote authenticated attacker with restricted TLS certificate privileges to escalate to cluster admin. It was disclosed on April 9, 2026, with the fix merged on March 23, 2026. The CVSS v3.1 base score is 9.1 (Critical) (GitHub Advisory).

The root cause is classified as CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes). In doCertificateUpdate, the guard block for unprivileged (restricted) callers validates that Restricted, Name, and Projects match the original database record, but omits a check on the Type field. The subsequent reset block rebuilds the dbCert struct using original values for most fields but uses the caller-supplied reqDBType for Type, allowing an attacker to persist a modified certificate type to the database. By sending a single PATCH request with {"type": "server"} to /1.0/certificates/{fingerprint}, a restricted user changes their certificate type from client to server; on the next identity cache refresh, the modified certificate is matched as a server certificate during TLS authentication, granting ProtocolCluster with full admin privileges (GitHub Advisory, GitHub PR #17936).

Successful exploitation allows a restricted, project-scoped TLS certificate user to gain full cluster admin access, completely compromising confidentiality, integrity, and availability across the entire LXD cluster. A cluster admin can create privileged containers (security.privileged=true) or inject raw LXC configuration (raw.lxc), enabling root-level access to the underlying host and full host compromise. The escalation is persistent, takes effect immediately after the identity cache refresh, and the permission change is not logged, making detection difficult (GitHub Advisory).

A detailed proof-of-concept is publicly available in the official GitHub Security Advisory, including step-by-step lxc commands to reproduce the escalation. The exploit requires only a single PUT/PATCH API request and high (but restricted) privileges as a precondition. The EPSS score is approximately 0.087%, and there is no current evidence of in-the-wild exploitation or CISA KEV catalog listing as of the time of this report (GitHub Advisory, Feedly).

1. Obtain restricted TLS certificate access: Acquire a restricted TLS client certificate for an LXD cluster (e.g., via a token issued by an admin: lxc config trust add --restricted --projects poc-restricted --name poc-user).
2. Add the LXD remote: Register the target LXD cluster as a remote using the token: lxc remote add target <token>.
3. Confirm restricted access: Verify that only the restricted project is visible and that admin operations (e.g., lxc project set target:poc-restricted restricted=false) are denied.
4. Retrieve own certificate fingerprint: Query the certificates endpoint to obtain the fingerprint of the current user's certificate: fp=$(lxc query target:/1.0/certificates | jq -r '.[0]').
5. Escalate certificate type: Send a PATCH request to change the certificate type from client to server: lxc query -X PATCH -d '{ "type": "server" }' target:$fp.
6. Confirm escalation: Verify the certificate type has changed to server via lxc config trust list target:.
7. Exercise cluster admin privileges: Perform previously forbidden admin actions, such as unrestricting a project (lxc project set target:poc-restricted restricted=false), creating privileged containers (lxc init ubuntu:24.04 target:privileged -c security.privileged=true), and mounting the host filesystem to achieve host root access (lxc config device add target:privileged hostfs disk source=/ path=/mnt/host) (GitHub Advisory).

• Network: Unexpected PUT or PATCH HTTP requests to /1.0/certificates/{fingerprint} originating from restricted TLS certificate users; requests containing {"type": "server"} or "type": "server" in the request body.
• Logs: LXD API access logs showing PATCH/PUT requests to the /1.0/certificates/ endpoint by non-admin users; absence of corresponding log entries for subsequent privilege escalation actions (the permission change itself is not logged).
• LXD State: Certificate entries in lxc config trust list showing a previously restricted user certificate with type server instead of client; unexpected cluster admin operations (e.g., project restriction changes, privileged container creation) attributed to a restricted user account.
• File System / Container: Newly created privileged containers (security.privileged=true) or containers with host filesystem mounts (source=/) not authorized by an administrator; unexpected files or processes on the host originating from within a container (GitHub Advisory).

Canonical has released patched versions: 5.0.7, 5.21.5, and 6.8.0 (and later). Users on the 4.x series should also apply the backported fix. The fix adds Type to the guard check in doCertificateUpdate and uses the original database type in the reset block, preventing caller-supplied values from persisting. As an interim workaround, restrict access to the /1.0/certificates/{fingerprint} endpoint to trusted administrators only, and audit all existing restricted TLS certificate users for unexpected type changes. Upgrading to a patched version is the strongly recommended remediation (GitHub Advisory, GitHub PR #17936).

Canonical published a blog post discussing how AI-assisted tooling was used to hunt for logic flaws in LXD, referencing this class of vulnerability (Canonical Blog). The Belgian Centre for Cybersecurity (CCB) issued an advisory warning about multiple privilege escalation vulnerabilities in Canonical LXD, including CVE-2026-34179. The Hacker Wire covered the disclosure with a dedicated article on the privilege escalation (The Hacker Wire). The vulnerability was also flagged in CISA's weekly vulnerability bulletin for the week of April 6, 2026.