What happened

Heads-up: a nasty bug turned up in Canonical’s LXD and MicroCloud that lets a remote attacker log in as a trusted client even if they don’t have that client’s private key. In plain talk: the attacker can pretend to be someone else by handing the server that person’s public certificate — which isn’t secret — and the server happily accepts them. This issue has been tracked under CVE-2026-112816 and carries a scary CVSS 10.0 severity.

The root cause lives in how mutual TLS was validated. LXD and MicroCloud accept client certificates from a trust store. But the server only really proves the client owns the private key for the first certificate in the TLS chain (the leaf). The rest of the chain is supplied by the client, and the server was comparing every certificate in the chain against the trust store instead of ensuring the leaf is the trusted one. That allowed an attacker to use their own leaf certificate, append a trusted client’s public cert behind it, and be treated as that trusted client.

Two things are needed to exploit this: network reachability to the HTTPS API and the targeted client’s public certificate. Note: a plain LXD install listens on a local socket by default and does not expose the network API unless an admin turns on the network listener with the core.https_address setting. MicroCloud clusters are more exposed: an attacker who snags a member’s public certificate during cluster join could reuse it to authenticate as that member.

The bug originated from the Incus project (a community fork of LXD) and was fixed there as well. Affected LXD versions include older point releases (for example 4.0.14, 5.0.10, 5.21.8 and 6.9 prior to their fixes). Canonical has released patched snap updates; Ubuntu archive packages were reported as not shipped or not affected in many cases.

There are no public reports of active exploitation at the time of the advisory, and a U.S. agency assessment said it’s not known to have been used in the wild.

What to do now

If you run LXD or MicroCloud, this is one of those occasions where boring, immediate updates are heroic. The vendor has pushed fixed snap releases; update them as soon as you can. If you used a snap install, run the refresh commands and then verify the version actually updated (the fixes were rolling from candidate to stable, so don’t assume).

  • Update snaps: sudo snap refresh lxd and sudo snap refresh microcloud.
  • Confirm the version after refresh—don’t assume the channel auto-switched for you.
  • If you use Incus, upgrade to 7.6.0 or later (it contains the same fix plus others).

There isn’t a neat configuration toggle that fixes the validation logic; the temporary mitigation is to reduce who can talk to the API. In short: limit network exposure to the HTTPS listener (keep the API on a local socket unless you truly need network access, and firewall or ACL the listener). For clusters, be extra careful during node joins so you don’t leak member certificates.

Quick checklist:

  • Patch LXD and MicroCloud snaps now.
  • Restrict network access to the API until you’re patched.
  • Verify your versions and cluster join hygiene.

If you like drama-free infrastructure, updating and tightening API exposure is your ticket. And yes, this is one of those rare bugs where the public cert — normally harmless — becomes the unwanted VIP that opens doors. Treat exposed APIs like tiny, picky bouncers: if you don’t know who’s knocking, don’t let them in.