Canonical LXD and MicroCloud CVE-2026-112816: Certificate Chain Flaw Lets Attackers Pose as Trusted Clients (CVSS 10.0)

TL;DR: Canonical has fixed CVE-2026-112816, a flaw in how the LXD HTTPS API checks client certificates. An attacker who can reach that API and holds the public certificate of a client the server already trusts can log in as that client, with no private key needed. In MicroCloud, an attacker who captures a joining cluster member's public certificate can then log in as that member. Canonical, as the CVE numbering authority, scores it CVSS 4.0 10.0 (Critical). Depending on the identity copied, Canonical says the attacker "may gain root access to the host machine." Fixed snaps: LXD 6.10.1, 5.21.9, 5.0.11 and 4.0.15, and MicroCloud 3.4.1 and 2.1.5, all dated 29 October 2026 in Canonical's fixed-version table (Canonical advisory).

What lowers the urgency for most readers:

• No known exploitation. The CVE record carries a CISA assessment dated 30 October of "exploitation: none". CVE-2026-112816 is not in CISA's Known Exploited Vulnerabilities (KEV) catalog (checked 2 November 2026, 08:19 Cyprus time, UTC+2). We have seen no report of attacks.
• The network API is off by default.LXD's documentation says a standalone server "can be used only by local users through a Unix socket and is not accessible over the network" until an administrator sets core.https_address. Hosts that never did this are not reachable through this flaw.
• The attacker needs a trusted certificate's public part. That is not secret, but the attacker still has to get it and still has to reach the API.
• Ubuntu's own archive packages are not affected. Ubuntu's CVE page lists the archive lxd package as not affected or not shipped in every supported release, and rates its priority as medium. The fix is in the snaps.

The catch: a lab proof of concept that reproduces the bypass was posted publicly on GitHub on 1 November. The technique is simple and CISA marks it "automatable". A public PoC is not exploitation, but it shortens the time defenders have to patch.

Our read: the score is the maximum, but the exposure is narrow. The hosts that matter are LXD servers with the HTTPS API switched on, and clustered set-ups, including MicroCloud, whose members talk to each other over the network. For those, patch now. Rescana rates this High for most estates.

Technical Information

LXD and MicroCloud let remote clients use their APIs over mutual TLS. The client shows a certificate, and the server accepts it if the certificate is in its trust store.

Canonical's summary: the check "compared all peer certificates sent by the client to known trust store entries. However, only the leaf certificate proves ownership of the signing key." An attacker could put a trusted client's public certificate into the chain as an intermediate behind their own leaf, and the server would treat them as that client. The CVE record files this under CWE-295, improper certificate validation.

What Canonical says the attacker gets:

• LXD: anyone who can reach the HTTPS API can authenticate as any trusted TLS client whose public certificate they hold. The CVE record describes the result as "full access to the cluster and managed virtual machines".
• MicroCloud: an attacker who can intercept the public TLS certificate of a member joining the cluster can then authenticate as that member.
• Host impact: "Depending on the privilege of the victim user, the attacker may gain root access to the host machine."

Incus, the community fork of LXD. Canonical says the issue was referred to it by the Incus project, and the CVE record credits Incus maintainer Stéphane Graber as reporter. Incus published its own advisory for its code, GHSA-xg75-xf37-cph9 (CVSS 3.1 10.0), fixed in Incus 7.6.0. For Incus, it says the flaw has existed "since the initial release". It also says that server certificates are returned in every TLS handshake, so an attacker needs no prior access to obtain one. It adds that the same flaw affects self-service renewal and deletion of trust store entries and the host-to-VM agent connection. These statements are about Incus. Canonical's LXD advisory does not repeat them, so we do not assume they apply to LXD in the same way.

CVE and KEV status

• CVE-2026-112816, published by Canonical on 30 October 2026 (18:42 Cyprus time). Canonical's advisory went up on 28 October and was last edited on 30 October (00:50 Cyprus time).
• CVSS 4.0 10.0 Critical, AV:N/AC:L/AT:N/PR:N/UI:N, high impact on the vulnerable and downstream systems (Canonical, CNA). NVD has not added its own score; its status is "Deferred".
• CISA's assessment in the CVE record: exploitation none, automatable yes, technical impact total.
• Not in CISA KEV (catalog version 2026.10.30, checked 2 November 2026).
• Public code: a repository describing itself as an "independent lab reproduction and post-patch verification tool" was created on GitHub on 1 November 2026. We have not run it and do not link it.
• Canonical's LXD advisory link, GHSA-99jp-jwmc-65p4, returned "not found" when we checked on 2 November 2026. We rely on Canonical's Discourse advisory and the CVE record for the LXD details.

Timeline (Cyprus time, UTC+2)

• 28 October 2026, 19:50: Canonical publishes its security advisory for LXD and MicroCloud.
• 29 October: fixed LXD and MicroCloud snaps released to stable, according to Canonical's table. (The release announcements were posted 21–28 October; Canonical added the security note to them on 30 October.)
• 30 October, 00:17: Incus publishes GHSA-xg75-xf37-cph9. Incus 7.6.0 follows at 03:50.
• 30 October, 18:42: CVE-2026-112816 published. CISA's assessment in the CVE record is dated the same day.
• 1 November: The Hacker News reports the flaw, saying at the time that no working exploit had been published.
• 1 November, 22:47: a public lab proof of concept appears on GitHub.
• 2 November, 08:19: still not in CISA KEV; no exploitation reported.

Affected Product Versions

Notes:

• The "affected" column for LXD is taken from the CVE record, which names 4.0.14, 5.0.10, 5.21.8 and 6.9 as the starting points. The record does not list older versions as affected or as safe. Canonical tells all LXD and MicroCloud users to update, so treat any version below the fixed release in your channel as needing the update.
• The CVE record covers LXD only. Canonical's advisory names the fixed MicroCloud versions but does not list the affected ones.
• Ubuntu archive lxd packages: not affected (xenial, bionic, focal) or not shipped (jammy and later), per Ubuntu's CVE tracker.

Workaround and Mitigation

1. Update. On snap installs, Canonical's fix is:

   sudo snap refresh lxd
   sudo snap refresh microcloud
   

   Canonical said the LXD point releases were being rolled out in stages from candidate to stable. After refreshing, check the installed version (snap list lxd microcloud) rather than assuming the fix arrived. Incus users should move to 7.6.0 or later.
2. Check whether the API is exposed. Run lxc config get core.https_address on each host. An empty value means a standalone host is not listening on the network. On clusters, also check cluster.https_address.
3. Limit who can reach the API until you patch. Canonical gives no workaround for LXD. Incus says, for its code, "there is no configuration based workaround" and advises restricting network access to the HTTPS listener to trusted hosts. Firewalling port 8443 (or whatever port you set) to management networks only cuts the exposure.
4. Never put the API on the internet. If an LXD or MicroCloud API is reachable from the internet, treat that host as a priority and review it after patching.
5. MicroCloud (Rescana advice, not Canonical's text): finish the update before adding new members. Canonical's MicroCloud scenario involves intercepting the certificate of a member that is joining the cluster.

Indicators of Compromise

Canonical and Incus have not published any indicators of compromise, and we know of no attack activity to draw them from. The attack uses a valid trusted certificate, so it may look like normal client traffic. After patching, owners of exposed hosts can still look for:

• Trust store changes they did not make (lxc config trust list): new, renewed or removed certificates.
• Instances, images, storage volumes or projects created or changed without a matching change record.
• API activity in LXD logs or audit tooling from source addresses that are not your known management hosts.

We will add IoCs here if Canonical, Incus or a credible researcher publishes them.

What we will update

We will update this post if:

• CISA's KEV catalog starts listing CVE-2026-112816, or exploitation is reported.
• Canonical publishes GHSA-99jp-jwmc-65p4 or changes the affected-version ranges.
• NVD adds its own score, or a weaponised exploit or scanning activity is reported.

What to do with this vendor today

LXD and MicroCloud usually sit inside your suppliers, not on your own network: hosting and managed-service providers, private-cloud and VPS platforms, CI and test-lab operators, and software vendors that run customer workloads in LXD containers or VMs. If one of them exposed the LXD API without the patch, an attacker posing as a trusted client could reach the VMs where your data or builds run.

Questions to send today to suppliers that host workloads for you:

• Do you run Canonical LXD, MicroCloud or Incus in the environment that hosts our data or services?
• Is the LXD HTTPS API (core.https_address or cluster address) enabled, and can it be reached from outside your management network?
• Are you on LXD 6.10.1, 5.21.9, 5.0.11 or 4.0.15, MicroCloud 3.4.1 or 2.1.5, or Incus 7.6.0 or later, and when did the update reach your hosts?
• Have you reviewed the LXD trust store and recent API activity for changes you did not make?

Record the answers and the date. Ask again if CISA's KEV catalog starts listing CVE-2026-112816 or attacks are reported.

Forward this to your TPRM owner: CVE-2026-112816 (CVSS 10.0) lets an attacker who can reach an LXD or MicroCloud HTTPS API log in as a trusted client. No exploitation is known and it is not in CISA KEV, though a lab proof of concept is public. The API is off by default, so the risk sits with exposed hosts and clusters. Ask hosting and infrastructure suppliers whether they run LXD, MicroCloud or Incus, and whether they are on the fixed versions.

Not sure which of your hosting and infrastructure suppliers run LXD or MicroCloud, or how to track their answers on CVE-2026-112816? Our team can help you prioritize them.

Sources

• Canonical: "Security advisory: Critical vulnerability found in Canonical LXD and MicroCloud" (Ubuntu Discourse, 28 October 2026, edited 30 October): https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557 · release posts: LXD 6.10.1 (https://discourse.ubuntu.com/t/lxd-6-10-1-lts-has-been-released/90024), 5.21.9 (https://discourse.ubuntu.com/t/lxd-5-21-9-lts-has-been-released/90565), 5.0.11 (https://discourse.ubuntu.com/t/lxd-5-0-11-lts-has-been-released/90570), 4.0.15 (https://discourse.ubuntu.com/t/lxd-4-0-15-lts-has-been-released/90571), MicroCloud 3.4.1 and 2.1.5 (https://discourse.ubuntu.com/t/microcloud-3-4-1-lts-and-2-1-5-lts-have-been-released/90501) · LXD documentation, "How to expose LXD to the network": https://documentation.ubuntu.com/lxd/latest/howto/server_expose/
• Ubuntu Security: CVE-2026-112816 tracker: https://ubuntu.com/security/CVE-2026-112816
• CVE record and NVD: CVE-2026-112816 (CNA record from Canonical, with CISA's assessment): https://www.cve.org/CVERecord?id=CVE-2026-112816 · NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-112816
• Incus: GHSA-xg75-xf37-cph9, "Authentication and authorization bypass through unverified client certificate chains" (30 October 2026): https://github.com/lxc/incus/security/advisories/GHSA-xg75-xf37-cph9
• CISA: KEV catalog (checked 2 November 2026): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Press: The Hacker News, "CVSS 10.0 LXD, MicroCloud Flaw Lets Attackers Impersonate Trusted Clients Without a Private Key" (1 November 2026; press coverage only): https://thehackernews.com/2026/11/critical-lxd-and-microcloud-flaw-cvss.html