Canonical has fixed a critical authentication flaw in LXD and MicroCloud. Its advisory says the bug “allows an attacker that is able to reach the LXD HTTPS API to authenticate as any trusted TLS client, for which the attacker has the public certificate.” The issue is tracked as CVE-2026-112816 and carries a CVSS 4.0 score of 10.0, the maximum.
How it worked
LXD authenticates remote clients with mutual TLS. The server compared every certificate the client sent against its trust store. Only the leaf certificate proves the client holds the signing key. So an attacker could put a trusted client’s public certificate into the chain as an intermediate and be accepted as that client.
Public certificates are not secret. Canonical says that, depending on the privilege of the impersonated user, “the attacker may gain root access to the host machine.” In MicroCloud, an attacker could intercept the public certificate of a member joining the cluster and then authenticate as that member.
Canonical says the flaw was referred by the Incus project and confirmed to affect LXD too.
Fixed versions
| Snap | Channel | Fixed version |
|---|---|---|
| lxd | 6/stable | 6.10.1 |
| lxd | 5.21/stable | 5.21.9 |
| lxd | 5.0/stable | 5.0.11 |
| lxd | 4.0/stable | 4.0.15 |
| microcloud | 3/stable | 3.4.1 |
| microcloud | 2/stable | 2.1.5 |
All were released on 29 October. Canonical’s fix is:
sudo snap refresh lxd
sudo snap refresh microcloudCanonical notes the point releases were rolling out progressively from candidate to stable, so run snap list lxd microcloud afterwards and confirm you have the version above for your channel.
Who is exposed
By default, LXD’s documentation says, LXD is reachable only through a local Unix socket. The network API is on only if core.https_address is set. Check with lxc config get core.https_address. As of 2 November the flaw was not in CISA’s Known Exploited Vulnerabilities catalogue.
This is the same class of mistake as a certificate check that skips part of the job, which we covered in a valid certificate still needs to match the hostname.
Why this matters
If you run LXD hosts for agent sandboxes, CI runners or dev VMs with the API exposed, refresh today and confirm the version. Unlike the ClickHouse flaw, where the attacker needed no credentials at all, this one needs a trusted client’s public certificate, but that is material you share freely, so treat it as nearly as easy. While you are there, close core.https_address on hosts that do not need remote access.
The Campfire
CommentsThanks. Your comment is waiting for the desk. Once it is approved it appears here within about a minute.
Add a comment