# LXD: a public certificate was enough to borrow a trusted identity

> CVE-2026-112816 allowed a client to append a trusted public certificate to its TLS chain. We explain the faulty authorization check and its impact.

Published: 2026-11-05  
Canonical: https://rootzero.eu/en/research/lxd-certificate-chain-trust-2026/

**Canonical notice of October 28, 2026, technical detail published on November 4.** The [vulnerability CVE-2026-112816](https://github.com/canonical/lxd/security/advisories/GHSA-99jp-jwmc-65p4) is due to a very specific confusion: LXD verified that a trusted certificate appeared *somewhere* in the chain sent by the client, while the TLS negotiation only proved possession of the private key for the first certificate. An attacker able to reach the HTTPS API could therefore present their own key and add the public copy of a trusted certificate. Canonical rates the issue as **10.0** and indicates that a cluster member identity could be spoofed as a result.

## What mTLS is supposed to prove

In a TLS connection with client authentication, the client presents a certificate and demonstrates that it holds the associated private key. The server can then ask if *this proven certificate* belongs to its trusted list, then determine the rights corresponding to this identity. A chain can contain other certificates to explain a signing relationship. Their presence in the message does not prove that the client owns all associated private keys. They are, by definition, public data that the peer can assemble and transmit.

The authorization check crossed the trust boundary at the wrong point. The HTTPS listener requested a client certificate without verifying it during the handshake; the application would then iterate through **all** the received certificates and compare each one to the trust store. The handshake attested to the key of the first element, but the application could retain a subsequent element as its identity. The correct reasoning is: "the leaf certificate key has been proven, and this leaf certificate is authorized." The faulty reasoning was: "an authorized entry appears in the list sent by the client."

We can represent the error without providing a payload: `chain = [attacker_certificate, trusted_member_public_certificate]`. The cryptographic proof concerns the first term; the authorization test could pass on the second. Copying someone else's public certificate does not require knowing their private key. The [fix described by Canonical](https://github.com/canonical/lxd/security/advisories/GHSA-99jp-jwmc-65p4) precisely limits the comparison with the trust store to the first certificate.

## Why the scope goes beyond a simple API account

LXD manages containers, virtual machines and host system resources. A trusted API identity can therefore have extended privileges; Canonical says that depending on the impersonated identity, the attacker can achieve `root` access on the host. In a cluster, a server certificate from another member provides access to internal functions; the bulletin even states that the server certificate is exposed during TLS negotiations and can be used to reach the database gateway. MicroCloud experiences a variation of the same confusion when adding a member to the cluster.

The advisory lists the affected paths: Core API, Metrics, Cluster and Database Gateways, Certificate Renewal and Deletion, Token Enrollment, and VM Agent Connection. We should therefore not reduce the flaw to “someone can connect to the web interface”. The same hypothesis of identity circulated between several privileged operations.

The exposure, however, has a clear precondition: the attacker must be able to reach the HTTPS listener of LXD or MicroCloud. A service inaccessible from its network cannot be attacked in this way. The [Canonical advisory](https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557) recommends the update and specifies that no single parameter fixes the validation; restricting network access is the documented temporary measure.

## How to find an error of this type

An authorized audit can start by writing the security invariant: *the authorized identity must be the certificate whose private key was proven by the connection*. You must then follow the data between the TLS object of the server, the table of certificates transmitted and each authorization function. The decisive negative test is conceptual: a client with its own key, but only the public part of the authorized certificate, must never obtain the rights of the latter. This test covers operations that consult the trust directly, but also those that invoke cluster, metrics or renewal helpers.

A patch review would be particularly informative here: changing a full chain path to the leaf certificate fixes the ownership confusion. The review should also verify that no other calls reuse the unverified list as proof of identity. This method describes how to find the bug class; the [Canonical Bulletin](https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557) attributes the report to the Incus project, without publishing a full discovery log in this notice.

## Decide and check

Canonical announces patched versions **LXD 6.10.1, 5.21.9, 5.0.11 and 4.0.15**, as well as **MicroCloud 3.4.1 and 2.1.5** in their snap channels. The inventory should compare the actual installed version to the channel employed, monitor which hosts have the HTTPS API reachable, and then examine trust and administrative actions during the exposure window. If a compromise is suspected, changing a single certificate does not demonstrate that the internal functions or the host are healthy; the analysis must start from the privileges of the potentially usurped identity.

This flaw teaches a general rule: a certificate chain is a **set of data provided by the peer**; proof of key possession must be attached to the identity that the application authorizes, and never inferred from the mere presence of a public certificate in that set.

**Main sources:** [advisory LXD](https://github.com/canonical/lxd/security/advisories/GHSA-99jp-jwmc-65p4), [Canonical advisory](https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557).