Canonical LXD Certificate Chain Authentication Bypass (CVE-2026-112816)

The CVE record says improper certificate validation in the LXD HTTPS listener lets an unauthenticated attacker "authenticate as any trusted client." The attacker then gains full access to the cluster and its managed virtual machines. Canonical, the CVE numbering authority, rates it CVSS 4.0 10.0 Critical.

LXD is Canonical's open source container and virtual machine manager. Remote clients sign in to its HTTPS API with mutual TLS, so the client also presents a certificate. LXD then looks for that certificate in its trust store.

How the Bypass Works

Canonical says LXD compared every certificate the client sent with its trust store. Only the first one, the leaf, proves that the client holds the matching private key. An attacker could add a trusted client's public certificate further down the chain and be accepted as that client.

A public certificate is not a secret. Canonical says the attacker needs only that public part and network access to the HTTPS API. Depending on the rights of the impersonated client, Canonical says the attacker may gain root access to the host machine.

MicroCloud, Canonical's LXD-based cloud platform, has a second route. Canonical says an attacker can intercept the public certificate of a member that joins a cluster. The attacker can then authenticate as that member.

What the Incus Advisory Adds

Canonical says the Incus project referred the flaw, and that it confirmed LXD is affected too. Incus is a community alternative to LXD, led by many of the people who once created LXD. Its advisory GHSA-xg75-xf37-cph9 describes the same bug in Incus.

Incus says every TLS handshake returns the server certificate, so an attacker needs no prior access to get one. On a cluster, appending another member's certificate grants internal cluster access. Incus adds that the flaw also affects the agent link between the host and its virtual machines.

These details describe Incus code. Canonical's own GitHub advisory for LXD was not public when we checked on 31 October, so we have not confirmed each point for LXD.

Is the HTTPS Listener On by Default?

No. LXD's documentation says that by default it "can be used only by local users through a Unix socket and is not accessible over the network." The HTTPS API starts listening once an admin sets core.https_address. By that documentation, a standalone host that never set it has no listener to attack.

Remote clients and the LXD web UI need the listener, and the documentation says the UI "requires LXD to be exposed to the network." Clustered setups also carry traffic over the network through cluster.https_address. Check each host before you treat it as safe.

What Our Checks Showed

These are the public signals we checked on 31 October 2026.

The Blackhole post is a daily digest of critical CVEs on a Telegram news channel. It adds nothing beyond the CVE record. Canonical's advisory does not say whether anyone has exploited the flaw.

Other recent flaws also let attackers skip the login on a management interface, such as the Cisco SD-WAN authentication bypass. Our certificate authority glossary entry explains how certificate chains are meant to work.

The CVE record lists four affected LXD ranges, each fixed by a new point release. Canonical ships LXD as a snap, with one channel per release track.

For the 5.21, 5.0 and 4.0 tracks the record lists only the newest release before the fix. Canonical tells all LXD and MicroCloud users to update, and Incus says its copy of the bug dates from its first release. We therefore treat older LXD releases as unverified, not as safe.

When we checked the Snap Store at 02:12 UTC on 31 October, the 5.21, 5.0 and 4.0 stable channels still served the vulnerable builds. The fixed builds were on the candidate channels. Canonical says all LXD point releases are in "progressive roll out from candidate to stable."

The Snapcraft documentation says snaps update on their own, four times a day by default. A refresh hold can delay that by up to 90 days. A host with a hold, or on the 5.21, 5.0 or 4.0 track, may stay vulnerable until someone checks it.

Ubuntu's CVE page lists the lxd deb package as not affected or not in release for every Ubuntu version. Canonical's fix instructions use snap refresh, not apt. Ubuntu gives the issue Medium priority, while the CNA score is 10.0. Our vulnerability management guide covers how to plan and check a rollout.