CVE-2026-112816 is an authentication bypass in Canonical LXD, the open-source platform used to manage Linux system containers and QEMU/KVM virtual machines from a CLI, web UI and REST API. It matters most where LXD is a clustered control plane: private clouds, hosting and data-centre environments, development and test estates, edge deployments, and teams provisioning Linux through MAAS, Juju or Ansible. MicroCloud deployments are affected too, because LXD is their workload control plane.
An unauthenticated network attacker does not need a legitimate LXD account or a stolen private key. They need reachability to the HTTPS listener and a copy of a certificate already trusted by the target. By supplying their own leaf certificate, then appending that trusted public certificate in a crafted client TLS chain, they can be recognised as the trusted identity. If that identity has sufficient privileges, Canonical says the result can include root access.
How a valid chain became a false identity
TLS proves control of the private key for the first certificate in a client chain: the leaf certificate. LXD instead fingerprinted and compared every certificate presented. That meant a trusted certificate placed later in the chain could decide the caller’s identity even though the caller did not possess its private key. The vulnerable 6.9 source shows the crucial iteration:
peerCertificateFingerprints := make([]string, 0, len(r.TLS.PeerCertificates))
peerCertificates := make(map[string]x509.Certificate, len(r.TLS.PeerCertificates))
for _, c := range r.TLS.PeerCertificates {
f := shared.CertFingerprint(c)
peerCertificates[f] = *c
peerCertificateFingerprints = append(peerCertificateFingerprints, f)
}The advisory’s description makes clear that the intended check is against the first certificate only. The wider blast radius is notable: Canonical’s detailed advisory says the defect touches the main API, metrics, cluster and database gateways, certificate lifecycle operations, token enrolment and VM-agent connections.
Patch promptly, but verify how you consume LXD
Canonical shipped fixed snap builds: LXD 4.0.15, 5.0.11, 5.21.9 and 6.10.1, plus MicroCloud 2.1.5 and 3.4.1. Refresh the lxd and microcloud snaps, confirm the deployed channel actually reached the fixed build, and restrict HTTPS management exposure to administrative networks while the update rolls out. Review trusted client certificates and cluster audit logs as well: a successful impersonation can look like actions by a legitimate administrator.
Version scope needs care. The Ubuntu record names narrow affected point-release ranges, while Canonical’s GitHub advisory says the flaw existed since the initial release, and Debian marks older LXD packages vulnerable with no fixed package. Teams using Debian packages should not assume a snap fix applies; obtain a distribution fix or isolate the service until one is available. Canonical’s public source tags also appeared to retain the all-chain loop, so the precise implementation of the correction could not be independently confirmed from those tags.
No confirmed attacks, but reproducible conditions
As of November 5, no confirmed exploitation, campaign, victim incident or attacker infrastructure had surfaced. CISA enrichment recorded exploitation as “none,” although direct inspection of the live KEV feed was not possible; no KEV entry surfaced in available checks. A public lab PoC is now available, but Canonical’s own advisory has no PoC, and the claimed October 31 exploit-publication date could not be verified.
This is the kind of control-plane flaw that turns one exposed listener into cluster-wide authority. Use SecAlerts to monitor the software your organisation actually runs and alert on newly affecting vulnerabilities, then make certificate-authentication paths part of the remediation check—not just the version number.
