LXD and MicroCloud CVE-2026-112816: CVSS 10.0 in Reports, Medium on Ubuntu, and What to Patch

Updated November 3, 2026 · first published November 3, 2026

CVE-2026-112816 is an improper certificate validation flaw in the HTTPS listener of Canonical's LXD. Ubuntu's CVE page says it lets an unauthenticated attacker authenticate as any trusted client and reach the cluster and its virtual machines. Fixed LXD versions are 4.0.15, 5.0.11, 5.21.9 and 6.10.1. Reports rate it CVSS 10.0, while Ubuntu lists priority Medium.

Published 3 November 2026 · sources: Ubuntu's CVE page (published 30 October) plus secondary reports, which we mark below. We could not open the GitHub advisory.

What is the flaw?

Ubuntu's description: improper certificate validation in the HTTPS listener of LXD 4.0.14, 5.0.10, 5.21.8 and 6.9, before the fixed versions, lets an unauthenticated attacker authenticate as any trusted client. Secondary reports describe the root cause as the server checking every certificate in the chain a client sends against its trust store, not just the client's own certificate, so an attacker needs the public certificate of a client the server already trusts, plus network access to the HTTPS API. They also say that if the impersonated client is privileged, the result can be host-level root. We could not confirm those details on a primary page.

Which versions are fixed?

Ubuntu's status table covers the lxd deb package and shows it as “Not in release” for current Ubuntu releases (22.04, 24.04, 26.04 and 26.10) and “Not affected” for older ones, so the exposure is in the LXD snap and in MicroCloud, not the Ubuntu archive package. The page does not itself mention snaps; that reading comes from secondary reports, so verify how you installed LXD.

Why does the severity differ?

Ubuntu's page lists priority Medium and states no CVSS score. Secondary reports give CVSS 4.0 of 10.0 and name Canonical's and the Incus project's advisories as the source. A distribution's priority reflects its own exposure and defaults, and a CVSS base score reflects the worst case, so both can be true. For a cluster whose API is reachable over HTTPS, plan around the worst case.

Who is exposed?

• Exposed: hosts running an affected LXD, MicroCloud or Incus version with the HTTPS API listening.
• Not reachable remotely, per reports: installations that listen only on the local Unix socket and have no HTTPS address configured.
• Public tooling: proof-of-concept code and scanners for this CVE are reported to exist, which raises the urgency.

What to do

1. Find every LXD, MicroCloud and Incus host. Check how each was installed (snap or package) and its version.
2. Update to a fixed version on your channel: 6.10.1, 5.21.9, 5.0.11 or 4.0.15 for LXD.
3. Until patched, restrict network access to the HTTPS API to trusted hosts. No configuration workaround for the validation error is reported.
4. Review trusted client certificates and the audit logs for unexpected authentication, since the attack uses a certificate the server already trusts.
5. Count the downtime. Cluster-wide updates have a cost; see the cost of emergency patch downtime.

If you run AI workloads on self-managed clusters, the same inventory discipline applies; see on-prem LLM FinOps.

Related

• The cost of emergency patch downtime
• On-prem LLM FinOps
• Linux TCP flaw CVE-2026-98432: Ubuntu fix status

Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit →

Back to finopsllm.com