PolicyCortex
Request Access
Summary
  • Canonical confirms a certificate validation flaw in LXD and MicroCloud.
  • An attacker needs only network access and a trusted public certificate.
  • The fixed releases are LXD 4.0.15, 5.0.11, 5.21.9, and 6.10.1.
  • No exploitation is confirmed, and the flaw is not on the KEV list.

What Canonical warned

Canonical published a security advisory on October 28, 2026. LXD is its system container and virtual machine manager. MicroCloud groups LXD hosts into a cluster. The advisory covers a flaw in both products. An attacker able to reach the LXD HTTPS API can pose as a trusted client. HTTPS means Hypertext Transfer Protocol Secure. The attacker needs the public certificate of that trusted client. Public certificates are not secrets. They are shared freely in normal operation.

The flaw in plain words

The record is CVE-2026-112816. Common Vulnerabilities and Exposures (CVE) is the record system for public flaws. LXD checks client identity with mutual Transport Layer Security (TLS). TLS is the protocol that secures the connection. Each side presents a certificate to prove identity. The server keeps a trust store of accepted certificates. The flawed logic compared every peer certificate to that trust store. Only the leaf certificate proves key ownership. The leaf is the first certificate in the chain. The rest of the chain is whatever the client attaches. An attacker can attach a trusted public certificate behind their own leaf. The server then accepts them as the trusted client. In MicroCloud, an attacker can intercept a joining member public certificate. That attacker can then pose as that member. The weakness type is improper certificate validation, CWE-295. Common Weakness Enumeration (CWE) names the weakness type. The score is 10.0 on the Common Vulnerability Scoring System (CVSS) 4.0 scale. That is the top of the scale.

Who is affected

Affected LXD lines are 4.0.14, 5.0.10, 5.21.8, and 6.9. The fixed releases are 4.0.15, 5.0.11, 5.21.9, and 6.10.1. MicroCloud fixes are 3.4.1 and 2.1.5. Incus fixed the same flaw in version 7.6.0. Canonical says the impact depends on the victim privilege level. An attacker posing as an admin may gain root access to the host. Root access means full control of the host machine. The CVE record states full access to the cluster is possible. It also states full access to managed virtual machines is possible.

What is not confirmed

No exploitation is confirmed for this flaw. The CISA assessment on the CVE record states exploitation is none. The Cybersecurity and Infrastructure Security Agency (CISA) runs the Known Exploited Vulnerabilities (KEV) Catalog. This flaw is not in that catalog. Do not cite a KEV listing for this flaw. No public exploit is claimed here. No attacker is named in the advisory. No victim count is given. The flaw is severe without those claims. A maximum score plus host level access is enough.

What to do

Update LXD to the fixed release for your line. Update MicroCloud to 3.4.1 or 2.1.5. Use the snap refresh command for each package. Until the patch lands, limit HTTPS listener access to trusted hosts. No configuration change fixes the validation error itself. After patching, confirm the running release on each host. Record the old release, the new release, and the patch date. Review the trust store for entries that should not be there. Remove stale client certificates. A stale entry is an open door after the patch.

The governance lesson

Identity proof is a claim an assessor will test. A certificate in a trust store is an identity grant. This flaw shows a grant checked the wrong part of the chain. The check looked complete, but it proved nothing about ownership. Evidence must show the running release on each host. It must show the listener exposure for each host. It must show the trust store contents at patch time. PolicyCortex does not patch LXD hosts. PolicyCortex helps teams link proof to requirements.

Sources

Next step

Want identity and patch evidence linked to each requirement? See how PolicyCortex collects it from live systems.

Questions on this record
Which releases fix the flaw?
Use LXD 4.0.15, 5.0.11, 5.21.9, or 6.10.1 for your line.
Is this flaw on the exploited list?
No. It is not in the Known Exploited Vulnerabilities Catalog.
Does the attacker need a private key?
No. A public certificate of a trusted client is enough.
What helps until the patch lands?
Limit HTTPS listener access to trusted hosts only.

Related records

Guides and articles describe the work. The evidence that work produces is described in three proof pages and one architecture page.

proof.state
Proof of State. What the environment was, as of a date someone else picks: point-in-time records, content hashed and chained.
proof.change
Proof of Change. Who or what altered the environment, under what authority, with before and after state hashes.
proof.agency
Proof of Agency. What a machine was permitted to do before it acted, what it did, and what would have stopped it.
architecture
Architecture. How the chain is built and where it lives: inside your tenant, with no egress of evidence.

Further reading in this register

  1. Drupal Commerce Access Bypass Is Actively ExploitedDrupal warns that attackers are already using an access bypass flaw in Commerce Core. Patch to the fixed release and audit orders for tampering.5 min
  2. Ivanti Gateway Chain Grows With Two New Exploited FlawsCISA added two more Ivanti Connect Secure flaws to its exploited list on October 30, 2026. Together with an earlier flaw, they form a chain attackers already used.5 min
  3. Linux Kernel TCP Flaw Scores 9.8, With a Scoring DisputeA Linux kernel network flaw scored 9.8, but Red Hat rates it 5.9. The exploit needs a Multipath TCP listener, so check that detail first.5 min

Verify the record this entry describes.

Request AccessBook a call
Published
Last updated
Unchanged since publication
Author
Leonard Esere