LXD and MicroCloud fix a flaw that lets a public certificate log in

LXD and MicroCloud fix a flaw that lets a public certificate log in

28 October 2026: Canonical has fixed CVE-2026-112816, a critical authentication bypass in LXD and MicroCloud that lets an attacker who can reach the LXD HTTPS API authenticate as any trusted TLS client whose public certificate they hold, and so gain root on the host if that client is privileged. Canonical published no workaround: every user is told to refresh the snaps now.

Not yet independently verified. This rests on Canonical's own advisory. We have not yet read the NVD entry or a severity score from a second source, and Canonical says the point releases were still rolling out from candidate to stable when it published. We will update this when it can be confirmed, and remove this note.

How a public certificate became enough

LXD authenticates remote clients with mutual TLS. Canonical's advisory says the daemon compared every certificate the client sent against its trust store, when only the leaf certificate proves that the client holds the matching private key. An attacker could therefore send their own certificate as the leaf and slip a trusted client's public certificate into the chain as an intermediate, and LXD would accept the connection as that trusted client.

Public certificates are not secrets. They sit in configuration files, cluster join records and backups, so the only real barrier was network reach to the API.

MicroCloud has a second route to the same result. Canonical says an attacker can intercept the public TLS certificate of a member joining a cluster and then authenticate as that member once it has joined.

The flaw was referred to Canonical by the Incus project, the community fork of LXD, and Canonical confirmed that LXD is affected as well.

Fixed snap versions

Canonical lists these fixed builds, all released on 29 October:

Channel	Snap	Fixed version
6/stable	lxd	6.10.1
5.21/stable	lxd	5.21.9
5.0/stable	lxd	5.0.11
4.0/stable	lxd	4.0.15
3/stable	microcloud	3.4.1
2/stable	microcloud	2.1.5

The update is sudo snap refresh lxd and sudo snap refresh microcloud. Canonical notes that the LXD point releases were "in progressive roll out from candidate to stable" when it posted, so a host that refreshed early on 29 October may still be on the old build. Check the installed version with snap list lxd rather than trusting the refresh.

Who is most exposed

The risk is highest where the LXD API listens on a network address, which is the normal setup for clusters, remote management and any tooling that drives LXD over HTTPS. A host that only accepts the local Unix socket is not reachable this way. Long-lived 4.0 and 5.0 hosts deserve a direct look, since snaps pinned to an old track or held back from automatic refresh will not pick up the fix on their own.

After patching, review the trust store with lxc config trust list and remove clients nobody recognises, and look in the LXD logs for API sessions from addresses that do not belong to known management hosts. Canonical has not said whether the flaw has been used in attacks.

Our virtualization category lists 14 products for teams comparing container and virtual machine platforms.

Company profile on TrustList: Canonical

Related on TrustList:

• Linux TCP flaw CVE-2026-98432: Debian fixed, Ubuntu and RHEL waiting
• Linux kernel flaw lets a guest VM read and crash its host

Sources

• Canonical (Ubuntu Discourse): Security advisory: Critical vulnerability found in Canonical LXD and MicroCloud, 28 October 2026