LXD and MicroCloud Have a CVSS 10.0 Certificate Bug. It Is Not Known to Be Exploited, and the Fix Is a Snap Refresh.
If you run LXD or MicroCloud from snaps with the HTTPS API exposed, update today. The flaw scores 10.0 and lets a client that can reach the HTTPS listener authenticate as any certificate the server trusts, without the private key. The Hacker News reports it as CVE-2026-112816; the Incus advisory, published October 29, lists no CVE. CISA's October 30 assessment says it is not known to be exploited, it is not in the Known Exploited Vulnerabilities catalog, and no working exploit has been published.
There are no indicators of compromise to hunt for. This post exists because defenders still have things to do.
What the bug is
A TLS client proves it owns the private key for only one certificate in the chain it sends: the leaf. The rest of the chain is whatever the client chooses to attach. According to the report, the server checked every certificate the client sent against its trust store. An attacker could therefore put their own certificate first and append a trusted client's public certificate behind it. Public certificates are not secret, so the attacker needs no stolen key.
The Incus project, a community fork of LXD, published the flaw as advisory GHSA-xg75-xf37-cph9 on October 29 and fixed it in Incus 7.6.0. It says the flaw has existed since the initial release. The Hacker News reports that Canonical confirmed it affects LXD; Incus's advisory does not mention LXD or MicroCloud. Incus rates it CVSS 3.1 10.0 and lists weaknesses CWE-287 and CWE-295.
What it allows
Per the Incus advisory, any client that can reach the listener can authenticate as any trusted client, metrics or server certificate whose public part it holds, including a cluster member, which bypasses authorization. On a cluster that can mean access to the database gateway and internal cluster traffic. It also lets a trusted client read other clients' certificates through the certificates API, lets self-service paths renew or delete trust store entries, and affects authentication of the host-to-VM agent connection. Clients that do not use mutual TLS, such as token or OIDC clients, could influence decisions made by the authorization scriptlet.
Who is exposed
Three conditions have to hold, as reported:
- The attacker has network access to the HTTPS API. Standalone LXD does not expose it by default; it needs the core.https_address setting.
- The attacker has a trusted certificate to borrow. Per the Incus advisory, server certificates are returned in every TLS handshake, so no prior access is needed to get one.
- For MicroCloud, capturing a member's public certificate as it joins the cluster is enough to log in as that member.
Ubuntu's archive packages of LXD are listed as not affected or not shipped. The fixed releases are the snaps.
What to do
- Update. Run sudo snap refresh lxd and sudo snap refresh microcloud. Fixed versions are LXD 6.10.1 (6/stable), 5.21.9, 5.0.11 and 4.0.15, MicroCloud 3.4.1 (3/stable) and 2.1.5 (2/stable), and Incus 7.6.0. Canonical says some fixed point releases were still rolling from candidate to stable, so check the installed version afterward instead of assuming the refresh took.
- Limit who can reach the API. Canonical gives no workaround for LXD, and the Incus project says there is no configuration fix. Restricting network access to the listener reduces risk until you have updated.
- Check whether the API is exposed at all. Look at the core.https_address setting on each host. If nothing needs the remote API, you may not need it listening.
These are ours, not Canonical's:
- Review your trusted client list. Run lxc config trust list and remove entries you do not recognize or no longer use. Every trusted certificate is a certificate an attacker can borrow.
- Review API access logs for connections from unexpected addresses since the bug became public, especially for clients that should only connect from a known place.
- On a cluster, a reachable listener is the whole exposure. The advisory says a member's certificate can be borrowed, so restrict listener access at the network level, not only inside LXD.
- Treat MicroCloud joins as sensitive moments. The reported join-time exposure means a join over an untrusted network is the case to avoid.
What we hold, and what we don't
Nothing. The report lists no indicators, so there is nothing to put in a feed. Our search of the KEV catalog and our corpus for this CVE returned no results on November 1. The CVE identifier comes from The Hacker News' summary; the Incus advisory lists none, so confirm the ID against Canonical's record before you cite it in a ticket.
Limits
This is based on The Hacker News' November 1 report. We read the Incus advisory but not Canonical's, did not test the bug, or confirmed the fixed versions against the snap store. The affected-version list follows the CVE record as reported and several fixed releases were still rolling out. If CISA adds this to KEV, treat everything in the exploitation paragraph as out of date.
Five percent of this is wrong somewhere. It always is. The numbers will move again before you finish reading.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.