Advisory · CVE-2026-115377
Incus migration streams can plant symlinks that write host files as root
Incus before 6.0.7, 6.1.0 before 7.0.2 and 7.1.0 before 7.5.0 replays instance and volume migration streams with rsync or btrfs receive, which follow symlinks planted in the stream, so a malicious migration source can write attacker-controlled files to arbitrary host paths as root. CVSS 3.1 9.9.
- Vendor
- Linux Containers
- Product
- Incus
- Identifier / CWE
- CVE-2026-115377
CWE-59 - Action timing
- Immediate
Explain it like I’m five
When Incus receives a copied workload it unpacks the delivery with tools that follow shortcuts hidden inside it. A shortcut planted early in the delivery can point at the host itself, so the rest of the delivery gets written onto the host as root.
- 01Malicious source starts a migration
A client allowed to create an instance or custom volume, or a server a target is told to copy or move from, offers a crafted migration stream.
- 02Stream plants a symlink
The stream plants a symlink such as rootfs pointing at the host root inside the transferred volume.
- 03Receiver follows the link
Per the Incus advisory, rsync and btrfs receive replay the stream with regular path-based calls and follow symlinks in the paths they write to, and the symlink check added in Incus 7.3 runs only after the transfer.
- 04Host files are written as root
Later entries in the same or following streams are written through the symlink, placing attacker-controlled files at arbitrary paths on the target host as root.
What happened
The Incus project disclosed CVE-2026-115377 in its GitHub security advisory: when receiving an instance or custom storage volume through migration (copy, move, refresh, push or pull), Incus hands the incoming data stream to rsync, or to btrfs receive for optimized transfers between btrfs pools. Both tools replay the stream on the host using regular path-based system calls and follow symlinks in the paths they write to, so a malicious migration source can plant a symlink, such as rootfs pointing to the host root, and have later entries written through it. The CVE record lists Incus before 6.0.7, 6.1.0 before 7.0.2 and 7.1.0 before 7.5.0 as affected. The CVSS 3.1 score is 9.9, with changed scope.
Per the advisory, any client allowed to create an instance or custom volume in a project, or any server a target is told to copy or move from, can write attacker-controlled files to arbitrary paths on the target host as root, leading to full host compromise; for virtual machines the same technique can replace the root block file with a symlink before the block stream is written through it. All storage drivers receiving through rsync are affected, as is the optimized btrfs path; optimized ZFS transfers are not affected. Releases before 7.3.0 are additionally affected by a rootfs symlink surviving the transfer, which the file API then follows when entering the container, allowing host files to be read as well as written. The CVE record lists 6.0.7, 7.0.2 and 7.5.0 as the fixed releases. As a workaround, Incus advises only allowing trusted clients to create instances and custom volumes, and only migrating from trusted servers.
What to do
- Inventory Incus hosts and clusters and note the version of each daemon, including hosts that receive copies or migrations from other servers.
- Upgrade affected installations to Incus 6.0.7, 7.0.2 or 7.5.0 or later for the branch in use, using the Incus project release guidance.
- Until every host is upgraded, only migrate from trusted servers and restrict instance and custom volume creation to trusted clients, as the Incus advisory advises.
- Audit recent migrations, copies and refreshes received from less-trusted sources, and inspect received volumes for symlinks pointing outside the volume, especially a rootfs symlink.
- Check target hosts for unexpected files written outside the storage pools, and verify the deployed version on every host after updating.
Management note
Migration is a trust decision that this flaw makes literal: receiving a workload from an untrusted server can hand that server root-level file write on yours. Patch receiving hosts first and treat past migrations from outside your trust boundary as an investigation trigger.