Enterprise IT News
Enterprise IT News Alert: LXD Trusts the Wrong Certificate
By Nattapong Sukkasem · Published · Updated .
TL;DR — CVE-2026-112816 lets anyone who can reach the LXD or MicroCloud HTTPS API authenticate as any trusted client whose public certificate they hold, with no private key and no stolen secret. The daemon compared every certificate a client presented against its trust store, but a TLS handshake only proves ownership of the first one. The Incus project found it and reported it upstream; Canonical published an advisory on 28 October and shipped fixed snaps on 29 October. Incus scores it 10.0. The enterprise IT news is not the number. It is that the whole attack is built from values that were never secret.
Most enterprise IT news about broken authentication is a story about a stolen credential. This one is a story about a credential that was never private to begin with. CVE-2026-112816 affects LXD, Canonical MicroCloud and the Incus fork they share ancestry with, and it turns a public certificate — a value a server hands out to every client that connects to it — into a working login for that certificate's cluster.
What a TLS handshake actually proves
Mutual TLS is how machines authenticate to each other without passwords, and it has one property that is easy to forget. The handshake proves that the peer holds the private key for exactly one certificate: the leaf, the first one it sends. Everything after that in the chain is unverified data the client chose to attach.
The daemon listens with Go's tls.RequestClientCert, which asks for a chain but does not validate it. Authentication then walked r.TLS.PeerCertificates — every certificate the client handed over, in the order the client picked — and tested each one against the trust store. A match anywhere in that list returned success.
So the attack needs no cryptography at all. Generate a throwaway key pair, use it as the leaf so the handshake completes, then append the target identity's public certificate behind it. The leaf proves who the attacker is. The appended certificate decides who the server believes they are.
The fix is an array index
The public Incus commit that closes this, authored on 13 October, replaces the loop with r.TLS.PeerCertificates[0] and runs the trust check against that certificate alone. The same correction is applied across API authentication, certificate enrolment, the self-service renewal and deletion paths, the agent connection between a host and its virtual machines, the authorization scriptlet and internal cluster traffic.
The obvious reading of this is the wrong one. This is not a security control enforced at the wrong layer. TLS was in exactly the right place and did exactly its job. The daemon above it asked a membership question — is any certificate in this connection one I recognise? — when the only answerable question is a proof question: did this peer demonstrate possession of the key for a certificate I trust? Those two sentences differ by one word, and in the code they differed by one subscript.
| Product | Affected | Fixed |
|---|---|---|
| LXD 6.x | 6.9.0 through 6.10.0 | 6.10.1 |
| LXD 5.21 LTS | through 5.21.8 | 5.21.9 |
| LXD 5.0 LTS | through 5.0.10 | 5.0.11 |
| LXD 4.0 LTS | through 4.0.14 | 4.0.15 |
| MicroCloud | 2.x and 3.x before the fixes | 2.1.5 and 3.4.1 |
| Incus | every release to date | 7.6.0 |
Nothing leaked, so nothing can be rotated
The material an attacker needs is public by design. A daemon presents its own certificate in every TLS handshake it completes, so one connection is enough to collect it. Client certificates are readable through the certificates API by any trusted client, and can also be harvested from any server that client has talked to. For MicroCloud, Canonical warns that intercepting a member's public certificate while it joins the cluster is sufficient to log in as that member afterwards.
That inverts the usual incident reflex. After a credential exposure the first instruction is always to rotate the exposed value, and here there is nothing to rotate, because nothing was ever confidential. The patch is the whole remediation, and there is no configuration that substitutes for it.
There is also no zero-day vulnerability anywhere in this story, in any sense the word is normally used. Nobody raced a fix against an exploit. A downstream project read its own authentication code, recognised the pattern, reported it to the vendor it shares a lineage with, and both shipped before the public knew the flaw existed.
What an impersonated identity reaches
The blast radius is what makes this enterprise IT news worth an out-of-band change window. Canonical describes the outcome as full access to the cluster and the virtual machines it manages, and notes that where the impersonated client is a privileged one, that extends to root on the host. The intermediate steps are not all equivalent. Presenting the server's own certificate reaches the database gateway. Presenting another cluster member's certificate reaches internal cluster traffic. Client and metrics certificates yield their respective identities. Token-based and OpenID Connect clients are in scope as well, and the authorization scriptlet — the hook operators use to express their own access rules — was handed the unverified chain too, so a policy written against it was reasoning about attacker-supplied input.
Detection is the uncomfortable part. A DDoS attack is hostile traffic that is unmistakably hostile; the difficulty is absorbing it, not spotting it. This is the opposite problem. Every request an impersonator makes is well formed, correctly authenticated and logged under the name of a real administrator, so the application log is not evidence of anything. The only layer where the attack is visible is the handshake itself, where a client that presents more than one certificate has no legitimate reason to do so.
This is also where private-cloud cloud security stops being a diagram. A container and virtual machine manager is server infrastructure that runs other people's server infrastructure, and the only thing separating one workload from the next is a daemon's ability to tell its administrators apart from strangers. When that distinction fails, there is no second boundary underneath it.
Where resolution comes into it
LXD does not merely place instances on a network. Its managed bridge runs the DHCP and DNS service those instances use, which makes the daemon the resolver for everything it hosts. An identity with authority over a managed network therefore decides what every container and virtual machine on it resolves, without logging into a single guest. Instances pick the change up when their leases and cached answers expire.
The wider lesson transfers directly to resolution infrastructure, because mutual TLS is the same primitive enterprises reach for when they want a resolver to recognise its clients. Client-authenticated DNS over TLS, and DNS over HTTPS endpoints that require a client certificate instead of an allow-list of addresses, are mutual TLS deployments with the same failure mode available to them if the validation is written by hand. The protocols DNS already uses for machine-to-machine trust avoid the trap by construction: TSIG authenticates each individual message with a keyed signature, and a DNSSEC validator verifies every link in a chain up to one pinned anchor rather than accepting a chain because it recognises something inside it.
What to check this week
- Refresh the snaps, then verify the version.
snap refresh lxdandsnap refresh microcloud. - Establish whether your listener is reachable at all. A standalone LXD installation does not expose the HTTPS API unless
core.https_addresshas been set. MicroCloud exposes it by design, because a cluster has to talk to itself. - Read the trust store as a list of identities an attacker could have worn. Every entry was usable by anyone holding its public half, and the same flaw allowed entries to be renewed or removed, so confirm the list still matches what you expect.
- Do not spend the week rotating certificates. Nothing was disclosed, so re-issuance buys no IT security benefit on an unpatched daemon and delays the only fix that works.
- Move detection down to the handshake. Record the leaf fingerprint and the chain length presented by each client. More than one certificate on an administrative connection is the anomaly; the API log will show a familiar name either way.
- Baseline what your instances resolve. A network diagnostic tool run against the resolvers your workloads actually use records what normal looks like, which is what makes a silent redirection visible later.
What it means
The hedges are worth carrying at full strength. Neither Canonical's advisory nor the Incus notice reports exploitation in the wild, and the assessment recorded on 30 October lists the identifier as not known to be exploited, absent from the Known Exploited Vulnerabilities catalogue, and without a published working exploit. The severity is also not agreed: Incus rates the flaw 10.0, while Canonical's own Ubuntu security tracker assigns its LXD record a priority of Medium. The root-access outcome is drawn from the vendor advisory, not from a demonstrated intrusion.
What is not hedged is the mechanism, because the corrected code is public and the correction is three characters long. Hand-written mutual TLS checks are everywhere in modern infrastructure — in orchestrators, in service meshes, in resolvers that authenticate their clients — and almost all of them were written by someone reading a chain out of a TLS library and treating it as evidence. It looks like evidence. Only the first entry is. The practical takeaway from this cycle of enterprise IT news is a single question to ask of any system in your estate that authenticates a machine with a certificate: does it check the leaf, or does it check the list?
Sources
- The Hacker News — CVSS 10.0 LXD, MicroCloud Flaw Lets Attackers Impersonate Trusted Clients Without a Private Key
- Canonical — Security advisory: Critical vulnerability found in Canonical LXD and MicroCloud
- Cyber Security News — Critical Certificate Validation Flaw in LXD and Incus Could Give Hackers Control of Linux Hosts
- Ostorlab — LXD and Incus mTLS Authentication Bypass (CVE-2026-112816)
Related articles
Browse every DNS news article by month →
DNS angle
Review resolver logs for the systems discussed above and compare unexpected names with your approved services. A successful lookup does not establish that a destination is safe. Use the DNS lookup tool to inspect current answers, then compare them with your own resolver and incident records.