CVE-2026-112816: LXD trusts the wrong certificate

A public certificate—not its private key—was enough to impersonate a trusted LXD or MicroCloud client over a reachable HTTPS API. CVE-2026-112816 bypasses client authentication entirely. Reported snap fixes exist, yet NVD's record still shows no published fixed version as of November 1. Restrict API access while updating; snap users can run sudo snap refresh lxd or sudo snap refresh microcloud, then verify the installed release.

Debian lists bookworm and trixie packages as vulnerable. The consequence reaches beyond a rejected login: Canonical warned that impersonating a privileged client could give an attacker root access to the host (unverified related link). For an operator responsible for the cluster and its virtual machines, the impersonated client's privileges determine how damaging that access could become.

Refresh LXD and MicroCloud, then check installed versions

Run the applicable refresh command, then inspect the version actually installed. Canonical said the fixed LXD point releases were moving from candidate to stable when its advisory was written. A refresh should therefore be followed by verification, not treated as proof that a reported fix has arrived.

Refresh commands

sudo snap refresh lxd
sudo snap refresh microcloud

1. Identify the installation you are assessing. Distinguish LXD installed through a snap from an Ubuntu or Debian archive package. The package findings and snap release targets below describe different installation paths.
2. Check whether the HTTPS API is reachable over the network. For standalone LXD, inspect whether core.https_address enables the network API; the default installation listens only on a local socket.
3. Limit who can reach the API while you arrange and verify the update. Canonical gives no temporary LXD workaround, and Incus says there is no configuration fix for the underlying problem.
4. After refreshing, inspect the installed version and channel, then compare them with the reported targets below. If the installed release does not match a reported fixed target, do not assume the refresh resolved CVE-2026-112816.
5. Prioritise a reachable HTTPS API serving privileged trusted clients, then verify the reported update rather than wait for public attack confirmation.

I'd start with network reachability rather than the severity label alone. The attack needs access to the HTTPS API and the public certificate of an already trusted client. Establishing those conditions gives the update decision a concrete operational basis.

CVE-2026-112816 trusts more than the TLS proof

The validation mistake was treating every certificate supplied by a client as though the connection had proved ownership of its private key. LXD and MicroCloud use mutual TLS for remote clients, with accepted client certificates held in a server-side trust store. That store identifies which clients the server trusts.

The important distinction is between a certificate being present and its private key being proven. The TLS connection proves possession of the private key for the first certificate in the chain, known as the leaf. It does not provide that same proof for every certificate attached behind it.

• The attacker presents their own certificate first, with its corresponding private key.
• The attacker attaches an existing trusted client's public certificate later in the chain. The vulnerable server checks it against the trust store and accepts the attacker as that client.

The trusted client's private key does not have to be stolen. The attacker still needs its public certificate, but that certificate is not a secret. The failure is in how the server uses it to make an authentication decision, not in the attacker recovering the private key.

The Incus project reported CVE-2026-112816, and Canonical confirmed that LXD was also affected. For MicroCloud, Canonical identified a specific opportunity: an attacker who captures a member's public certificate while it joins the cluster can subsequently authenticate as that member. That makes the join process relevant to exposure assessment, without establishing that any particular join has been intercepted.

Which LXD and MicroCloud channels have reported fixes?

Canonical lists the following fixed snap targets. Treat them as reported vendor targets: NVD has not published a fixed version as of November 1, 2026, so the records do not provide matching confirmation. Canonical's rollout statement described the situation at the time of its advisory; it does not establish what every stable-channel installation will receive on November 1.

Compare the installed version with its channel's reported fixed target. Equally, NVD's missing fixed-version entry should not be rewritten as a claim that Canonical has released nothing.

The report names fixes across several LXD and MicroCloud channels; it does not say that resolving CVE-2026-112816 requires moving every installation onto a different release line.

For a change record, keep the distinction explicit: record the product, channel, installed version and reported target separately. That is my recommendation for avoiding an ambiguous entry that says only that updates were run.

Match Debian and Ubuntu findings to the installation

An Ubuntu package finding does not answer the same question as a snap release target. Ubuntu's tracker marks the listed archive packages as not affected by CVE-2026-112816, while Debian's tracker lists vulnerable LXD packages. Those findings need to stay attached to their distribution and installation context.

The distribution trackers list these package statuses:

The snap commands above apply to snap installations. They are not evidence that a Debian archive package has been repaired, and the available Debian findings do not publish a fixed package version. There is no supported Debian version target here to substitute into an upgrade instruction.

Match tracker status to the actual installation type. The useful question is which installation the tracker entry actually describes, not merely which operating system appears on the host.

Patch verification and attack evidence remain incomplete

Ubuntu rates CVE-2026-112816 10.0, Critical, under CVSS 4.0. That score describes severity; it does not establish that attackers have used the flaw. Keep the score separate from both the patch-verification question and evidence of exploitation.

As of November 1, CISA does not list the vulnerability in its Known Exploited Vulnerabilities catalog. The CVE record also carries an October 30 CISA assessment saying it was not known to have been exploited. Those are statements about the available record, not a guarantee that no attack has occurred.

Public exploit evidence needs similar care. No working exploit has been published. PoC-in-GitHub names a repository associated with the CVE, but marks that entry unverified. A repository naming the vulnerability and a validated working exploit are different claims; the available information does not justify merging them.

The network restriction advice has a narrower purpose than a fix. It reduces access to a prerequisite for the attack, but it does not repair the certificate-validation logic. A standalone LXD server that retains its default local-socket-only setup lacks the network API exposure described here; that is an exposure distinction, not proof that its installed software contains the correction.

Prioritise reachable APIs and privileged client identities

For MicroCloud, include the member-joining scenario in that assessment. The question is whether an attacker could obtain the joining member's public certificate and subsequently reach the API—not whether the member's private key was stolen. Restricting the investigation to private-key theft would miss the mechanism described in this disclosure.

Where standalone LXD has no enabled network API, the specific remote path described here is absent. My priority would be lower there than on an exposed cluster, while still keeping installation and update records accurate. There is no reason to manufacture an emergency network exposure that the configuration does not have.

The practical decision for CVE-2026-112816 is therefore specific: identify the installation, establish API reachability, refresh applicable snaps and verify the installed release against Canonical's reported channel target. Keep network restrictions in place where needed until that verification is complete, and do not mistake a refresh attempt—or a missing NVD fixed-version entry—for a complete answer.