LXD and MicroCloud trusted any certificate in a client's chain, so a public certificate could log in as it

Six fixed builds, four affected lines on the record, and no attack on the record

Canonical's advisory for CVE-2026-112816 lists six fixed builds: four LXD snap tracks (6.10.1, 5.21.9, 5.0.11 and 4.0.15) and two MicroCloud tracks (3.4.1 and 2.1.5). The CVE record that Canonical itself filed as the numbering authority lists four affected LXD lines and no MicroCloud product at all. Its CVSS 4.0 vector sets all 11 base metrics at their most severe value (derived, by reading the vector), which is how it reaches 10.

The flaw is simple to state. In Canonical's words, the API's mutual TLS check "compared all peer certificates sent by the client to known trust store entries", but "only the leaf certificate proves ownership of the signing key". A trusted client's public certificate is not a secret. Placed in the chain behind an attacker's own certificate, it matched the trust store, and the server treated the attacker as that client.

What the score does not establish: that anyone has used the flaw, or that any given server can be reached. The CVE record carries a CISA assessment dated 30 October 2026 with "Exploitation: none". The CVE was not in CISA's Known Exploited Vulnerabilities catalogue (version 2026.10.30) when checked at 10:51 GMT on 1 November. And Canonical's own documentation says a standalone LXD server, by default, is "not accessible over the network" at all until an administrator sets core.https_address.

This briefing reads the primaries themselves: Canonical's advisory and its edit history, the CVE record, Ubuntu's CVE page, the Incus project's advisory, fix commit and 7.6 release post, the LXD documentation and the snap store pages. All were read between 10:47 and 11:03 GMT on Sunday 1 November 2026. The Hacker News report of the same day was used only as a pointer, and each of its claims below is checked against a primary.

The mechanism: the handshake proved the leaf, the server trusted the whole chain

LXD and MicroCloud let remote clients use their HTTPS API with TLS client certificates. A client is trusted when its certificate is in the server's trust store. During the TLS handshake the client presents a chain: its own certificate first (the leaf), then any further certificates it chooses to send. The handshake proves only that the client holds the private key for the leaf. Everything after the leaf is whatever the client attached.

Canonical's summary says an attacker could "authenticate to the LXD or MicroCloud API as another identity by placing their trusted public TLS certificate as an intermediary certificate in the chain". The Incus advisory, written for the same class of flaw in Incus, puts it the same way: the listener "requests client certificates without verifying them", and the checks "compared every certificate in the presented chain against the trust store".

Zoom

The Incus fix is public. Its commit, dated 29 October 2026, says the listener "only proves possession of the first certificate in the client's chain" and changes every trust store check to "Match only the first peer certificate". The commit also covers the paths that renew or delete a trust entry, the virtual machine agent connection and the authorization scriptlet, matching the impact list in the Incus advisory.

Canonical's equivalent change could not be read. Its advisory and the CVE record both link a GitHub advisory, GHSA-99jp-jwmc-65p4 in the canonical/lxd repository, which returned "Not Found" through the GitHub API and the web page at about 10:49 GMT on 1 November and again at 11:03 GMT, and the canonical/lxd advisory list did not include it (its newest entries were dated 25 September 2026). No canonical/lxd commit whose title describes the fix was found between the lxd-5.21.8 and lxd-5.21.9 tags, between lxd-6.10.0 and lxd-6.10.1, or in the history behind the 6.10.1 build the store serves. That search was by commit title only, so it does not show the fix is absent from the public code; it shows only that it is not labelled. So the green half of the diagram is the Incus fix, and how Canonical fixed LXD is not stated on the record.

Two preconditions, and who meets them by default

Canonical names two conditions. The attacker must be "able to reach the LXD HTTPS API", and must have "the public certificate" of a trusted client. Both must hold.

Standalone LXD in its default state does not meet the first. Canonical's documentation says: "By default, LXD can be used only by local users through a Unix socket and is not accessible over the network." To expose it, an administrator must "set the core.https_address server configuration option". A server where that option is set listens on the network, and anyone who can reach that address meets the first condition.

MicroCloud has a specific weak moment. Canonical's advisory says that in MicroCloud "it is possible for an attacker to intercept the public TLS certificate of a joining cluster member, and subsequently authenticate as that joined member." The advisory does not describe the join process further, and the CVE record does not list MicroCloud as a product. A MicroCloud is a cluster of machines that talk to each other, so a network path to its members is the normal state (inference; Canonical does not state MicroCloud's default listener).

For Incus, the certificate condition needed no prior access. The Incus advisory says that "Server certificates are returned by every TLS handshake, so no prior access is needed to obtain one", and that presenting the server's own or another member's certificate gave database or internal cluster access. Canonical's advisory does not say whether the same server certificate route applied to LXD. Its CVE description, which says the flaw lets an "unauthenticated attacker" gain "full access to the cluster and managed virtual machines", reads in that direction, but the record does not spell it out. A defender should not assume the certificate condition is hard to meet.

Zoom

What an impersonated client can then do depends on that client. Canonical's advisory: "Depending on the privilege of the victim user, the attacker may gain root access to the host machine." The LXD documentation explains why that range is wide. The usual way to add a client, a certificate add token, comes with the note "The recipient of this token will have full access to LXD", unless the administrator uses the restricted option to confine the client to projects. So a server whose trust store holds even one unrestricted client certificate offers full access to whoever can borrow it. A server whose clients are all restricted limits the damage to their projects, as far as the advisory's wording goes.

Note the difference in strength between Canonical's two texts. The advisory says "may gain root access" depending on privilege; the CVE record says "full access to the cluster and managed virtual machines". This briefing uses each in its own words and does not stretch either.

What CVSS 10.0 encodes, and the labels that do not mean what they seem

A score of 10.0 and the word "impersonate" invite two readings the record does not support: that the flaw is being exploited, and that any LXD server on the internet is open to anyone. Neither follows. The vector describes the flaw where the API is reachable. It says nothing about how many servers expose the API, and the record's exploit maturity field is "NOT_DEFINED".

Two more labels need care. The CVE description calls the attacker "unauthenticated". That is accurate in the scoring sense, since the attacker needs no credentials of its own, but the attack still needs a trusted client's public certificate and a network path. And Ubuntu's CVE page gives the CVE an Ubuntu priority of Medium, beside a package table in which the Ubuntu archive's lxd package is "Not affected" in 16.04, 18.04 and 20.04 and "Not in release" from 22.04 onward. The page does not explain the rating on this CVE. Read with its table, it describes the archive package, not the snaps where the fixed builds live (inference). A Medium on that page is not a Medium for a snap install.

CISA's assessment in the record also sets "Automatable: yes" and "Technical Impact: total". Those two values are the reason not to wait for an exploitation signal: if the flaw is used, CISA's view is that it can be used at scale and with complete effect.

Fixed versions, channels, and what the snap store showed on 1 November

Canonical's advisory dates every fix 2026-10-29 and adds: "All LXD point releases are currently in progressive roll out from candidate to stable." The three older LXD release posts each carry a follow up dated 29 October at about 21:25 UTC saying the release "is currently in" its candidate channel and that roll out to stable "will begin shortly" (the 5.21.9 post is one). When the store pages for lxd and microcloud were read at 10:53 GMT on 1 November, every fixed version was in its stable channel. For the 4.0, 5.0 and 5.21 tracks the store showed the stable release date as "Today".

Three things follow. First, the advisory's single date is the date the fixes were published, not the date every stable channel carried them: on the record, the three older LXD stable channels caught up later, and "progressive" means not every machine at once. A refresh command that ran is therefore not proof of a fixed version; the installed version is. Second, the 6.10.1 build in 6/stable has the same store revision as the one in 6/candidate since 22 October, seven days before its stable date (derived from the store table; the store does not say what that build contains beyond its version). Third, two tracks still in the store, LXD 3.0 and MicroCloud 1, appear in neither the advisory nor the CVE record. Whether they are affected is not stated.

The CVE record's affected ranges also need reading carefully. Each LXD line is listed from a single point release (4.0.14, 5.0.10, 5.21.8 and 6.9.0) up to the fixed one, with every other version marked unaffected by default. The record does not explain why the ranges start there, and Canonical does not say when the flaw entered LXD. The Incus advisory says of its own code: "This has been the case since the initial release." Anyone running an older point release in any track should not read the record as clearing it, and should move to the fixed version anyway (this site's advice).

Timeline from the records

Stated on the record, and not stated

Incus: the same class of flaw, fixed in 7.6.0 alongside 17 other security issues

Incus is a separate container and virtual machine manager, which The Hacker News describes as having begun as a community fork of LXD. Its advisory, GHSA-xg75-xf37-cph9, is titled "Authentication and authorization bypass through unverified client certificate chains", rated critical, and marks versions below v7.6.0 vulnerable and v7.6.0 patched. It carries no CVE identifier of its own: the API's CVE field is empty and the fix commit says "CVE pending". So CVE-2026-112816 is Canonical's number for LXD; Incus's flaw is the same class in a separate code base, not the same CVE.

The Incus advisory lists more consequences than Canonical's: authentication as any trusted client, metrics or server certificate; internal cluster access; the ability to renew or delete any trust store entry through the self service paths; the agent connection between host and virtual machines; and authorization scriptlet decisions, including for clients that log in by token or OIDC. Its workaround is: "Restrict network access to the HTTPS listener to trusted hosts. There is no configuration based workaround."

The Incus 7.6 release post says it "fixes 18 security issues" and lists them: 8 rated critical, 5 high and 5 medium (counts derived from the list). This flaw is one of the 8 critical ones, so 17 others shipped in the same release (derived). The release post says nothing about workarounds.

Interests, plainly: Canonical makes LXD and MicroCloud and wrote the advisory, the CVE record and the Ubuntu page. The Incus project maintains a separate product in the same space and reported the flaw. The only independent party on the record is CISA, through its assessment in the CVE record.

What to do, in order

Technical details

Each block below is copied from the primary named in its caption, read on 1 November 2026. Nothing here shows how to build a chain; the primaries do not print one and this briefing does not either.

The fix table. Canonical's advisory prints the fixed snap versions as a table. Use it to compare against the version the snap tool reports on each host.

Channel      Snap Name   Fixed Version  Release date
6/stable     lxd         6.10.1         2026-10-29
5.21/stable  lxd         5.21.9         2026-10-29
5.0/stable   lxd         5.0.11         2026-10-29
4.0/stable   lxd         4.0.15         2026-10-29
2/stable     microcloud  2.1.5          2026-10-29
3/stable     microcloud  3.4.1          2026-10-29

The update commands. These are the two commands in the advisory's "How to address" section. They refresh the snap in its current channel; they do not move a host to another track.

sudo snap refresh lxd
sudo snap refresh microcloud

The setting that exposes the API. The LXD documentation uses this command as its example of exposing LXD on port 8443. A defender looks for core.https_address in the server configuration; the second command, from the configuration guide, displays that configuration.

lxc config set core.https_address :8443
lxc config show

The scores. Canonical's vector from the CVE record, and the Incus advisory's vector for the Incus flaw. They use different CVSS versions, so compare them metric by metric, not number by number.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

The affected ranges. The LXD version ranges exactly as the CVE record lists them. The record's default status for any version not listed is "unaffected"; see the section on versions for why that should not reassure.

[
  {
    "status": "affected",
    "version": "4.0.14",
    "lessThan": "4.0.15",
    "versionType": "semver"
  },
  {
    "status": "affected",
    "version": "5.0.10",
    "lessThan": "5.0.11",
    "versionType": "semver"
  },
  {
    "status": "affected",
    "version": "5.21.8",
    "lessThan": "5.21.9",
    "versionType": "semver"
  },
  {
    "status": "affected",
    "version": "6.9.0",
    "lessThan": "6.10.1",
    "versionType": "semver"
  }
]

CISA's assessment. The CISA ADP block in the same record. It is a dated assessment, not a guarantee; re-check the record and the KEV catalogue before relying on it.

timestamp: 2026-10-30T00:00:00+00:00
Exploitation: none
Automatable: yes
Technical Impact: total
role: CISA Coordinator

The Incus range. The package and versions the Incus advisory marks.

package: github.com/lxc/incus/v7/cmd/incusd (go)
vulnerable_version_range: < v7.6.0
patched_versions: >= v7.6.0

What this briefing could and could not check

• Canonical's GitHub advisory and fix commit. Not readable: the advisory returned Not Found, and no fix commit was identified by title. The mechanism rests on Canonical's Discourse advisory and the Incus advisory and commit.
• Exploit code. This briefing did not search for or read any exploit code, and makes no claim about whether any has been published.
• Exposed server counts. None was found in any primary, and none is given here.
• The Hacker News, 1 November 2026. Its version table, the Ubuntu archive status, the CISA assessment of 30 October and the 17 other Incus fixes all match the primaries. Its line that no working exploit has been published is not repeated, because no primary was checked for it.
• The store's "Today". It is the store's own relative label on the page read at 10:53 GMT on 1 November 2026, and it may change as the page is regenerated.
• Time stamped. Sources were read between 10:47 and 11:03 GMT on 1 November 2026. Canonical's advisory was re-read at the end; a KEV listing, a published GitHub advisory or a new CVE for Incus could change this picture within hours.

The question that exposes the gap

For every LXD or MicroCloud server you run with the API on the network, can you name each certificate in its trust store, say what it is allowed to do, and say who besides its owner has ever held a copy of the public half?

Key facts