LXD Authentication Bypass: CVSS 10 Flaw CVE-2026-112816 in LXD and MicroCloud, and the Snap Versions to Install

Canonical has fixed a critical flaw in LXD and MicroCloud, CVE-2026-112816. It lets someone who can reach an LXD server over the network log in as one of that server's trusted clients without having the client's private key. If you run containers or virtual machines on LXD or MicroCloud and the management API can be reached over the network, update the snaps this week: the CVE record gives the flaw a score of 10 out of 10.

Neither Canonical nor the Incus project reports any attacks so far. But the fix is public, the bug has been described in detail, and an attacker needs no password. That makes the next few days the time to patch.

What happened with LXD and MicroCloud

LXD is Canonical's tool for running Linux system containers and virtual machines. MicroCloud packages LXD with storage and networking so you can run a cluster across a few machines. Both are installed as snaps.

Here is the confirmed timeline from the primary sources:

• October 28, 2026 (Wednesday): Canonical posted a security advisory on Ubuntu Discourse called "Critical vulnerability found in Canonical LXD and MicroCloud". It lists the fixed snap versions.
• October 29, 2026 (Thursday): The Incus project, a community fork of LXD, published advisory GHSA-xg75-xf37-cph9. It rates the flaw critical, with a CVSS 3.1 score of 10.0.
• October 30, 2026 (Friday): Canonical published CVE-2026-112816 with a CVSS 4.0 base score of 10. Incus 7.6 came out the same day with the fix.

Canonical says the issue was referred from the Incus project, and Canonical then confirmed that LXD is also affected.

How the LXD authentication bypass works

LXD clients prove who they are with TLS certificates. When a client connects, it sends a chain of certificates. The TLS handshake only proves that the client holds the private key for the first certificate in that chain, called the leaf. The client can put anything it likes in the rest of the chain.

The bug was that LXD checked every certificate in the chain against its list of trusted clients. An attacker could send their own certificate first and attach a trusted client's public certificate behind it. LXD found a trusted certificate in the chain and treated the attacker as that client.

Canonical lists two things the attacker needs:

• Network access to the LXD HTTPS API.
• The public certificate of a client the server already trusts.

Public certificates are not secret. The Incus advisory says client certificates "can be read by any trusted client through the certificates API" and can be "obtained from any server the client connected to." For MicroCloud, Canonical warns that an attacker could intercept the public certificate of a cluster member while it is joining.

The impact depends on which client is impersonated. Canonical says: "Depending on the privilege of the victim user, the attacker may gain root access to the host machine." The CVE record describes full access to the cluster and the virtual machines it manages.

What is confirmed and what is not known

Confirmed by Canonical, Incus or the CVE record:

• The CVE is CVE-2026-112816. Canonical assigned it and scored it CVSS 4.0 base 10.
• The fixed snap versions are the ones in the table below.
• Ubuntu's own security page lists the archive lxd package as not affected on 16.04, 18.04 and 20.04, and not shipped on 22.04 and later. The snap is what matters.
• CISA's enrichment in the CVE record, dated October 30, 2026, records exploitation as "none", automatable as "yes" and technical impact as "total".

Not known yet:

• Whether anyone has used it. Neither advisory reports attacks.
• How far back it goes. The CVE record names only the last release before the fix in each track. It does not say older builds are safe, and the Incus advisory says the bug in Incus has existed since its first release. Treat anything below the fixed version as affected.
• Incus 7.0 LTS. The Incus 7.6 release notes we read do not say whether the fix has reached the LTS branch.

LXD and MicroCloud fixed versions

Canonical says the LXD point releases are rolling out gradually from the candidate channel to stable. A refresh may not pick up the new build straight away, so check the version afterwards instead of assuming it updated.

How to patch LXD this week: a checklist

1. Find every host. Run snap list lxd microcloud on each Linux server, including test and lab machines. Check for Incus as well.
2. Check whether the API is on the network. Run lxc config get core.https_address. An empty result means a standalone server only listens on its local socket. MicroCloud clusters always use the network API.
3. Update. Run sudo snap refresh lxd and sudo snap refresh microcloud, then run snap list again and compare the result with the table. Many servers hold or schedule snap refreshes, so check rather than assume.
4. Limit who can reach the API until you are patched. Canonical gives no workaround, and Incus says "There is no configuration based workaround." The only stopgap is a firewall or VPN rule that lets only trusted management hosts reach the HTTPS listener.
5. Clean up the trust list. Run lxc config trust list and remove clients you no longer use. Every trusted certificate is an identity someone could pose as.
6. Look for changes you did not make. If the API was reachable from untrusted networks, check for new instances, new trusted certificates or configuration changes you cannot account for.

Why this matters for a business network

LXD and MicroCloud often run the things a company depends on: internal apps, databases, build servers and client websites. This flaw skips the login check entirely. If an attacker poses as an administrator's client, they get every container and virtual machine on the cluster, and possibly root on the host.

In this case, the most important safeguard is whether the API was reachable at all. A management port open to the internet, or to a flat office network, gives anyone the access the attack needs. A port that only accepts connections from a management VPN gives them very little. If you host your own infrastructure, this is the time to check both the patch and the network path. Our self-hosting infrastructure work covers this kind of setup.

LXD vulnerability questions people are asking

Is the LXD vulnerability being exploited?

There are no reports of attacks so far. CISA's entry in the CVE record lists exploitation as "none" as of October 30, 2026, but it also marks the flaw as automatable.

Does an attacker need a password or private key?

No. They need network access to the LXD HTTPS API and a trusted client's public certificate, which is not a secret.

Which LXD version fixes CVE-2026-112816?

LXD 6.10.1, 5.21.9, 5.0.11 or 4.0.15, depending on your snap channel. For MicroCloud it is 3.4.1 or 2.1.5.

Am I affected if I installed LXD with apt on Ubuntu?

Ubuntu lists the archive package as not affected or not shipped, but LXD is normally installed as a snap. Run snap list lxd to be sure.

Does this affect Incus?

Yes. Incus found the flaw and fixed it in 7.6.0. Monthly Incus releases are only supported until the next one comes out.

Is there a workaround if I cannot update today?

There is no configuration setting that fixes it. Block network access to the API from everything except trusted management hosts until you can update.

The bigger lesson

A security check is only as strong as the thing it actually verifies. Here, LXD verified proof of one certificate and trusted a different one. Problems like this are hard to spot from outside, so the defence you control is keeping management interfaces off networks where strangers can reach them, and patching quickly when a fix ships.

If you want a second pair of eyes on your servers and management ports, see our security hardening service or request a quote.

Get security alerts like this by email, plus our free checklist, at /security-alerts.

Sources: Canonical LXD and MicroCloud security advisory; Incus advisory GHSA-xg75-xf37-cph9; Ubuntu CVE-2026-112816; CVE-2026-112816 record; Incus 7.6 release notes.