LXD and MicroCloud fixes stop trusted-client impersonation
LXD and MicroCloud can accept a trusted public certificate without its private key; check API exposure, match fixed snap releases and verify the update.
CVE-2026-112816 lets an attacker impersonate a trusted LXD or MicroCloud client without possessing that client's private key. The requirements are narrower: access to the HTTPS API and a copy of the client's public certificate. Canonical has released fixed snaps. The maximum CVSS score is 10.0, and an impersonated identity with enough privileges can give the attacker host-root access.
The Hacker News report attributes that host-root warning to Canonical.
Why the certificate check accepts the wrong client
The vulnerable server looked through the entire certificate chain supplied by the client to find a trusted identity. TLS proved something narrower. It established possession of a private key for the first certificate—the leaf—not possession of the keys belonging to every certificate the client attached behind it.
LXD and MicroCloud use mutual TLS for remote API access. A client presents a certificate, and the server's trust store identifies the certificates it accepts as trusted clients. That design depends on a specific connection: the identity the server accepts must belong to the private key whose possession TLS actually proves.
The faulty check broke that connection. An attacker could supply their own certificate as the leaf and place a legitimate client's public certificate later in the chain. The server checked every supplied certificate against its trust store, not just the leaf. Finding the legitimate certificate behind it could therefore cause the server to authenticate the attacker as that trusted client.
I read this as an identity-binding failure. It is not evidence that TLS encryption itself is broken. To assess the potential privilege escalation, I'd look at the impersonated client's permissions rather than stop at the maximum severity score. That score does not mean every successful impersonation reaches host root. The permissions attached to the accepted identity still determine what the attacker can do.
Which LXD and MicroCloud deployments are exposed?
A standalone LXD server using its default local socket does not expose the network API required for this attack.
On standalone LXD, the network API becomes reachable only after an administrator enables it through core.https_address. That listener configuration is where I'd start the deployment check.
Before assigning patch priority, I'd divide the inventory into these two groups:
- Network-accessible LXD and MicroCloud: prioritise affected builds according to who can reach the HTTPS API and what permissions belong to the trusted identities an attacker could impersonate.
- Local-socket-only standalone LXD: place it behind reachable deployments for this issue.
For MicroCloud, Canonical says an attacker who captures a member's public certificate during its cluster join can subsequently log in as that member. I'd examine the network used for joining as well as ordinary API access. Those are separate moments in the attack: capturing the certificate during the join does not require the attacker to use it for impersonation at that same time.
Network access does not mean internet access. The prerequisite is reachability to the HTTPS API, wherever the listener happens to sit. I would not clear an affected deployment merely because the address is on a private network.
Fixed LXD and MicroCloud snap releases
Canonical lists fixed releases for the snap channels below. Check the product and the channel together against the installation in front of you. Both must match. A fixed version from another release line is not the update target for that installation, even though it appears in the same table.
| Product | Snap channel | Fixed version |
|---|---|---|
| LXD | 6/stable | 6.10.1 |
| LXD | 5.21/stable | 5.21.9 |
| LXD | 5.0/stable | 5.0.11 |
| LXD | 4.0/stable | 4.0.15 |
| MicroCloud | 3/stable | 3.4.1 |
| MicroCloud | 2/stable | 2.1.5 |
The CVE record cited in the reporting explicitly identifies LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected. The affected-version list is not a complete inventory of every vulnerable build, and I would not use it that way.
Ubuntu's own archive packages of LXD are listed as not affected or not shipped. These fixes are for snaps. Keep those package sources separate when assessing an installation: the archive status does not mean every LXD installation on Ubuntu is unaffected.
Refresh the snaps, then check what is installed
When Canonical issued the advisory, it warned that fixed LXD point releases were still moving from candidate to stable. A successful update request was therefore insufficient evidence that the installation had received the correction; the installed version was the thing to check.
Identify the installed product, package source and snap channel. Use the table above for snap installations.
Refresh LXD where it is installed.
sudo snap refresh lxdRefresh MicroCloud where it is installed.
sudo snap refresh microcloudInspect the installed version after the refresh. Compare it with the fixed release for that product and channel.
Network restrictions reduce exposure but do not repair trust
Restricting access to the HTTPS API reduces risk while updates are applied. It does not fix certificate validation. Canonical's LXD advisory gives no temporary workaround; Incus says there is no configuration fix and advises restricting access to the listener.
I'd identify the machines that genuinely need remote API access and, where the deployment permits it, narrow reachability to those machines.
I would not substitute secrecy around public certificates for a server fix. They are public certificates.
Incus requires its own update to 7.6.0
Incus fixed the same flaw in version 7.6.0. An Incus deployment needs the Incus update. The LXD and MicroCloud snap refresh commands above do not provide a remediation procedure for it, and I would not treat those commands as instructions for updating an Incus installation.
Incus began as a community fork of LXD, and the Incus project reported the issue. Canonical then confirmed that LXD was affected too. The Incus 7.6.0 release addressed this vulnerability along with 17 other security issues.
Public exploitation evidence has a date
The supplied reporting describes no public indication of exploitation, no working published exploit and no entry in CISA's Known Exploited Vulnerabilities list.
The reports were published on November 1, 2026, and cite a CISA assessment dated October 30. Both predate today, November 2, 2026. The assessment says the vulnerability is not known to have been exploited. That is a limited statement. It does not say exploitation is impossible or establish that any particular deployment is uncompromised; neither claim follows from the assessment.
Frequently asked questions
Does this vulnerability mean a trusted client's private key was stolen?
No. The attack specifically works without that private key: the attacker attaches the trusted client's public certificate behind their own certificate. The supplied reports prescribe updating the affected server software, not private-key rotation as a substitute for patching.
Does the HTTPS API have to be exposed to the internet?
No internet-specific requirement is stated. The attacker needs network access to the HTTPS API, so a private-network listener still needs assessment if an attacker could reach it.
Do the refresh commands guarantee a disruption-free cluster update?
The supplied reports do not provide that guarantee or document a cluster rollout and rollback procedure. Use the deployment's established maintenance process, verify the installed fixed version and check legitimate client access afterwards.
Sources: CVSS 10.0 LXD, MicroCloud Flaw Lets Attackers Impersonate Trusted Clients Without a Private Key, CVSS 10.0 LXD MicroCloud Vulnerability Allows Trusted Client Impersonation - The 420.in
How we research, write and check articles
