Summary "POST /1.0/storage-pools/<pool>/volumes" with an "application/octet-stream" body (custom-volume ISO or backup import) uses an attacker-controlled name as an on-disk path segment without validation. A project user with the "can_create_storage_volumes" entitlement can supply "X-Incus-name: ../../../../<target>" (ISO) or an "index.yaml name: ../../../../<target>" (backup), causing the root Incus daemon to create directories, remove directory trees ("os.RemoveAll"), and (backup vector) unpack attacker content outside the storage pool. The "validate.IsAPIName" guard exists only on the JSON create branch and is never reached on the import branches. ## Root Cause In "storagePoolVolumesPost" ("cmd/incusd/storage_volumes.go:828-833"), octet-stream requests dispatch to "createStoragePoolVolumeFromISO(..., r.Header.Get("X-Incus-name"))" (":830") or "createStoragePoolVolumeFromBackup(...)" (":833") BEFORE the "validate.IsAPIName(req.Name)" at ":845" (which is only on the JSON branch). "createStoragePoolVolumeFromISO" (":2697") checks only "volName == """ (":2701"). The name flows to "pool.CreateCustomVolumeFromISO(projectName, volName, ...)" -> "project.StorageVolume(projectName, volName)" -> "GetVolume(...).MountPath()" -> "dir.CreateVolume" "EnsureMountPath" "os.Mkdir" + reverter "os.RemoveAll(volPath)". "VolumeDBCreate"/"validateVolume" validate config keys only, not the name (verified - no "ValidName"/"IsAPIName"/"filepath" check in either). ## Impact Root-owned arbitrary directory creation and directory-tree removal ("os.RemoveAll") at an attacker-chosen path (integrity/DoS). The backup import vector additionally unpacks tarball rootfs bytes, giving arbitrary-content file write as root -> host RCE. ## Proof of Concept ISO: "curl -X POST --data-binary @x.iso -H 'Content-Type: application/octet-stream' -H 'X-Incus-type: iso' -H 'X-Incus-name: ../../../../etc/cron.d/pwn' https://incus/1.0/storage-pools/default/volumes" (as a user with "can_create_storage_volumes"). ## Attack Chain 1. Entry: "POST /1.0/storage-pools/<pool>/volumes", "Content-Type: application/octet-stream", "X-Incus-type: iso", "X-Incus-name: ../../../../etc/cron.d/x" -> "createStoragePoolVolumeFromISO" ("storage_volumes.go:830"). Guard: "allowPermission(project, can_create_storage_volumes)". 2. Check: "if volName == """ (":2701") - rejects only empty. "validate.IsAPIName(req.Name)" (":845") is on the JSON branch, not reached. Bypass proof: "volName" passes with any value including the traversal string. 3. Sink: "pool.CreateCustomVolumeFromISO(projectName, volName, ...)" ("backend.go") -> "project.StorageVolume(proj, volName)" -> "GetVolume(...).MountPath()" -> "EnsureMountPath" "os.Mkdir" + reverter "os.RemoveAll(volPath)", as root. "VolumeDBCreate"->"validateVolume" validates config keys only (verified). 4. Impact: root arbitrary dir create + directory-tree removal at attacker path; backup vector adds arbitrary-content write (RCE). ## Bypass Evidence "validate.IsAPIName" present but on the wrong branch (":845", JSON only); import branches (":830"/":833") bypass it; downstream validation is config-only. "filepath.Join" collapse verified (same as the instance backup-import path). Forced ".iso" suffix constrains the final filename but still permits arbitrary-directory creation/removal via "..". ## Affected Versions "<= 7.2.0" (vulnerable code verified present on latest release tag v7.2.0 and on HEAD 60d85b3e; no fix commit on "cmd/incusd/storage_volumes.go" between v7.2.0 and HEAD). ## Suggested Fix Apply "validate.IsAPIName(volName, false)" to the "X-Incus-name" header and to "bInfo.Name"/each volume-snapshot name at handler entry, before any storage I/O. ## Credit Vulnerability independently discovered and responsibly disclosed by Zhixi "Jace" Sun (@manus-use).