A Trusted Public Certificate Authenticates as Any LXD Client

TL;DR

• LXD is a manager for system containers and virtual machines that runs on a Linux host and can be managed through an HTTPS API reachable over the network, and MicroCloud builds a cluster out of several such hosts.
• Mutual TLS is the mechanism that decides which client may call that API: the handshake proves possession of the private key belonging to the first certificate in the chain, and the server then matches certificates against its trust store.
• Until the fix published on 29 October 2026, LXD compared every certificate in the chain the client sent, including certificates the client chose, so a public certificate was enough to authenticate as another identity (CVE-2026-112816, CVSS 10.0).
• MicroCloud made the same mistake while a cluster member joins, and the advisory notes an attacker can intercept the public certificate of a joining member and authenticate as it.
• An impersonated identity reaches the cluster, the instances it runs, the database gateway, the metrics endpoint and the trust store self-service paths, and depending on the victim's privilege it reaches root on the host.
• The fix compares the leaf certificate and stops there; no setting turns the old behaviour back on, so an operator has network restriction and the 29 October snap releases.
• The flaw has been present since the initial release, which is the detail that should decide how far back an audit reaches.

A hypervisor API is the most privileged network service in a self-hosted estate. It creates machines, attaches storage, moves workloads and reads their memory through snapshots. LXD exposes that API over mutual TLS, with client certificates acting as the whole identity system, and the advisory Canonical published on 29 October 2026 describes a mistake in that identity system that had been there from the beginning.

The flaw is tracked as CVE-2026-112816 and scored 10.0. The advisory credits stgraber as reporter and notes that the issue reached the project from Incus, the fork, which found it and confirmed LXD shared it. Mutual TLS was the thing that was supposed to make the API safe to expose on a management network, and the sentence that matters in the advisory explains why it did not.

What mutual TLS was supposed to prove

During the TLS handshake, the client proves possession of the private key belonging to the first certificate it presented. The client supplies every remaining certificate in the chain. Middleware that treats the protocol's request for a client certificate as meaning the certificates have been verified builds its authorisation on a proof that never happened.

The GitHub advisory states the position plainly: the HTTPS listener requests client certificates without verifying them, so the handshake only proves the key of the first certificate, and the remaining certificates are entirely client controlled. The ownership check then compared every certificate in the presented chain against the trust store, which meant a client could authenticate as any trusted certificate whose public part it had, without the matching private key.

That is the whole vulnerability. The vulnerability lies in the authentication logic. A comparison against a list, applied to a set of values that the caller controls.

A chain the client controls

Where the public certificate comes from matters, and the answer is the part that surprises operators. Server certificates are returned by every TLS handshake, so an attacker needs no prior access to obtain one. Client certificates can be read by any trusted client through the certificates API, or collected from any server that client has connected to.

An attacker therefore starts with a public certificate obtained from a routine connection, appends it as an intermediary in its own chain, and is authenticated as that identity. Appending the server's own certificate grants access to the database gateway, and on a cluster, appending another member's certificate grants internal cluster access that bypasses authorisation entirely.

Where one impersonated identity reaches

The advisory lists the paths the same ownership check covered, and each one is a separate privilege. The main API gives cluster and instance control. The metrics endpoint exposes telemetry. The cluster and database gateways sit behind their own checks. Certificate self-renewal and self-deletion run through self-service paths, so an impersonated identity can renew or delete entries in the trust store. Token based enrolment and the connection between the host and its virtual machines use the same comparison.

Canonical's own summary of the impact stays careful and lands where it should: an attacker may gain trust with the daemon by impersonating another user with only that user's public client certificate, and depending on the privilege of the victim user, may gain root access to the host machine. Deleting a trust entry through the self-service path is the operational worst case, because the estate loses the record of who was trusted while the attacker keeps whatever access it obtained.

MicroCloud and the joining member

MicroCloud has its own version of the problem, and it is more specific. The advisory states that in MicroCloud an attacker can intercept the public TLS certificate of a joining cluster member and then authenticate as that member. A joining member is a privileged identity by design: it replicates configuration, holds storage credentials and participates in the control plane.

The fix compares the leaf and stops there

The patched behaviour is a smaller comparison: only the first certificate in the presented chain, whose key the handshake proves, is matched against the trust store. That single change covers the main API, the metrics endpoint, the cluster and database gateway checks, the self-renewal and self-deletion paths, token based enrolment and the virtual machine agent connection.

The advisory lists fixed snap channels released on 29 October 2026: LXD 6.10.1, 5.21.9, 5.0.11 and 4.0.15, and MicroCloud 3.4.1 and 2.1.5. Canonical notes that the point releases were rolling from candidate to stable, which is the sentence to check against your own host before assuming a refresh picked the fix up.

What an operator does on the day

Restricting network access to the HTTPS listener is the only workaround Canonical offers, and it says explicitly that no configuration based workaround exists. Both snap channels then need a refresh, and the service needs to be confirmed on the patched build, with the channel name treated as the starting point.

There is a second job that the advisory does not assign and that matters as much. The check has been wrong since the initial release, so any trust store built over that period deserves reading: which client certificates are trusted, who could read them, and whether every one of those identities still belongs in the list. An estate built to keep workloads under its own control is the reason sovereign infrastructure and cloud exit work gets funded, and the same choice concentrates a great deal of authority in one API that a public certificate used to satisfy.

The broader lesson for anyone building on mutual TLS is worth stating once, because it recurs. A trust decision belongs to the certificate whose key the protocol proved, and every other certificate in a chain is a claim the caller wrote down. Middleware that checks the chain and calls it authentication turns a list of public documents into a set of keys.

Sources

• Security advisory: Critical vulnerability found in Canonical LXD and MicroCloud, Canonical, 2026-10-29, discourse.ubuntu.com
• GHSA-99jp-jwmc-65p4, Authentication bypass through unverified client certificate chains, Canonical, 2026-11-04, github.com
• CVE-2026-112816 record, CNA Canonical Ltd., 2026-10-30, cve.org

Source: the Canonical security advisory of 29 October 2026, the GitHub advisory published 4 November 2026 and the CVE.org record, read in full. The CVSS score, the affected and patched versions, the authentication logic, the paths the check covers, the MicroCloud scenario, the workaround and the snap channels come from those three documents.