Critical LXD and MicroCloud flaw allows root access without private keys

Canonical has released emergency patches for a critical security flaw in its LXD container hypervisor and MicroCloud clustering tool. The vulnerability, tracked as CVE-2026-112816, carries a maximum severity score of 10.0 on the Common Vulnerability Scoring System. It allows remote attackers to impersonate trusted clients and gain unauthorized access to infrastructure without possessing the necessary private cryptographic keys.

What happened

The flaw enables an attacker to log in as a trusted client by exploiting a verification error in the mutual TLS authentication process. To succeed, the attacker needs network access to the HTTPS API and the public certificate of a client that the server already trusts. Once authenticated, the attacker acts as that client, gaining full access to the cluster and its virtual machines. If the impersonated account holds privileged rights, the attacker can escalate to root access on the host machine itself.

This issue was originally reported by the Incus project, a community fork of LXD, which confirmed the bug affected both platforms. While Ubuntu’s standard archive packages for LXD are not affected, users running LXD or MicroCloud via Snap packages are at risk. Canonical has stated that there is no evidence this vulnerability has been exploited in the wild, and it does not currently appear on the CISA Known Exploited Vulnerabilities list. However, the potential impact is severe enough to warrant immediate attention from infrastructure teams.

How it works

LXD and MicroCloud use mutual TLS (mTLS) to secure remote API access. In this setup, a client proves its identity by presenting a digital certificate. The server checks this certificate against a trust store, which contains the identities of all allowed clients. The vulnerability lies in how the server validates the certificate chain during this handshake.

In a standard TLS connection, the protocol only cryptographically proves that the client owns the private key for the first certificate in the chain, known as the leaf certificate. The rest of the chain is simply data attached by the client. The flawed implementation in LXD compared every certificate in the provided chain against the trust store, rather than strictly validating the leaf. An attacker could take a trusted client’s public certificate, which is not secret, and attach it to their own chain. The server would then mistakenly accept the attacker as the trusted client because it found a match in the chain, even though the attacker did not possess the corresponding private key for that specific certificate.

Key details

• Vulnerability ID: CVE-2026-112816 with a CVSS score of 10.0.
• Affected products: LXD versions 4.0.14, 5.0.10, 5.21.8, and 6.9, along with MicroCloud clusters.
• Fixed versions: LXD 6.10.1, 5.21.9, 5.0.11, 4.0.15, and MicroCloud 3.4.1 or 2.1.5 via Snap channels.
• Attack requirements: Network access to the HTTPS API and possession of a trusted client’s public certificate.
• Origin: Reported by the Incus project, which released its own fix in version 7.6.0.
• Exploit status: No known active exploitation or public exploit code exists as of October 30, 2026.

Why it matters

For engineers managing containerized infrastructure, this vulnerability undermines the fundamental trust model of mTLS. Mutual TLS is often relied upon as a strong authentication mechanism because it requires possession of a private key. This flaw bypasses that requirement entirely, meaning that merely having a public certificate, which is often distributed openly or captured during network joins, is sufficient for impersonation. This is particularly dangerous for MicroCloud environments, where an attacker who captures a member’s public certificate during the cluster joining process can subsequently impersonate that member.

The impact extends beyond simple data access. Because LXD manages system-level containers, a successful impersonation of a privileged client can lead to full host compromise. This grants the attacker root access to the underlying physical or virtual machine, allowing them to escape the container environment entirely. For teams using LXD in production, especially those exposing the API over a network, this represents a critical failure in access control that cannot be mitigated by configuration changes alone.

What you can do

• Update your LXD and MicroCloud installations immediately using sudo snap refresh lxd and sudo snap refresh microcloud.
• Verify the installed version after refreshing, as fixes may roll out from candidate to stable channels gradually.
• Restrict network access to the LXD API listener if you cannot update immediately, as the attack requires direct HTTPS API access.
• Check if your standalone LXD server has core.https_address enabled; if not, it is likely not exposed to this specific remote attack vector.
• Monitor for any unusual activity in cluster membership or API logs that might indicate attempted impersonation.
• If you are using Incus instead of LXD, upgrade to version 7.6.0 or later to address this and 17 other security issues.