LXD Flaw Enables Keyless Client Impersonation

CVE-2026-112816 allowed an attacker to authenticate to LXD or MicroCloud as a trusted client without possessing that client’s private key. The attacker needed network access to the HTTPS API and a copy of a trusted client’s public certificate. Canonical assigned the flaw a CVSS score of 10.0.

Successful impersonation gave the attacker the trusted client’s access to the cluster and its virtual machines. Canonical said impersonating a privileged account could provide root access to the host machine.

The server trusted the wrong certificate

LXD and MicroCloud support remote API access through mutual TLS. The server maintains a trust store containing the certificates of clients it accepts. During authentication, the client presents a certificate chain, and the server decides whether the connection belongs to a trusted identity.

A TLS connection proves possession of the private key corresponding to the first certificate in that chain, known as the leaf certificate. Certificates attached later in the chain do not receive the same proof. They are data supplied by the client as part of the handshake.

The vulnerable verification code compared every certificate supplied by the client with the server’s trust store. An attacker could authenticate with a certificate and private key they controlled, then append a trusted client’s public certificate to the chain. When the server found that trusted certificate, it treated the connection as belonging to the trusted client.

Public certificates are not secrets, so possession of one should never substitute for proof of its private key. The vulnerable check turned the trust store from a list of authenticated identities into a list of certificates that merely had to appear somewhere in client-controlled input.

Exposure depends on the API listener

Exploitation requires access to the HTTPS API. Standalone LXD listens only on a local socket by default. It becomes remotely reachable when an administrator enables the network API through the core.https_address setting. Operators who enabled that listener should examine which networks and hosts can reach it.

MicroCloud has additional exposure during cluster formation. Canonical said an attacker who captures a member’s public certificate while that member joins the cluster can subsequently authenticate as the member.

The affected releases listed in the CVE record are LXD 4.0.14, 5.0.10, 5.21.8, and 6.9, in each case before the following fixed release. Ubuntu archive packages are listed as unaffected or not shipped. Canonical distributes the relevant fixed LXD releases as snaps.

The Incus project discovered and reported the issue. Incus, a community fork of LXD, fixed the flaw in version 7.6.0 alongside 17 other security issues.

Update and verify the installed version

Snap installations can be refreshed with:

sudo snap refresh lxd
sudo snap refresh microcloud

Canonical said the fixed LXD point releases were moving from the candidate channel to stable when it published its advisory. A successful refresh therefore does not by itself establish that the installed build contains the fix. Check the resulting version after updating.

Canonical provided no temporary LXD workaround. Incus likewise said there is no configuration fix. Until patched versions are installed, restrict network access to the API listener to the smallest required set of systems. Incus users should update to 7.6.0.

As of the U.S. CISA assessment dated October 30, the vulnerability was not known to have been exploited. It was absent from CISA’s Known Exploited Vulnerabilities catalog, and no working exploit had been published.