LXD Backup Import as an Attack Surface: CVE-2026-87799 and the btrfs Restore Path

An underrated entry point

Migration gets the attention because it moves live workloads between hosts. Backup import moves the same kinds of bytes and is often treated as an administrative routine. In this advisory cycle it carries a matching fix.
CVE-2026-87799 itself is the migration-side symlink flaw. CVE-2026-85526 is the restore-side traversal, and both target LXD's willingness to replay an untrusted stream with host privileges.

The two mechanisms

On the migration path, LXD hands the received stream to rsync or to btrfs receive. Neither refuses to traverse a symlink planted earlier in the stream, so later entries are written through the link, as root, outside the destination volume.
On the restore path, the btrfs storage driver consumes a subvolume path field from attacker-supplied backup headers. Restoring an optimized backup tarball onto a btrfs pool therefore lets any authenticated user with permission to create instances craft a tarball whose stored path escapes the volume. The advisory describes the outcome in multi-tenant projects as effectively a host-level filesystem compromise.
A third entry, CVE-2026-85185, targets the same field through a different operation, joining the header path to the pool mount point without a containment check.

Severity and status

CVE-2026-87799 and CVE-2026-85526 are both rated 9.9 under CVSSv3, tracked as CWE-59 and CWE-22 respectively. CVE-2026-85185 is 9.6 and CWE-22. None has been observed in the wild; a public proof of concept exists for the symlink issue.

Affected versions

CVE-2026-87799 affects LXD 4.0 and later. The btrfs flaws affect LXD 4.0.2 and later. Fixed releases are 4.0.14, 5.0.10, 5.21.8 and 6.10, with a 6.9 build at commit bf243da. Optimized ZFS transfers are not affected by the symlink flaw.

Exposure context

A ZoomEye search for app="LXD" matches 12,153 assets as of 29 September 2026. This counts observable assets matching the product fingerprint; it cannot distinguish hosts that accept backup import from those that do not.

Hardening the import path

Patch to a fixed release. Then restrict the import path:

• Permit instance and custom volume creation only for trusted identities.
• Accept migration only from servers the operator controls.
• Never import btrfs optimized backups from untrusted sources.
• In multi-tenant projects, block backup import for non-admin project members until every host is upgraded. The last control matters most. Backup import is frequently granted broadly because it is useful, and it is the capability that makes the restore-side primitives reachable.

Where to look after patching

If a host imported an optimized backup from an untrusted source before it was fixed, treat pre-patch integrity as unproven. The advisory's guidance for the btrfs issues is to preserve relevant logging and a memory dump before applying the update, since the patch prevents new abuse but does not exclude earlier abuse.

References

• SecurityOnline, "Critical LXD Vulnerabilities Let Container Users Write Files as Root on the Host": https://securityonline.info/lxd-vulnerabilities-host-root/
• Official LXD security advisories on GitHub (btrfs restore and subvolume-path fixes)