DEV Community

StarkMan
StarkMan

Posted on

Choosing Between rsync and btrfs receive in LXD: Exposure Differences Under CVE-2026-87799

#security #vulnerability #lxd #cve202687799

Choosing Between rsync and btrfs receive in LXD: Exposure Differences Under CVE-2026-87799

Storage design is security design

Two LXD operators can run the same release, apply the same patch cadence, and carry different risk from CVE-2026-87799. The variable is how they move workloads and which storage driver they chose.
The advisory is explicit on one point: optimized ZFS transfers are not affected. That single sentence splits the population.

The affected replay paths

When LXD receives an instance or custom volume through migration, it hands the stream to an external tool. The default is rsync. On hosts using the btrfs driver, LXD can instead use btrfs receive to replay an optimized send stream.
Neither tool refuses to traverse a symlink planted earlier in the same stream. A malicious source places the symlink first, then references paths beneath it, and the later writes land outside the destination volume with host privileges.
rsync and btrfs receive are behaving as documented. The assumption that needs scrutiny is that a stream from an untrusted peer is safe to replay with host privileges and without path containment checks.

Where driver choice changes the answer

  • Optimized ZFS send and receive: not affected for the symlink primitive.
  • Default rsync-based migration: affected on LXD 4.0 and later.
  • btrfs receive of an optimized stream: affected, and additionally carrying the btrfs-specific siblings CVE-2026-85185 and CVE-2026-85526. An operator on btrfs therefore faces three entries in the same patch cycle, while an operator limiting transfers to optimized ZFS avoids one of them. A host that mixes both, which is normal in growing fleets, inherits the union.

Why the difference is easy to miss

The transfer path is invisible from the volume listing. It is determined by the storage pool driver, the source pool type, and the flags used at the time of the move. Documentation tends to describe the convenient path, which is the optimized one.
An inventory built on "LXD 4.0 and later" will therefore overstate risk on ZFS-optimized paths and understate it wherever btrfs backups are imported outside the migration flow, because CVE-2026-85526 reaches the same field through backup restore rather than migration.

Exposure evidence and its limits

A ZoomEye search for app="LXD" matches 12,153 assets as of 29 September 2026. Fingerprint matching cannot see which storage driver an asset uses, so it cannot separate the rsync, btrfs and ZFS-optimized populations described above.

Applying the fix

Upgrade to LXD 4.0.14, 5.0.10, 5.21.8, 6.10, or the fixed 6.9 build at commit bf243da, and review the per-CVE advisories on GitHub.
While patching rolls out, the vendor's controls are worth copying into runbooks exactly as written: allow only trusted users to create instances and custom storage volumes, migrate only from servers you trust, do not import btrfs optimized backups from untrusted sources, and block backup import for non-admin project members in multi-tenant projects.

Practical takeaway

Record the storage driver and transfer mode for every LXD host alongside its version. Without that pairing, a patch-compliance report cannot tell an unaffected ZFS-optimized host from an exposed btrfs one.

References

Top comments (0)