LXD hit by 11 flaws including CVE-2026-63294, only 4 affect solo hosts

On August 12, 2026, the US vulnerability database NVD published 11 vulnerabilities at once in LXD, a product from Canonical, the company behind Ubuntu. Nine of them carry a CVSS score of 9.9, which sits almost at the top of the 10-point scale.

On the numbers alone, this looks like a major incident. Dig into the details, though, and the picture changes considerably. The fixes finished rolling out on August 2, so for most users automatic updates already handled it. On top of that, two of the nine supposed 9.9s were rated "High" (8.7 and 8.5) by Canonical itself, and only ballooned to the top tier because of a mismatch in the submitted data.

This article breaks down what the 11 issues actually are, which of them apply to you, and which version you need to be on. The short version: if you run a server by yourself and you are not in the habit of importing files made by other people, none of the 11 cause you any real harm. Conversely, exactly one behavior hits even solo users directly.

What LXD actually does

LXD is management software built by Canonical, the UK company that develops Ubuntu, an operating system for PCs and servers. In one sentence, it is a tool for creating and running many independent miniature servers inside a single physical server.

Say you have one physical server. You can carve it into compartments — one for the development team, one for the accounting system, one to rent out to customers — and run each as if it were a separate machine. These compartments are called containers, or lightweight virtual machines. If the concept is new to you, we have an earlier article explaining how containers work that is worth a look.

Docker is the best-known tool in the same space, but where Docker is a box for running a single application, LXD handles boxes that run an entire operating system. It is used by hosting providers, home server enthusiasts, and research labs sharing machines.

LXD also has a fork called Incus. It was created by developers who split off in 2023 when Canonical changed LXD's governance, and distributions such as Debian ship it instead. Incus is relevant here too, and we return to it later.

What the 11 vulnerabilities are

The table below summarizes all 11, based on Canonical's official advisory and the technical details for each CVE (GitHub security advisories).

Not one of the 11 can be attacked by anyone from the internet. Every one of them requires either an account of some kind on the LXD server, or an administrator who imports a crafted file themselves. That fact alone puts a lot of distance between reality and the impression a 9.9 gives off.

Who targets these holes, and what they get

The people in a position to exploit these 11 issues are not attackers scanning the internet at random. They are legitimate account holders who rent a single compartment on the server: a student sharing a lab machine, another department inside the company, the tenant next door at a hosting provider. In other words, someone who already has a small foothold inside. The other entry point is whoever plants the tampering in a template file that gets shared around. That person does not even need to get inside; they just wait for an administrator to import the file.

What they do next is break through the walls of the small room they were given. They should only be able to touch their own compartment, but by exploiting missing validation on settings or by swapping file paths, they obtain administrator privileges on the host itself. CVE-2026-63294 is the shortest confirmed path of all: getting a crafted file imported is enough to hook your own code into the server's startup processing.

What is lost if someone gets that far? Taking over the host means being able to look inside every other compartment on the same machine: other companies' or departments' databases, stored customer records, backups, key files. Keeping separate passwords per compartment does not help. For the operator, the entire premise that "one machine can be safely rented to multiple parties" collapses. That is why Canonical describes this set of flaws as significantly undermining the isolation guarantees LXD provides. The flip side, though, is that if your usage does not depend on that isolation, the impact never reaches you. The next section draws the line.

Which ones apply to you

Sorted by what they require, the 11 split cleanly into two groups. This is the most practical part of the whole story.

Group A: only if you share one machine with others (7 issues)

CVE-2026-62420, 63295, 63296, 63297, 63298, 63299 and 63300 only matter if you use LXD's "projects" feature as a wall to isolate parties you do not fully trust. The attacker's role is filled by someone inside a restricted project, and the damage takes the form of that person climbing over the wall.

If you are the only person who operates your LXD instance, there is nobody available to play the attacker for these seven. Two of them, CVE-2026-62420 and CVE-2026-63296, additionally require a cluster of several servers bound together. If you simply run a few containers on a single home server, you can leave these seven alone.

Group B: if you import files made by other people (4 issues)

This group is the real problem. CVE-2026-63293, 63294, 16033 and 66898 need no sharing and no cluster at all. There is exactly one condition: who created that image or backup.

Concretely, that means VM templates shared on a forum or in a chat room, migration backups received from another company, prebuilt images picked up on GitHub. The moment you run the command to import one of those, you hand over the host server with your own hands. It makes no difference that the machine is "just mine and therefore safe."

That said, if you only use Canonical's official image sources, this is not a practical threat. These four are only dangerous when you bring in files of unknown origin. This pattern of pulling an untrusted component into your own environment is the same family of problem as the case where contamination spread in a chain through development tool dependencies and the officially distributed container image that shipped with default credentials still in place. Doing one pass to inventory what your environment pulls in from outside — with a tool like the free OSS supply chain scanner we publish on this site — makes that much easier to see.

"Nine issues at 9.9" was actually padded

Here is a detail you will not find in the syndicated coverage. Of the nine issues listed at 9.9 on NVD, two are not rated that high by Canonical itself.

A vulnerability score (CVSS) is calculated mechanically from a short string that lists conditions such as whether the attack works over the network, whether privileges are needed, and what gets broken. In this case, for CVE-2026-63298 and CVE-2026-63299, the score Canonical submitted did not match the condition string it submitted alongside it.

NVD does not simply take the submitted score at face value; it recalculates from the condition string. As a result, two issues Canonical had judged "High" went out to the world as "Critical." The number of issues actually rated 9.9 is therefore seven, not nine.

It sounds like a minor discrepancy, but most vulnerability management tools automatically treat anything at CVSS 9.0 or above as a top-priority alert. Whether an operations engineer gets woken up in the middle of the night comes down to exactly those two entries. This is a textbook illustration of why you should read the conditions and prerequisites before setting priorities rather than taking the CVSS number at face value. If you also want to check whether a vulnerability is being exploited in the wild, we publish a dashboard for searching CISA's Known Exploited Vulnerabilities catalog in Japanese. None of these 11 appear on that list.

Which version you need to be on

Canonical's fixed versions are listed below. LXD splits into separate lines by distribution channel, so you only need to look at the row for the line you use.

If you run LXD on Ubuntu, it is normally installed through snap with automatic updates enabled. As of August 2, the fixes had reached every stable channel. To confirm, check the version with snap list lxd and, if it is out of date, run sudo snap refresh lxd. Note that this is a different path from Ubuntu's own updates, which go through apt — the mechanism involved in the serious vulnerability found in Ubuntu's standard management tool and the case involving the AD integration tool ADSys.

You cannot follow the advice to "update to 6.10"

This is the easiest trap to fall into here. The CVE records and some advisories list "6.10" as the fixed version for the 6 line. But LXD 6.10 does not exist as of August 13, 2026. The latest tag for the 6 line on GitHub is still lxd-6.9 from June 23.

The only place the fix actually landed is the interim snap that replaced 6.9 (6.9-ab8fad2). In other words, if you build the 6 line from source yourself, there is currently no path for you to receive the fix. Waiting to upgrade "once 6.10 comes out" leaves you vulnerable indefinitely. If that describes you, you need to either pull in the commits containing the fix or switch to an LTS line such as 5.21.6.

The fix was done 11 days earlier

The impression that "11 vulnerabilities were disclosed on August 12" comes purely from the NVD publication date. Here is what actually happened.

← Swipe to navigate

Vulnerability monitoring tools and subscription feeds fire their alerts based on NVD publication. That is how you end up with a case like this one, where everything goes off at once more than ten days after the fix was done. The day the alarm rings and the window during which you were at risk are two completely different things. This applies far beyond this incident; it comes up every time you work with CVE dates.

Incus has the same holes, but they do not show up in the numbers

Canonical's advisory contains an interesting line. It states explicitly that some of these vulnerabilities were reported by the Incus project and then confirmed to affect LXD as well. And indeed, Incus published its security information on July 30, a day ahead of LXD: flaws found by Incus developers were shared with LXD.

Yet as of August 13, 2026, the Incus-side vulnerabilities have no CVE IDs. Incus delegates ID assignment to GitHub, and GitHub's queue is running three to four weeks behind. Canonical, by contrast, can issue IDs itself, so all 11 went public the same day.

The consequence is predictable. Look at a vulnerability scanner or a threat intelligence feed and it appears that LXD is full of holes while Incus is clean. In reality both carry the same flaws; one of them is simply waiting on IDs and therefore missing from the statistics. This incident is a clear illustration of the obvious point that the presence or absence of a CVE ID says nothing about a product's safety. Keep that asymmetry in mind whenever you compare products by the numbers.

Note also that Debian moved some time ago to shipping Incus rather than LXD, and the LXD it still carries is an old build from the 5.0 line. If you use LXD on Debian, triage of these 11 issues has not even begun. You will need to verify this yourself.

Is there any sign of exploitation?

At present, there are no reports of actual attacks and no public exploit code. Here is the summary.

There has been almost no press coverage either. None of the major international security outlets have run the story, and the developer community has stayed quiet. Canonical's official advisory from July has not received a single reply, and related threads on English-language technical forums have gone by with zero comments. The fixes had already shipped, and this is not the kind of flaw that can be attacked remotely and unilaterally, so there was never much for anyone to get worked up about.

Who found them

The 11 issues are not the output of a single research team. Six separate reporters found them independently, and Canonical processed them together. The most prolific reporter is Zhixi "Jace" Sun of the security team at the video sharing service TikTok, who was involved in 6 of the 11. Others credited include Adam Jordan of Indonesia and penetration tester Kingsley Olukanni.

Reading through the details, the approach is not brute-force attack experimentation but careful source code reading to find logical gaps. CVE-2026-16033, for example, came from noticing that a separate vulnerability fixed in June had received a guard on the container code path but not on the virtual machine path. Two of the 11 are re-exploitations of incomplete previous fixes. This pattern of chasing down missed patches also showed up in the Linux kernel privilege escalation vulnerability and the OpenShift traffic hijacking case — once a spot has been patched, it tends to attract renewed scrutiny.

So what should you actually do?

There is not much to it. Start by checking your version with snap list lxd; if you are on 5.21.6, 5.0.8, 4.0.12 or 6.9-ab8fad2, you are done. If not, run sudo snap refresh lxd. Only two groups need to verify the state of the fixes for themselves: those building the 6 line from source, and those using Debian's packaged version.

Going forward, the one operational habit worth internalizing is this: do not import images or backups of unknown origin. Of these 11 issues, all four that hit solo users came in through that door. Sticking to official distribution sources closes that path.

To recap once more: the count at 9.9 is seven, not nine; all 11 require authentication or an administrator action; seven of them are irrelevant unless you share a machine with other people; the fixes finished rolling out on August 2; and there are no reports of exploitation. There is no need to panic at a headline that says "nine CVSS 9.9 flaws." Two groups, though, are worth acting on right now: anyone waiting for 6.10, and anyone casually importing other people's images.

References

• ▸ Canonical - Security advisory: Multiple vulnerabilities found in Canonical LXD
• ▸ GitHub - canonical/lxd security advisories
• ▸ Canonical - LXD 6.9 interim snap release (6.9-ab8fad2)
• ▸ Canonical - LXD 5.21.6 LTS has been released (July 23, 2026)
• ▸ Canonical - LXD 4.0.12 LTS has been released
• ▸ NVD - CVE-2026-63294
• ▸ NVD - CVE-2026-63293
• ▸ NVD - CVE-2026-66898
• ▸ NVD - CVE-2026-63298
• ▸ NVD - CVE-2026-63299
• ▸ GitHub - lxc/incus security advisories
• ▸ Linux Containers - Incus 7.3 has been released (July 31, 2026)
• ▸ Debian Security Tracker - lxd
• ▸ CISA - Known Exploited Vulnerabilities Catalog