A public cert now gets full cluster access on Canonical LXD, patch today

A trusted peer's public TLS certificate now logs in as that peer to a Canonical LXD or MicroCloud cluster. The National Vulnerability Database rates the bug 10.0, its highest score. The fix is one snap refresh. The public certificate is not a secret.

Canonical's Mark Laing posted the advisory on Ubuntu Discourse on 28 October. The bug is tracked as CVE-2026-112816. It affects LXD 4.0 up to 4.0.14, 5.0 up to 5.0.10, 5.21 up to 5.21.8, and 6.9. The MicroCloud snap on 2.x and 3.x is also affected. The fixed versions reached the stable snap channels on 29 October.

What the bug is

Canonical writes that the remote API used mutual TLS to authenticate clients. It compared every peer certificate the client sent against the trust store. Only the final certificate in a chain proves ownership of the signing key. Comparing the others is the bug.

A trusted client's public certificate is enough. An attacker puts it anywhere in the chain. The API then accepts the attacker as that client. In MicroCloud, the public TLS certificate of a joining cluster member can be intercepted on the wire. The attacker then authenticates as that joined member.

The impact is total. The advisory says an attacker can gain trust with the daemon, impersonating another user with only their public certificate. Canonical adds that the attacker may gain root access to the host machine, depending on the victim's privilege. The National Vulnerability Database records the attack as remote. It needs no credentials, no user action, and no complex setup. CISA's coordinator record says automation is possible and the technical impact total.

Canonical thanks the Incus project, from which the issue was referred. Incus is a fork of LXD. The two share enough code that the same mistake affects both.

How to patch

Canonical lists the fixed snap versions by channel: LXD 6.10.1 on 6/stable, 5.21.9 on 5.21/stable, 5.0.11 on 5.0/stable and 4.0.15 on 4.0/stable. Each landed on 29 October. MicroCloud 2.1.5 is on 2/stable and 3.4.1 is on 3/stable, same date. Canonical adds that the LXD point releases are in progressive roll-out from candidate to stable. A cluster still waiting for the update should pin the fixed version or move to the candidate channel.

The team's own instructions are two commands: sudo snap refresh lxd and sudo snap refresh microcloud.

The hard part is not the patch. Who could have a trusted peer's public certificate? Anyone who ever saw a copy of the certs directory. Anyone who scraped one from a backup. Anyone the cluster ever handed one to. A public key was never written to resist being read. The server's own code was the defence, and that code was wrong until last week.

A team running LXD on anything that an attacker can reach should treat this as a job for today. An internal network counts. The LXD API listens on port 8443 by default and is the whole target.

Source

Ubuntu Discourse: Security advisory, Critical vulnerability found in Canonical LXD and MicroCloud, by markylaing, Canonical, with details at CVE-2026-112816 and in the National Vulnerability Database.