Vulnerabilities

Canonical has fixed CVE-2026-112816, an authentication bypass in LXD and MicroCloud scored 10.0 under CVSS 4.0 by Canonical as the CVE Numbering Authority. Anyone who can reach the LXD HTTPS API and holds the public certificate of a client the server already trusts can log in as that client. No private key, password or token is needed. Depending on what the impersonated identity may do, Canonical says that can mean root on the host. Incus, the community fork of LXD where the bug was first found, has the same flaw and fixed it in 7.6.0.

You are exposed if you run the LXD or MicroCloud snap with the remote API switched on. Out of the box LXD listens only on a local Unix socket; remote access starts when someone sets core.https_address, which every cluster and every remotely managed host has done. Ubuntu's own deb packages are not involved: the tracker lists lxd as not in the release for 22.04 to 26.10 and not affected on 20.04 and older, so this is a snap update.

How it works

LXD's remote API uses mutual TLS. Each client has a key pair, and an administrator adds the client's certificate to the server's trust store, usually with a trust token. On every connection the server asks for a client certificate and checks it against that store.

A TLS client can send a chain of certificates: its own leaf certificate first, then intermediates. During the handshake the client signs with one key, the leaf's, so the handshake proves possession of that key and nothing else. LXD's listener requested client certificates without verifying the chain, and its authentication and ownership checks then compared every certificate in the chain with the trust store. If any one matched, the connection got that identity.

So an attacker generates a throwaway key pair, puts their own certificate in the leaf slot and appends a trusted client's public certificate as a fake intermediate. The handshake succeeds because they really hold the leaf key. LXD then finds the appended certificate in its trust store and treats the session as that client. Both the LXD and Incus advisories say the flaw has been there since the first release.

Public certificates are easy to come by. Any trusted client can read the others through the certificates API, and a client's certificate can be pulled from any server it has connected to. Server certificates are sent in every TLS handshake, and the advisories say appending the server's own certificate opens the database gateway, while on a cluster another member's certificate gives internal cluster access. The same flaw lets a client renew or delete any trust store entry through the self-service paths, and it also affects the connection between the host and the agent inside LXD virtual machines. For MicroCloud, Canonical warns that an attacker who intercepts the public certificate of a member joining the cluster can then authenticate as that member.

What attackers are doing

No exploitation has been reported. The CISA enrichment on the CVE record, dated October 30, rates exploitation as "none", automatable as "yes" and technical impact as "total". The CVE is not in CISA's Known Exploited Vulnerabilities catalog. A repository calling itself a proof of concept is indexed on Sploitus; the Cloud Security Alliance (CSA) has not verified it, and one review says it holds only a version check and update script. The attack needs no exploit kit anyway, just a crafted certificate chain, so plan as if it will be used soon.

Ubuntu's tracker rates the issue Medium priority despite the 10.0 score, without saying why. If you run the snap, go by the score.

The dates differ between sources. Canonical's Ubuntu Discourse advisory is dated October 28, its fixed snaps are listed as released October 29, the Incus advisory came out October 29, and the CVE record was published October 30. Some write-ups give October 29 for Canonical's advisory, and the LXD GitHub advisory carries a later date of November 4.

What to do

1. Update every host and cluster member. The fixed snaps are lxd 6.10.1 (6/stable), 5.21.9 (5.21/stable), 5.0.11 (5.0/stable) and 4.0.15 (4.0/stable), and microcloud 3.4.1 (3/stable) and 2.1.5 (2/stable). Run sudo snap refresh lxd and sudo snap refresh microcloud, then confirm with snap list lxd microcloud on each machine. Canonical rolled these out progressively from candidate to stable, so a refresh that finished early may not have landed the fix; check the version itself. The CVE record lists 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected, while the LXD GitHub advisory also names 6.10.0 as patched. Canonical's channel table says 6.10.1, so go to 6.10.1. CSA advises treating every older LXD release as affected until Canonical says otherwise. Incus users need 7.6.0 or later.

2. If you cannot patch today, cut off the listener. Both advisories say there is no configuration setting that blocks the attack, so the only interim step is network access. Run lxc config get core.https_address to see what the API binds to (8443 is the usual port). If it is [::]:8443 or :8443, bind it to a management interface instead, for example lxc config set core.https_address 10.0.0.5:8443, and allow that port in the host firewall only from admin hosts and cluster peers. Remove any port forward or load balancer that publishes it to the internet. On a cluster, keep the members reachable from each other. CSA notes that PKI mode is not a listed mitigation, and rotating client certificates does not help because the new public certificates are just as easy to obtain.

3. Look for abuse. An attacker appears as a legitimate trusted identity, so the useful signal is where the request came from and what changed:

• lxc config trust list: look for entries added, renamed or with restrictions removed without a change record, and entries that have gone missing.
• lxc monitor --type=lifecycle streams the audit trail, including certificate-created, certificate-deleted, certificate-updated and cluster-member-added, with a requestor block naming the identity. These are live events, so history exists only if you forward them to Loki or another log store.
• In central logs or firewall flows for the API port, look for connections from addresses outside your admin and cluster set during the exposure window.
• Review instances, profiles and projects for unexpected creation, new devices, image imports, security.privileged=true or raw.* keys.
• On MicroCloud, confirm every cluster member is one you added.

4. Clean up if anything is off. Remove unknown trust entries and instances, rebuild sensitive instances from known-good images, and rotate any secrets stored in instance configuration or cloud-init data on hosts that were reachable.

Check your own certificate pinning

The bug comes from a common shortcut: treating "this certificate appears in the chain" as "this client is that identity". Any service that does its own client certificate matching should tie the identity only to the leaf certificate whose key signed the handshake. If you have internal tools that accept client certificates without a CA and match them by fingerprint, check which certificate in the chain they compare.

If you run LXD or MicroCloud clusters and want a second pair of eyes on exposure or the post-patch review, our cloud and Kubernetes security and platform and cloud engineering teams do that work. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: Canonical advisory on Ubuntu Discourse, LXD GitHub advisory GHSA-99jp-jwmc-65p4, Incus GitHub advisory GHSA-xg75-xf37-cph9, Ubuntu CVE tracker, OpenCVE record, Cloud Security Alliance research note, The Hacker News, lilting.ch analysis, LXD events reference.