This issue is not a WordPress plugin patch. It sits one layer below your website, in the container and virtual machine platforms that some hosting providers use to run customer workloads. If your site lives on shared hosting or a VPS, you probably cannot apply the fix yourself, but you can ask the right questions and record the answers. Everything below was checked as of November 2, 2026.
What the notices establish
Canonical published a security advisory for LXD and MicroCloud on October 28, 2026. It describes a critical weakness in how the HTTPS API validates client certificates. Where that API is reachable over the network, someone holding only the public certificate of a trusted client could impersonate that client, without ever having its private key. Depending on the privileges attached to that client, root access on the host is possible. For MicroCloud, the advisory adds a cluster case: an attacker able to intercept a member’s public certificate while it joins could later impersonate that joined member.
The Ubuntu record for CVE-2026-112816, published October 30, 2026, lists the affected releases as LXD 4.0.14, 5.0.10, 5.21.8 and 6.9, fixed in 4.0.15, 5.0.11, 5.21.9 and 6.10.1. It also notes that LXD packages in the Ubuntu archive are not affected or not shipped. The question therefore concerns snap-installed hosts. A host that is current with apt, or a website CMS that is fully updated, does not by itself verify that the snap fix is installed.
| Product | 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 | 2/stable | 2.1.5 |
| MicroCloud | 3/stable | 3.4.1 |
The fixed snaps are dated October 29, 2026. For the two Canonical snaps, the advisory supplies these commands:
sudo snap refresh lxd
sudo snap refresh microcloudThe advisory still describes a progressive rollout from the candidate to the stable channel, so a refresh may not deliver the fixed build on every host immediately. Check the installed version after refreshing. Stay on your current channel unless a channel change was already planned.
The related Incus advisory
Incus is a separately maintained fork of LXD. Its maintainers published GHSA-xg75-xf37-cph9 on October 29, 2026. The advisory currently lists no known CVE. Track Incus by its own GHSA identifier, and do not use the Canonical CVE above to identify the Incus issue. The HTTPS listener in the incusd daemon accepted a malicious certificate chain, so a server or member’s public certificate was enough for some access. There is no configuration-based fix. While patching, the project suggests restricting network access to the listener to trusted hosts. That is risk reduction, not a substitute for the patch. The two snap commands above do not apply to Incus. Incus administrators update to v7.6.0 or later using the installation method they already support.
| Product | Affected | Patched |
|---|---|---|
| Incus (github.com/lxc/incus/v7/cmd/incusd) | before v7.6.0 | v7.6.0 and later |
When this applies to you
Network reachability of the HTTPS API is the exposure condition for the attack these notices describe. It is not a reason to skip the update. The vendors ask all users to update, and a host without a network-reachable API is not thereby shown to be unaffected. According to the LXD documentation, LXD listens only on a local Unix socket by default, and remote HTTPS access exists only where an administrator has configured it with core.https_address. That default is a statement about LXD specifically. We make no equivalent claim for MicroCloud or Incus. Do not expose your own API to test this. The issue also does not mean every Linux or Ubuntu-hosted website is affected. It concerns hosts running these platforms, so the useful question for a shared-hosting or VPS customer is whether the provider’s control plane uses them. The flaw was reported more widely by The Hacker News on November 1, 2026.
Business implications
- Provider side. Root on a host puts every tenant’s files, credentials and local backups on that host in scope, not just one site.
- Owner side. Your exposure depends on infrastructure you do not control. What you can do is ask clear questions and keep the answers.
- Change windows. Treat the update as planned maintenance under your provider-approved process. Confirm a current backup exists first and check hosted services afterwards. We make no claim about how long the update takes or whether services are interrupted.
Practical checklist
These are practical checks from ViWeb, not vendor requirements.
If you administer your own LXD, MicroCloud or Incus hosts:
- Record product, channel and installed version for every cluster member before changing anything.
- Confirm whether the HTTPS API is bound to a network address and from where it can be reached.
- Verify a current backup and schedule a maintenance window.
- For LXD or MicroCloud, refresh the installed snaps in their current channel. For Incus, update to v7.6.0 or later using your supported installation method.
- Re-check the installed version on each member, since the Canonical rollout is progressive.
- Confirm hosted websites and services work after the update.
- If you suspect unexpected API access, preserve and review logs before rotating credentials. Do not rotate every certificate reflexively without evidence.
If you are on shared hosting or a VPS:
- Ask whether the control plane uses LXD, MicroCloud or Incus.
- Ask for product, channel and version on each member, and whether the API was reachable from the network.
- Ask for completion evidence, such as the date and result of a version check, rather than a bare “we are patched”.
- Check that your own site works after the provider’s maintenance.
Remaining limits
- The notices we opened describe the flaw and the fixes. They do not establish whether exploitation has or has not occurred, and we make no claim either way.
- A fixed version shows the host is patched now. It does not establish what happened before the update, and a patch is not evidence of no earlier compromise.