LXD Certificate Bypass Turns A Public Certificate Into Cluster Trust

Canonical has disclosed CVE-2026-112816, a critical authentication bypass in LXD and MicroCloud. The HTTPS listener proved possession of the private key only for the first certificate in a client-presented chain, but authentication code compared every certificate in that chain with trusted entries. An attacker able to reach the listener could present a certificate they controlled, append the public certificate of a trusted client or server, and be accepted as that trusted identity without possessing its private key.

Canonical says the flaw dates to the initial release and can reach the main API, metrics endpoint, cluster and database gateways, certificate self-service paths, enrollment and virtual-machine agent connections. The stable fixes are LXD 4.0.15, 5.0.11, 5.21.9 and 6.10.1, plus MicroCloud 2.1.5 and 3.4.1. Network restriction is the only documented temporary workaround; there is no configuration-only fix. Administrators should patch first, preserve edge and API evidence, inventory trusted identities and cluster membership, and investigate management-plane changes before deciding which trust material to replace.

In mutual TLS, the handshake proves that the connecting client holds the private key for the leaf certificate it presents. A client may also send additional certificates to help the peer build a chain. Those extra certificates describe a path; their presence does not prove that the client holds each corresponding private key. LXD's HTTPS listener requested certificates without independently verifying the whole client-supplied chain, while later authentication checks looked for a trusted match anywhere in that chain.

That mismatch created the bypass. An attacker could make a leaf certificate and prove possession of its key, then append the public portion of a trusted LXD certificate. The trust check could find the appended certificate and accept the request as that identity even though the handshake proved only the attacker's leaf. The patch changes the comparison so only the first certificate, whose private-key possession the handshake establishes, is matched against the trust store.

This is not a break in TLS encryption, a stolen server key or a forged certificate signed by a trusted certificate authority. Public certificates are designed to be shared. The security failure was treating a public object placed deeper in an attacker-controlled list as proof of the identity bound to it. Rotating a public certificate without correcting that logic would only replace the value an attacker needs to append.

Canonical says any client able to reach the LXD HTTPS listener can authenticate as any trusted client, metrics or server certificate for which it has the public certificate. Server certificates are returned in ordinary TLS handshakes, so the server's own public certificate is available without prior authentication. The advisory says appending that certificate can grant access to the database gateway. In a cluster, another member's certificate can grant internal cluster access and bypass authorization entirely.

The same validation pattern affected the main API, metrics endpoint, cluster and database gateway checks, certificate self-renewal and self-deletion, token-based certificate enrollment and the agent connection between hosts and virtual machines. That list matters because blocking one user-facing route does not demonstrate that every affected trust path is unreachable. Inventory endpoints by function, address and network path rather than assuming the web UI is the whole management plane.

Canonical also calls out MicroCloud. During cluster joining, an attacker able to intercept a joining member's public TLS certificate could later impersonate that member. The company says the resulting privilege depends on the identity being impersonated and may include root access to the host. Its public announcement does not report observed exploitation, so administrators should describe exposure and evidence separately rather than treating every reachable server as compromised.

Canonical's fixed stable snap versions are LXD 4.0.15 on the 4.0 channel, 5.0.11 on 5.0, 5.21.9 on 5.21 and 6.10.1 on 6. MicroCloud fixes are 2.1.5 and 3.4.1. The repository advisory also lists LXD 6.10.0 as patched, but Canonical's operational notice directs users to the latest versions in their channels and identifies 6.10.1 as the stable fixed release. Production validation should follow the installed channel and the version actually running on every node.

The advisory's affected-version field names 4.0.14, 5.0.10, 5.21.8 and 6.9, while its description says the faulty behavior existed from the initial release. Administrators on older releases should not infer safety from the short affected list. Move to a listed fixed release or a newer supported version containing the correction. For snap installations, Canonical's response command is `sudo snap refresh lxd`, with a separate `sudo snap refresh microcloud` where applicable.

A cluster is complete only when every management endpoint has been checked. Record the snap channel, installed revision, daemon version and refresh time per member. Confirm that the service restarted into the corrected build and that a load balancer, direct member address or disaster-recovery node does not still expose an older listener. Keep this evidence with the incident record rather than relying on a package-manager command that may have been deferred by progressive rollout or local hold policy.

Canonical's only documented workaround is to restrict access to the HTTPS listener to trusted hosts, and it says there is no configuration-based workaround. LXD is not remotely reachable over HTTPS by default until `core.https_address` is configured, but many production clusters expose the API for the CLI, web UI, automation, metrics or inter-node operations. Inspect the effective bind address on every member and enumerate every route through firewalls, load balancers, VPNs and management networks.

Remove internet reachability where it is not strictly required. Bind the management listener to a dedicated address, allow only named administrative and cluster sources, and enforce the same policy at host and upstream firewalls. A broad private network is not automatically trusted: a compromised workstation, tenant workload or adjacent service may still reach the listener. Log both allowed and denied connections so the temporary control produces evidence as well as prevention.

Do not substitute OIDC, project restrictions or a different client role for the patch. The vulnerable decision occurred before normal authorization could be trusted, and the advisory says a cluster-member identity bypasses authorization entirely. Least privilege still matters after the fix, but it cannot repair an authentication layer that accepts the wrong certificate from the presented chain.

Before rotating trust entries, preserve reverse-proxy, firewall, load-balancer and LXD API logs, plus authentication and cluster events if retained. Look for management connections from unexpected source addresses, unusual use of server or cluster identities, certificate renewals or deletions, new enrollment, cluster membership changes and database-gateway access. Because a forged request can be attributed to an existing trusted identity, source, timing and requested operations may be more useful than the displayed identity alone.

Review the resulting control-plane state. Inventory instances, profiles, projects, images, storage and network configuration; inspect new or changed privileged instances; compare cluster members and trust entries with an approved baseline; and review snapshots, migrations, file operations and console or execution activity. LXD documentation notes that unrestricted server administration is equivalent to full daemon authority and can reach host-level outcomes, so a successful bypass should not be scoped as a web-console event only.

Patch before changing certificates. Then remove unknown identities, revoke suspicious tokens, replace trust material whose use cannot be explained and validate cluster links or automation from known-good clients. Rotating the server certificate by itself is neither a workaround nor proof of recovery because the old vulnerability consumed public certificate material rather than requiring the private key. Rebuild a host or cluster member when evidence shows unauthorized root-level action or when logging gaps prevent a trustworthy state comparison.

After patching, minimize the number of certificates that carry broad authority. LXD supports restricted TLS certificates and fine-grained authorization for identities and groups. Use project-scoped or resource-scoped permissions where operations permit, separate human administration from automation, and remove stale client entries. A certificate that no longer has an owner or business purpose is still an impersonation target if another validation defect appears later.

Keep the HTTPS listener on a management plane, alert on changes to trust entries and cluster membership, and retain enough API history to reconstruct high-risk operations. Test emergency patching across all supported channels and cluster members. The corrective release arrived across four LXD channel lines and two MicroCloud lines; an inventory that records only the product name will not show which nodes actually crossed the fixed boundary.

The central lesson is precise. Certificate chains carry public assertions, while authentication depends on proof tied to the correct private key and the correct position in that chain. Systems that separate TLS termination from application authorization should document which verified identity is passed across that boundary and test malformed or reordered chains. Here, the patch is the primary control, reachability limits reduce exposure, and post-patch evidence determines whether recovery must extend to workloads and hosts.