DEV Community

OnaEiuspkz
OnaEiuspkz

Posted on

Reading the Three LXD Advisories Together: CVE-2026-87799 and Its btrfs Siblings

#security #vulnerability #lxd #cve202687799

Reading the Three LXD Advisories Together: CVE-2026-87799 and Its btrfs Siblings

Three flaws, one theme

Canonical patched three critical LXD vulnerabilities in one cycle. They are separately tracked, separately scored, and not interchangeable, yet they describe the same underlying disagreement: who is responsible for validating a path that arrives from an untrusted peer.
| CVE | CVSS (v3) | CWE | Mechanism | Fixed in |
| --- | --- | --- | --- | --- |
| CVE-2026-87799 | 9.9 | CWE-59 | Symlink followed during migration stream replay | 4.0.14, 5.0.10, 5.21.8, 6.10 |
| CVE-2026-85526 | 9.9 | CWE-22 | Path traversal when restoring a btrfs optimized backup tarball | 4.0.14, 5.0.10, 5.21.8, 6.10 |
| CVE-2026-85185 | 9.6 | CWE-22 | Unvalidated btrfs subvolume path from backup or migration headers | 4.0.14, 5.0.10, 5.21.8, 6.10 |
None of the three has been observed in the wild. A public proof of concept for CVE-2026-87799 has been confirmed.

CVE-2026-87799 in detail

This is the link-following case, and it is the one that does not depend on the btrfs driver. LXD hands a received migration stream to rsync or to btrfs receive. Both replay the stream with path-based system calls and neither refuses to traverse a symlink planted earlier in the same stream. Later entries are then written through the link, as root, outside the destination volume.
For virtual machines the same primitive can redirect the root disk image. For containers it produces arbitrary root-owned file writes on the host.

The btrfs pair

CVE-2026-85526 reaches the same field through restore of an optimized backup tarball. Any authenticated user permitted to create instances can craft a tarball whose stored path escapes the volume. The advisory describes the result in multi-tenant projects as effectively a host-level filesystem compromise.
CVE-2026-85185 is the narrower, subtler case: the btrfs storage driver reads a subvolume path from attacker-supplied backup or migration headers and joins it to the pool mount point without a containment check. Escaping paths then reach file removal and rename operations that run as root. The advisory is explicit that this is a distinct sink from the earlier fixes for CVE-2026-66897 and CVE-2026-66898, which matters for anyone who assumed the older patch closed the class.

What the grouping implies

First, affected-version ranges differ. CVE-2026-87799 affects LXD 4.0 and later; the btrfs flaws affect 4.0.2 and later. An inventory based on a single "LXD 4.0+" rule will misclassify some hosts.
Second, exposure is driver-dependent. Optimized ZFS transfers are not affected by the symlink flaw, and btrfs-specific paths do not apply to ZFS pools. Two fleets on the same release can carry materially different risk.
Third, the mitigations overlap but are not identical. All three are addressed by restricting who may create instances and volumes, and by refusing untrusted migration sources. The btrfs issues add a specific instruction: do not import btrfs optimized backups from untrusted sources, and block backup import for non-admin project members in multi-tenant projects.

Verified exposure

A ZoomEye fingerprint search for app="LXD" returns 12,153 matching assets as of 29 September 2026. This is product exposure evidence: it counts observable assets that match the LXD fingerprint. It does not establish that any of them are vulnerable, unpatched, or reachable on a migration endpoint.

Recommended reading order for responders

Patch to 4.0.14, 5.0.10, 5.21.8, 6.10 or the fixed 6.9 commit. Then work backwards through the three entries in the table above, confirming for each host whether it ever accepted a migration or an optimized backup from a source outside the operator's control, and whether its pool driver made the btrfs-specific paths reachable.

References

Top comments (0)