LXD Incus image vulnerabilities reached GitHub’s Advisory Database on 6 November 2026, when GitHub finished reviewing six Critical advisories for the Go module behind Canonical’s LXD. Each one scores CVSS 3.1 9.9. Each says it was reported from a matching Incus security advisory, and each lists a fix already present in the canonical/lxd code.
The underlying CVE records are older than the 6 November date suggests. NVD published all six CVE numbers on 21 August 2026, describing the flaw as affecting Incus, not LXD, before specific Incus versions. GitHub’s Go module page for canonical/lxd reused those same CVE numbers this week and gave them a Critical score for the first time.
Both projects run system containers and virtual machines, and teams that host several tenants on one LXD or Incus server are the ones with the most to check here. A flaw that lets one tenant’s image or snapshot reach the host affects every other tenant on that server, not only the one who uploaded it.
Brandefense already covers a different LXD flaw, a certificate-chain authentication bypass, CVE-2026-112816. That issue is unrelated in mechanism to the six advisories below, but a team reviewing one LXD flaw should check both while it has the deployment open.
What the LXD Incus Image Vulnerabilities Have in Common
Four of the six advisories share one pattern. A container image, built and offered by whoever controls it, is something the daemon has to partly trust before it can fully check it. Each advisory shows a different point where that early trust went too far.
In one advisory, the daemon fetches an image from a remote server. It accepts a fingerprint the same server supplies and writes the file to disk before confirming that fingerprint is genuine. A crafted fingerprint can point the write outside the folder the daemon expects.
In two further advisories, a crafted image contains a symlink where the daemon expects a plain folder. Unpacking the image follows that symlink, so a file the daemon later opens inside the image lands somewhere else on the host instead.
In the last of the four, a command’s output is supposed to stay inside the running container’s own output folder. If an image replaces that folder with a symlink first, the output file is created at the symlink’s target instead.
- Crafted image or snapshotAttackeroffered to the daemon
- Daemon accepts it as trustedIncus or LXD Daemonfingerprint or symlink not yet confirmed
- Content is unpacked or openedExtraction Stepprocesses the image
- A symlink or path escapes the expected folderExtraction Stepescapes
- A file lands outside the image’s own areaHost Filesystem
All four advisories, GHSA-pjff-c2wc-f6jm, GHSA-vghh-5rfx-xhq8, GHSA-jpf8-86f3-wp38 and GHSA-9j25-mm2h-2f76, say the result is arbitrary file read or write on the host. Each says that may lead on to command execution. We leave out the exact fields and paths the advisories use to do this on purpose.
A Restricted Project and a Backup Command: Two More Patterns
GHSA-47w9-6r3f-938g covers a different kind of boundary. An Incus or LXD project can be set to block certain low-level hardware options on the containers inside it. The advisory says that block is not re-checked against a snapshot that already carried one of those options before it moved into the restricted project.
Moving a snapshot between projects is a normal administrative action, not a bug by itself. The gap is that the restricted project trusts the snapshot’s own settings instead of re-applying its own rule when the snapshot is restored. A setting the project was built to block can still run.
GHSA-fmc8-p6q7-75cc covers the backup feature. A backup job lets the caller name the compression program to use. The advisory says the daemon checks only the first word of that setting against an allowed list, not anything added after it.
The extra, unchecked part of the setting reaches the compression program as further instructions. The advisory says a crafted setting can make that program write a file outside the backup, again as the daemon’s own user. We leave out the exact syntax the advisory uses to do this.
The Scores, the Advisories and the Fix Dates
GitHub’s score for every one of the six is CVSS 3.1 9.9, Critical, with network attack vector, low complexity and low privileges required. No CVSS 4.0 score appears in any of the six GHSA pages or in NVD. GitHub’s advisories list no known CVE field for the LXD-side entries themselves, but each one’s references point to the Incus-origin CVE record that NVD published on 21 August 2026.
CISA’s own decision records, attached to the NVD entries, add a detail the GHSA pages do not state directly. For CVE-2026-48769 (the remote-fingerprint advisory), CVE-2026-48751 (the restricted-project advisory) and CVE-2026-48749 (the rootfs-symlink advisory), CISA lists exploitation as poc. For CVE-2026-48755 (the backup advisory), CVE-2026-48752 (the templates-symlink advisory) and CVE-2026-48750 (the exec-output advisory), CISA lists exploitation as none.
Fix dates differ by advisory. GHSA-jpf8-86f3-wp38 lists a fix landing in canonical/lxd on 3 February 2026. GHSA-9j25-mm2h-2f76 lists 26 June 2026. The other four, GHSA-pjff-c2wc-f6jm, GHSA-47w9-6r3f-938g, GHSA-fmc8-p6q7-75cc and GHSA-vghh-5rfx-xhq8, list the same fix commit, dated 30 June 2026.
Two of the advisories name the LXD release that shipped the fix: LXD 5.0.7 LTS and LXD 5.21.5 LTS, both released on 1 July 2026. None of the six is in the CISA Known Exploited Vulnerabilities catalog, version 2026.11.06.
| Advisory | Pattern | Fix landed in canonical/lxd |
|---|---|---|
| GHSA-pjff-c2wc-f6jm | Remote image fingerprint trusted before the file write it names is checked | 30 June 2026 |
| GHSA-vghh-5rfx-xhq8 | Symlink in an image’s rootfs folder followed during unpack | 30 June 2026 |
| GHSA-jpf8-86f3-wp38 | Symlink in an image’s templates folder followed during unpack | 3 February 2026 |
| GHSA-9j25-mm2h-2f76 | Symlink in an image’s exec-output folder followed when output is recorded | 26 June 2026 |
| GHSA-47w9-6r3f-938g | Restricted project’s low-level block not re-applied to a restored snapshot | 30 June 2026 |
| GHSA-fmc8-p6q7-75cc | Backup compression setting only partly checked before it reaches the compressor | 30 June 2026 |
What to Check on Your LXD or Incus Hosts
Detecting a crafted image or snapshot from the host side alone is hard. The daemon’s own logs show the import or the restore step succeeding, the same as a normal one. The daemon believed the content was safe until the moment it acted on it.
That shifts the useful work earlier, to who is allowed to add an image source or push a snapshot in the first place. Each reporter is credited in the advisory itself, and GitHub lists the Incus maintainer as the coordinator for all six.
- Confirm your LXD build dateCheck whether your canonical/lxd deployment, container image or vendored copy predates the fix commits above, especially the 30 June 2026 batch.
- Move to a fixed LXD releaseLXD 5.0.7 LTS or 5.21.5 LTS or later carries the fixes GitHub names for those advisories, per the release pages.
- Review who can publish imagesThe four image-handling advisories all start with a crafted image or snapshot, so tighten who can add an image source or push a snapshot into your projects.
- Review restricted project settingsAfter upgrading, confirm a project’s low-level block still holds for every snapshot already stored, not only for new ones.
This pattern, a guest object that is trusted a little too early, also shows up in hypervisor escapes. See our page on the VMware ESXi sandbox escape, CVE-2025-22225. The restricted-project gap is a least privilege boundary that a snapshot’s own settings were able to cross.