A Borrowed Certificate Was All It Took: Canonical Fixes a Perfect-10 Flaw in LXD and MicroCloud
A maximum-severity flaw in Canonical’s LXD and MicroCloud let an attacker pose as a trusted client by tacking that client’s public certificate onto their own. Fixed snaps are out. Here is the spec sheet and an update checklist for anyone running these tools.
LXD is Canonical’s tool for running containers and virtual machines on Linux, and MicroCloud groups several LXD machines into a small cluster. Both just received fixes for a flaw rated as severe as it gets. It let someone log in as a trusted client without ever holding that client’s private key.
We built this spec sheet from The Hacker News’ coverage of the advisory.
Spec sheet
- Identifier: CVE-2026-112816.
- Severity: CVSS 10.0, the maximum.
- Products: Canonical LXD and MicroCloud. The CVE record lists LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected, each up to the fixed release that follows it.
- Impact: the attacker acts as the impersonated client, with access to the cluster and its virtual machines. If that client is privileged, Canonical says this can mean root access to the host.
- Requirements: network access to the HTTPS API and the public certificate of a client the server already trusts.
- Exploitation: none known. A CISA assessment dated October 30 says it is not known to be exploited, it is not on the Known Exploited Vulnerabilities list, and no working exploit has been published.
- Found by: the Incus project, a community fork of LXD, which fixed the same bug in Incus 7.6.0 alongside 17 other security issues.
- Workaround: none from Canonical. Restricting network access to the API is the only interim step.
How the trick worked
These products use mutual TLS: a client proves who it is by presenting a certificate, and the server accepts it if that certificate is in its trust store. The TLS handshake only proves the client holds the private key for the first certificate in the chain it sends. Everything after that first certificate is simply whatever the client chose to include. The vulnerable code checked every certificate in the chain against the trust store, so an attacker could put their own certificate first, add a trusted client’s public certificate behind it, and be accepted as that client. Public certificates are not secrets, which is why this was so dangerous.
Who is actually exposed
- Standalone LXD: the HTTPS API is off by default and LXD listens only on a local socket, unless an administrator has set core.https_address. If that setting is on, you are in scope.
- MicroCloud: clusters have an extra weak point. Canonical says someone who captures a member’s public certificate while it joins the cluster can later log in as that member.
- Ubuntu archive packages: listed as not affected or not shipped. The fixes come through the snap packages.
Update checklist
- Find every host running LXD, MicroCloud or Incus, including lab and test machines.
- On snap installs, run
sudo snap refresh lxdandsudo snap refresh microcloud. - Check the installed version afterward. Canonical said the fixed LXD point releases were still moving from the candidate channel to stable when it published the advisory, so do not assume the refresh pulled the fix.
- Incus users: upgrade to 7.6.0 or later.
- Until every host is fixed, limit who can reach the API with firewall rules, a VPN or a management network.
- Review the trust store and remove client certificates you no longer need.
What this means for your company
Many small businesses run LXD without realizing it, through a contractor, an appliance or a test server someone set up years ago. Ask whoever manages your Linux servers whether it is in use and whether the management API can be reached from the network. More broadly, management interfaces for virtualization should never be reachable from the open internet, and every host should be included in a patch process that confirms updates actually landed.
Not sure what is running on your Linux servers, or who can reach their management interfaces? Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.
About The Author
