LXD and MicroCloud patch flaw that let public certificates impersonate trusted clients

Canonical released patched builds of LXD and MicroCloud on 29 October 2026 for a flaw that undermines the client identity model of both products. Tracked as CVE-2026-112816 with a CVSS score of 10.0, the vulnerability allowed anyone holding a trusted public certificate to authenticate as an arbitrary client, with no private key required. According to a technical write-up on dev.to summarising Canonical's advisory, the faulty logic had been in place since the first release.

What went wrong

LXD manages system containers and virtual machines on a Linux host and is controlled through an HTTPS API exposed on the network, while MicroCloud assembles several such hosts into a cluster. Identity for that API rests entirely on mutual TLS: during the handshake, a client demonstrates possession of the private key tied to the first certificate in the chain it presents, and the daemon then checks the presented material against its trust store.

The bug sat in the second half of that arrangement. As the dev.to write-up explains, LXD's HTTPS listener requested client certificates but did not verify the chain, and the ownership check then compared every certificate in the chain, including intermediates the client chose itself, against the trust store. Because only the first certificate's key is proven by the handshake, a client could slip any public certificate into its chain and be accepted as that identity.

The advisory credits stgraber as the reporter, and the issue reached LXD through Incus, the project's fork, which discovered the defect and confirmed that LXD carried it too.

Where the certificate comes from

The attacker needs no prior access. Server certificates are handed out in every TLS handshake, and client certificates can be read by any trusted client through the certificates API or harvested from any server that client has connected to. An attacker appends one of these public certificates as an intermediary in its own chain and is authenticated as its owner. Appending the server's own certificate unlocks the database gateway, and on a cluster, appending another member's certificate yields internal cluster access that sidesteps authorisation checks.

What an impersonated identity reaches

The weak ownership check guarded several distinct surfaces. The main API grants cluster and instance control, the metrics endpoint exposes telemetry, and the cluster and database gateways sit behind the same comparison. Certificate self-renewal and self-deletion run through self-service paths, meaning an attacker can renew or delete trust store entries under someone else's name. Token-based enrolment and the connection between a host and its virtual machines rely on it as well. Canonical's own summary, relayed by dev.to, states that depending on the privilege of the impersonated user, an attacker may gain root access to the host machine.

MicroCloud during cluster joins

MicroCloud repeats the mistake while a new member joins a cluster. According to the advisory, an attacker who intercepts the public TLS certificate of a joining member can then authenticate as that member, an identity that is privileged by design because it replicates configuration across the cluster, carries storage credentials and takes part in the control plane.

The fix and what operators should do

The patched code compares only the leaf certificate, the single one whose key the handshake actually proves, and no configuration option restores the previous behaviour. Canonical published fixed snap channels on 29 October 2026: LXD 6.10.1, 5.21.9, 5.0.11 and 4.0.15, plus MicroCloud 3.4.1 and 2.1.5. The company noted that the point releases were still rolling from candidate to stable, so operators should confirm the running build rather than trust the channel name alone. The only workaround offered is restricting network access to the HTTPS listener, and Canonical states explicitly that no configuration-based workaround exists.

Why it matters

A container-host or hypervisor API is among the most sensitive services in a self-hosted estate: it creates machines, attaches storage, migrates workloads and can read their memory through snapshots. Its authentication has to rest exclusively on proofs the protocol actually delivers, and this flaw shows what happens when a trust check is applied to values the caller supplies. Two points deserve attention beyond LXD itself. First, the defect shipped with the initial release, so audits need to reach back through years of trust store entries and historical access rather than recent logs alone. Second, the pattern of comparing client-controlled chain data against a trusted list is a design mistake that other services implementing mutual TLS could repeat, and it took a review in the Incus fork to surface it upstream.