Canonical LXD, CVE-2026-112816: a new CVE scored 10

The short version

Canonical LXD (CVE-2026-112816) is a new CVE record, published by Canonical on 30 October 2026, with a base score of 10 (CVSS 4.0). We picked it for our daily highlight on 31 October 2026.

It is not on CISA's list of exploited vulnerabilities when we read it, which means nothing public says yet that anyone is using it. A high score is the record's author describing the worst case. Read the conditions before you act on the number.

Free analysis report · 8 pagesCanonical LXD, CVE-2026-112816: a new CVE scored 10The same note as a document you can keep or forward: what the sources say, who is affected, and what to do first.Download the analysis report →

Our reading

An attacker who can reach the LXD HTTPS API can log in as any trusted client whose public certificate they hold, by sending a crafted certificate chain. The record says this gives full access to the cluster and its managed virtual machines.

Anyone running LXD or MicroCloud whose HTTPS API can be reached from networks or machines you do not fully trust, and anyone adding members to a MicroCloud cluster.

Why it matters

The vendor's advisory says an attacker needs only a victim's public certificate, and that depending on the victim's privilege this may give root access to the host. Our reading is that no password or private key is involved, so any reachable API plus any trusted certificate that has been seen or shared is a way in. The vendor calls it critical and the record scores it 10.

What the record says

The CVE record says:

Improper certificate validation in the HTTPS listener in Canonical LXD 4.0.14, 5.0.10, 5.21.8, 6.9 before 4.0.15, 5.0.11, 5.21.9, 6.10.1 allows an unauthenticated attacker to authenticate as any trusted client and gain full access to the cluster and managed virtual machines via a crafted certificate chain.

What the vendor's advisory says

We read three pages on discourse.ubuntu.com. In short:

• The advisory says the flaw was referred by the Incus project and confirmed to affect LXD as well. It covers LXD and MicroCloud.
• Fixed snap versions, all released on 29 October 2026: lxd 6.10.1, 5.21.9, 5.0.11 and 4.0.15; microcloud 2.1.5 and 3.4.1.
• For MicroCloud, the advisory says an attacker can intercept the public certificate of a joining cluster member and then authenticate as that member.
• The advisory says the LXD point releases are in progressive roll out from candidate to stable, so a refresh may not offer the fix on every channel yet.
• The 5.21.9 release post, updated on 29 October 2026, says that release was in 5.21/candidate and roll out to 5.21/stable was about to begin.

Are you affected?

The record lists these versions of Canonical LXD as affected:

• 4.0.14 up to, but not including, 4.0.15
• 5.0.10 up to, but not including, 5.0.11
• 5.21.8 up to, but not including, 5.21.9
• 6.9.0 up to, but not including, 6.10.1

If you run it, find the version number first. If you cannot say what you run, that is the first job, and your IT provider can answer it in minutes.

Exposure by situation

These priorities are our judgement from what the sources say about who can use the flaw and how. They are not vendor ratings.

Things people will get wrong

• "The attacker needs to steal a private key." The advisory says only the public certificate is needed. The server checked every certificate in the chain, but only the leaf proves ownership of the key.
• "This only affects MicroCloud." The advisory says both LXD and MicroCloud are affected. The record itself names LXD versions.
• "It is not on CISA's list, so it is not being used." The listing only says CISA had not listed it when we read it. The sources say nothing either way about use.

How we would triage it

This is our judgement.

The commands only read: they print a version or list what is installed. They come from general knowledge of this kind of product, not from the sources, so check them against the vendor's page before you run them. Words in capitals are for you to fill in.

Step 1: Find the versions you run

• List every host running LXD or MicroCloud and note the installed version.
• Compare each with the fixed versions in the advisory for its channel.

snap list lxd
snap list microcloud
lxd --version

Step 2: Reduce exposure

• Find which hosts expose the HTTPS API. The attack needs to reach it.
• Limit access to known management addresses until you have updated.

sudo lxc config get core.https_address
ss -tlnp

Step 3: Patch

• Refresh the snaps, as the advisory says. If no update is offered, roll out is progressive: check again and note which channel you follow.
• Do not add new members to a MicroCloud cluster on an unpatched version.

snap info lxd

Step 4: Check the result

• Confirm each host now runs at least the fixed version.
• Our reading: review who holds a trusted client certificate and remove any you no longer need.

lxc config trust list

If it is in range and you cannot update today, write down who owns it, the new date, and what limits exposure until then.

Read the version from the product itself, not from an old inventory, and save the output with the date, so you can show later when it was done.

The weakness behind it

The record classes this as CWE-295.

What we do not know yet

• The sources do not say whether the HTTPS listener is on by default.
• The record does not say how an attacker would obtain a victim's public certificate on plain LXD.
• The sources give no log entry or sign that shows this attack happened.
• The sources do not say whether releases outside the listed lines are affected.
• This is a new record. We read the vendor pages named above, and nothing here has been tested.
• Scores, versions and wording can change in the first days. They are as at 31 October 2026.
• Exploitation is not recorded. That is not the same as none.
• The sections headed "Our reading", "Why it matters", "Exposure by situation", "Things people will get wrong" and "How we would triage it" are our interpretation of the sources, not a statement by CISA or the vendor.

• The day's CVE highlight →The three new records we picked that day, and how we chose them.
• Today's mission →Every exploited vulnerability from the last seven days, in the order their deadlines fall.