Canonical has disclosed a critical authentication-bypass vulnerability in LXD and MicroCloud that lets an attacker impersonate a trusted client without having its private key. Tracked as CVE-2026-112816, the flaw has a maximum CVSS score of 10.0 and can allow control of containers, virtual machines, cluster resources, and, depending on the victim’s permissions, the host machine.
Key Points
- CVE-2026-112816 affects certain LXD and MicroCloud releases and bypasses client authentication.
- An attacker needs network access and a trusted client’s public certificate, but not its private key.
- Clustered LXD and MicroCloud systems face the most relevant exposure because members communicate over the network.
- Fixed versions are available, and administrators should update immediately and restrict access until updates are installed.
How the flaw works
Canonical said the issue was reported by the Incus project and was later confirmed to affect LXD. LXD and MicroCloud use mutual TLS for remote client authentication, and a client certificate is trusted when it appears in the server’s trust store.
The vulnerability is caused by improper validation of the client certificate chain. The server incorrectly checks every certificate presented in the chain against the trust store, rather than using only the first, or leaf, certificate to identify the client.
During the TLS handshake, the client proves possession of the private key linked to the leaf certificate. Certificates later in the chain are supplied by the client and do not by themselves prove that the client controls their private keys. An attacker can therefore create or use a certificate and private key of their own, place a trusted client’s public certificate later in the presented chain, and cause the server to treat the connection as belonging to that trusted client.
A technical analysis described the vulnerable behavior as a loop over the full PeerCertificates collection instead of limiting identity resolution to the leaf certificate at index zero. The analysis classifies the flaw as CWE-295, Improper Certificate Validation.
Exposure and possible impact
An attacker needs network access to the LXD or MicroCloud HTTPS API and the public certificate of a client already trusted by the server. The trusted client’s private key is not required. The conventional LXD API port is TCP 8443, although administrators can configure a different listener port.
A default standalone LXD installation does not normally expose the HTTPS API over the network. It usually listens on a local Unix socket, and network exposure begins when an administrator enables the HTTPS listener through core.https_address.
Clustered LXD and MicroCloud deployments have a more relevant exposure path because their members need network-based communication. In MicroCloud environments, an attacker may intercept the public TLS certificate of a cluster member while that member is joining the cluster, then use the certificate to authenticate as that member.
The attacker receives the permissions assigned to the impersonated certificate. If the certificate belongs to a privileged client or cluster member, the attacker may control containers, virtual machines, and other cluster resources. Canonical said that, depending on the privileges of the impersonated user, the attacker may gain “root access to the host machine.”
A technical analysis said an unrestricted LXD client can control instances and may use privileged container and host-filesystem operations to reach the underlying host. The possible impact therefore depends on the permissions associated with the client certificate that is being impersonated.
Affected versions and fixes
The affected LXD versions listed by the research sources are LXD 4.0.14 and earlier in the 4.0 series, LXD 5.0.10 and earlier in the 5.0 series, LXD 5.21.8 and earlier in the 5.21 series, and LXD 6.9 and earlier in the 6.x series.
The listed fixed LXD versions are 4.0.15, 5.0.11, 5.21.9, and 6.10.1. The fixed MicroCloud versions are 2.1.5 and 3.4.1. Incus, the community fork from which the issue was reported, fixed the corresponding flaw in Incus 7.6.0.
The research sources describe Ubuntu archive packages of LXD as not affected or not shipped. The fixed LXD releases are distributed through snap packages.
Disclosure and response
Canonical’s advisory states that the issue was identified through collaboration with the Incus project and had been addressed in fixed releases. Canonical instructed users to update immediately and said: “All users must update their LXD and MicroCloud installations to the latest version available in their respective channels.”
For snap-based installations, the recommended commands are sudo snap refresh lxd and sudo snap refresh microcloud. Administrators should verify the installed versions after refreshing because Canonical’s fixed LXD point releases were progressively rolling out from candidate to stable channels.
The CVE record included a Cybersecurity and Infrastructure Security Agency assessment stating that there was no known exploitation at the time of assessment. The vulnerability was not listed in CISA’s Known Exploited Vulnerabilities catalog.
Public reporting indicated that laboratory reproduction and proof-of-concept material became available after disclosure. It also said there was no confirmed exploitation in the wild at the time covered by the report.
Temporary protection
No configuration setting has been identified as a complete fix. Until the software is updated, administrators should restrict network access to the LXD or MicroCloud HTTPS listener so that only trusted management and cluster networks can reach it.
Administrators should also review exposed listeners, especially on clustered systems, and check whether trusted client certificates could have been intercepted during MicroCloud cluster-member enrollment. Incus users should upgrade to version 7.6.0, while LXD and MicroCloud users should install the fixed releases for their product lines.
About the Author
