Incus CVE-2026-115378

Exploitation requires ALL of the following: (1) the attacker has root inside an Incus virtual machine and can run a modified incus-agent that serves inconsistent SFTP listings (the same entry name returned first as a symlink, then as a directory or regular file); and (2) an operator must run 'incus file pull -r' recursively from that specific compromised VM - this operator interaction is mandatory and is the primary limiting factor. The damage is bounded by the operator's privileges on the CLI host: run as root it can overwrite /etc/shadow or /root/.ssh/authorized_keys; run unprivileged into a dedicated directory the impact is contained. Containers are NOT affected because their transfers are served by forkfile on the host rather than an in-guest agent. Affected: Incus before 6.0.7, 6.1.0 before 7.0.2, and 7.1.0 before 7.5.0. Vendor workarounds: avoid recursive pulls from untrusted VMs, or run the pull as an unprivileged user into a dedicated directory; the complete fix is updating to a fixed version.

This is a genuine but conditional integrity threat rather than a mass-exploitation emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:P, VI:H/SI:H) scores 6.9 (medium): the high integrity impact on both the vulnerable system and the subsequent system (the operator's host) reflects that a successful attack escapes the VM boundary and writes attacker-controlled files like /etc/shadow or /root/.ssh/authorized_keys on the host, which can escalate to full host compromise. However, the AT:P (attack requirement) and UI:P (operator must act) metrics are decisive limiters: exploitation cannot proceed unless an operator voluntarily runs 'incus file pull -r' against a VM the attacker already controls at root. No EPSS score, KEV listing, or confirmed working exploit code is present in the input - only vendor/GHSA and VulnCheck advisory references, not a PoC. The vuln.today decision label is 'this_month', not act_now/emergency, consistent with a patch-available, high-impact-but-interaction-gated flaw. Net: prioritize patching for operators who pull files from untrusted guests, but this is not a drive-by, pre-auth, widespread-exploitation scenario. Note a signal nuance: PR:L here reflects that the attacker needs root inside the guest VM, not any privilege on the targeted incus CLI host - the trust boundary is the guest/host split, not an authentication check on the host.

An attacker who has gained root inside an Incus-managed virtual machine replaces incus-agent with a modified version that serves a malicious SFTP directory listing. When an operator later runs 'incus file pull -r' from that VM, the agent returns the same entry name twice - first as a symlink, then as a directory or file - causing the client to write through the symlink and land attacker-controlled content outside the target directory on the operator's host, with the operator's privileges. No public exploit code is identified in the input, though the mechanism is fully described in the GHSA advisory.