Skip to content

Independent cybersecurity briefing

Latest

RSS
Breaches, bounties, zero-days, and AI.

Zero-Days & CVEs

CVE-2026-112816: LXD and MicroCloud score CVSS 10.0

Canonical's LXD and MicroCloud can accept a caller as a trusted client when that caller holds only the client's public certificate and can reach the HTTPS API. Refresh the snap and confirm the fixed build is the one installed.

By ZeroDay Times Desk2 min read

Story card “CVSS 10” for Linux, CVE-2026-112816, terminal view, [ ZERO-DAY ] badge, and the ZeroDay Times mark.

Canonical has patched CVE-2026-112816 in LXD and MicroCloud and scored it 10.0. The break is in the HTTPS listener remote clients use to prove who they are. A caller who can reach that API, and who has the public certificate of a client the server already trusts, can be accepted as that client. The private key never has to leave its owner.

The authority that follows is the client’s. On a cluster, that includes the machines and the virtual machines they run. Canonical says a privileged identity can mean root on the host. Public certificates are supposed to be shareable. On an unpatched listener, possession of one was enough to wear the name.

Who is actually listening

A standalone LXD server keeps that API off the network unless an administrator turns it on. The default is a local socket. The switch is core.https_address. A host that still uses only the local socket stays off this path until someone fills that setting in.

MicroCloud is the sharper case. It ties several LXD machines into one cluster. Canonical says a joining member’s public certificate can be observed during the join and then used to sign in as that member. Cluster expansion is the moment the certificate is easiest for someone else to see.

Incus, the community fork, reported the flaw. Canonical confirmed LXD had it too. Incus ships its fix in 7.6.0, in a release that also covers other security issues, so read those notes before you treat this CVE as the only change. Ubuntu’s archive packages of LXD are listed as unaffected or not shipped. The installs that matter are snaps.

The builds that close it

Canonical’s fixed snaps landed on October 29, 2026. LXD 6/stable is 6.10.1, 5.21/stable is 5.21.9, 5.0/stable is 5.0.11, and 4.0/stable is 4.0.15. MicroCloud 3/stable is 3.4.1 and 2/stable is 2.1.5. The CVE record names the releases immediately before those — LXD 4.0.14, 5.0.10, 5.21.8, and 6.9 — as affected. Compare the installed revision with the fixed build for your channel.

The LXD point releases were still moving from the candidate channel to stable when the advisory went out. A refresh can finish and still leave the old build in place. Read the version back after the refresh.

The advisory lists no configuration change that repairs the check. Until the fixed snap is what the host is running, the useful reduction is reach: the HTTPS API should be open only to the people who already administer the cluster. Incus said the same about its listener.

What to do this week

Refresh LXD and MicroCloud on every cluster member, then match the snap version to the builds above. Update the members you already have before you join a new node.

Find every host where the network API is enabled. A lab box that gained core.https_address for a demo and never lost it is in scope.

CISA’s October 30 assessment recorded no known exploitation, and the flaw is not in the Known Exploited Vulnerabilities catalog. A trusted client on these products is an administrator wearing a certificate, and the check still sits at CVSS 10.0 on any cluster that runs production virtual machines.

This briefing relies on public reporting by The Hacker News and on Canonical’s security advisory. It does not include exploit procedures.

Corrections and tips:[email protected]