LXD, MicroCloud CVSS 10 Flaw Enables Trusted-Client Impersonation

Canonical has shipped fixes for a maximum-severity authentication flaw in LXD and MicroCloud that lets an attacker impersonate a trusted client without ever touching that client's private key. Tracked as CVE-2026-112816 and scored CVSS 10.0, the bug lives in how the server's mutual TLS handshake evaluates certificate chains: present a trusted client's public certificate — which is, by design, not a secret — behind your own, and the server waves you in as that client. According to The Hacker News, a successful impersonation of a privileged account could hand an attacker "root access to the host machine," along with the cluster and every virtual machine on it.

The preconditions matter, and I'll get to whether 10.0 is the right number. You need two things: network access to the LXD or MicroCloud HTTPS API, and the public certificate of a client the server already trusts. No phishing, no key theft, no brute force. It's the certificate-chain equivalent of tailgating — you walk in on your own legs, but the guard checks the badge of the person behind you.

How the chain-of-trust check failed

LXD and MicroCloud authenticate remote clients with mutual TLS. The client presents a certificate; the server trusts it if that certificate sits in its trust store, the list of identities it will accept. So far, so standard. The flaw was in which certificates the server bothered to check against that store.

In TLS, the handshake cryptographically proves the client holds the private key for exactly one certificate: the leaf, the first in the chain. Everything appended after the leaf is just data the client chose to send. The vulnerable LXD code compared every certificate in the presented chain against the trust store — so an attacker could generate their own keypair, attach a trusted client's public certificate behind their own leaf, and match the trust store on the second entry. The server never verified that the attacker possessed the private key for that trusted cert, because TLS simply doesn't work that way.

# What the attacker presents
chain = [attacker_leaf, trusted_client_public_cert]
# What TLS proves: private key for attacker_leaf ONLY
# What the vulnerable server did:
for cert in chain:
if cert in trust_store:
authenticate_as(cert)   # matches trusted_client_public_cert -> session as trusted client

Once authenticated, the attacker inherits the impersonated client's full privileges: cluster operations, VM access, and — if the account is an administrator — host-level root. Public certificates are meant to be shareable; they travel in handshakes, get logged, and sit in config backups. Treating one as proof of identity without proof of key possession breaks the entire mTLS model.

The timeline: from a community fork to a Canonical fix

Credit where it's due: the bug didn't surface at Canonical. The Incus project — the community fork of LXD — found and reported it, then shipped its own fix in Incus 7.6.0 alongside 17 other security issues. Canonical confirmed the same flaw affected LXD, which inherited the code path. Fork relationships cut both ways: shared code means shared vulnerabilities, and whoever audits first does everyone a favour.

On October 30, the CVE record for CVE-2026-112816 carried a CISA assessment: the flaw is not known to have been exploited, and it has not been added to CISA's Known Exploited Vulnerabilities catalog. No working exploit has been published. That's the state of play as of today — a fully documented attack primitive, a public fix, and no confirmed in-the-wild abuse. The window between 'publicly described' and 'weaponised' is where defenders either patch or explain later why they didn't.

Canonical's fixed snap releases are LXD 6.10.1 (6/stable), 5.21.9 (5.21/stable), 5.0.11 (5.0/stable) and 4.0.15 (4.0/stable), plus MicroCloud 3.4.1 (3/stable) and 2.1.5 (2/stable). The CVE record lists LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 as the affected versions, each vulnerable until the point release that follows it. One wrinkle: Canonical noted the fixed LXD point releases were still rolling out from the candidate channel to stable when its advisory went live, so a refresh doesn't guarantee the fix — verify the version you actually landed on. Ubuntu's archive (deb) packages of LXD are listed as not affected or not shipped; the snaps are the vehicle here.

Does CVSS 10.0 fit? Yes and no

The case for 10.0: this is a complete authentication bypass with no user interaction, low complexity, and impact that tops out at host root. The primitive is dirt simple — anyone who has ever pasted a certificate chain into a PEM file has all the skills required.

The case against: both preconditions genuinely shrink the blast radius. A standalone LXD server doesn't expose the API by default; it listens on a local Unix socket unless an administrator explicitly sets core.https_address. And you need a trusted client's public certificate, which is not secret but is also not broadcast on the open internet. The sharpest exposure is MicroCloud: Canonical said an attacker positioned to capture a member's public certificate as it joins the cluster can then log in as that member. Cluster bootstrap traffic is exactly the kind of thing that crosses management networks, so 'public but hard to get' becomes 'captured once, replayed forever.'

My read: if your LXD API is reachable from anything beyond a dedicated management segment, treat this as a drop-everything patch. If it's socket-only, you're patching out of hygiene, not panic. The 10.0 describes the bug; your network topology describes your risk.

No workaround: patch or wall off the listener

Canonical's advisory offers no temporary configuration workaround for LXD, and the Incus project was blunt about its own codebase: there is no configuration fix, and the only interim step is restricting network access to the listener. That tells you the flaw is in the verification logic itself, not in any knob you can turn. On snap installs, the remediation is two commands and a version check:

sudo snap refresh lxd
sudo snap refresh microcloud
snap list lxd microcloud   # confirm you actually got the fixed point release

While you're in there, answer the exposure question honestly:

• Run lxc config get core.https_address on every host. An empty value means local socket only — remote exploitation is off the table for that machine.
• If the API must stay network-reachable, restrict it to a management VLAN or firewall allowlist until the patched snap lands on the stable channel for your track.
• For MicroCloud, treat cluster join traffic as sensitive: an on-path observer who captures a joining member's public certificate met half the attack's requirements.
• Incus shops should move to 7.6.0, which closes this flaw and 17 other security issues in one release.
• After patching, review trust store entries and cluster membership for identities you don't recognise — cheap insurance if anyone got in before the fix.

If the impersonated account is privileged, the attacker could gain "root access to the host machine," Canonical said.

The broader lesson is one that keeps showing up in authentication code, from the GitLab CVSS 10 regex RCE to this: the check that looks thorough — validating every certificate in the chain — can be worse than a narrow one, because it lends false confidence to a broken assumption. TLS proves key possession for the leaf and nothing else. Any trust decision based on certificates further down the chain needs its own proof, and here there was none. Incus caught it, Canonical fixed it, and now the only question is whether your refresh lands before someone else's exploit does.