Canonical Patches CVSS 10.0 Flaw in LXD and MicroCloud That Lets Attackers Log In as Trusted Clients

A critical flaw in Canonical's LXD and MicroCloud lets an attacker authenticate as any trusted TLS client without holding that client's private key. It is tracked as CVE-2026-112816 and carries a CVSS score of 10.0, the maximum.

Canonical posted its security advisory on Oct. 28 and listed fixed snap releases dated Oct. 29. The CVE was published Oct. 30.

How the bypass works

LXD and MicroCloud let remote clients reach their APIs over mutual TLS. The client presents a certificate, and the server accepts it if the certificate is in its trust store.

The bug is in how the server checked that certificate. Canonical's advisory says the authentication logic compared ALL peer certificates the client sent against the trust store. But only the first certificate in the chain, the leaf, proves the client owns the signing key. Everything behind it is whatever the client chooses to attach.

So an attacker can take a trusted client's public certificate, which is not a secret, place it behind their own certificate in the chain, and the server treats them as that trusted client.

Canonical says that, depending on the privilege of the impersonated user, the attacker "may gain root access to the host machine." The CVE entry describes the outcome as full access to the cluster and the virtual machines it manages.

What an attacker needs

Two things: network access to the LXD HTTPS API, and the public certificate of a client the server already trusts.

That narrows the exposure. A standalone LXD server does not expose the API to the network by default. It listens only on a local socket unless an administrator enables the network API with the core.https_address setting.

MicroCloud has a specific weak point. Canonical says an attacker who can intercept a joining cluster member's public certificate can then authenticate as that member. MicroCloud ties several machines running LXD into one cluster.

The CVSS vector rates the attack as network-reachable, low complexity, no privileges and no user interaction. That is how it reaches 10.0. The certificate requirement is the practical hurdle.

Who found it, and what is fixed

The Incus project, which began as a community fork of LXD, referred the bug to Canonical. Canonical confirmed LXD was affected too. Incus fixed the same flaw in version 7.6.0. Canonical thanked Incus's Stéphane Graber, who goes by stgraber, for his collaboration.

Affected LXD ranges are 4.0.14, 5.0.10, 5.21.8 and 6.9.0, each up to the fixed release on the same branch. Canonical's fixed snap versions, all dated Oct. 29:

• LXD 6.10.1 (6/stable)
• LXD 5.21.9 (5.21/stable)
• LXD 5.0.11 (5.0/stable)
• LXD 4.0.15 (4.0/stable)
• MicroCloud 2.1.5 (2/stable)
• MicroCloud 3.4.1 (3/stable)

The fixes ship as snaps. Ubuntu's own archive packages of LXD are listed as not affected or not shipped.

Exploitation status

No attack has been reported. CISA's assessment, dated Oct. 30, says the flaw is not known to have been exploited. It is not on CISA's Known Exploited Vulnerabilities list. The assessment does flag the flaw as automatable and its technical impact as total.

The status of public exploit code is less settled. The Hacker News reports that no working exploit has been published. A separate CVE-tracking feed, cve.now, says a proof of concept is on GitHub and lists two repositories carrying the CVE number. Canonical has not addressed either claim.

The same feed also cautions that absence from CISA's list does not prove the flaw has not been attacked, since vendors and researchers can report attacks before CISA catalogs them.

What administrators should do

Canonical's instruction is to update immediately. On snap installs:

• sudo snap refresh lxd
• sudo snap refresh microcloud

Canonical said the LXD point releases were still in progressive rollout from the candidate channel to stable when it published the advisory. A refresh may not pull the fixed build on every machine yet. Administrators can confirm what they are running with lxd --version or snap list lxd and compare it against the fixed versions above.

Where the network API is not needed, leaving core.https_address unset keeps the HTTPS listener off, which is the default for a standalone server.

What remains unanswered is whether the public proof-of-concept code works as advertised, and whether anyone used the flaw before the Oct. 29 patches.