CVE-2026-62867 is a command injection vulnerability in Incus's storage volume configuration where a project-scoped user can achieve root-level command execution. The critical vulnerability isn't the injection mechanism itself—it's that project-scoped users can reach root execution contexts at all. Incus defines project-scoped users as a distinct trust tier below full administrators, but the storage volume configuration handler operates in a context where that distinction collapses. The developer likely reasoned: this user is already authenticated within a project, so the configuration options are trusted input. That reasoning produced the vulnerability.
This exemplifies a recurring pattern where conceptual security boundaries (project isolation) and implementation reality (root execution context) diverge. When user-provided configuration flows through to command-line construction without validation, you have a design smell—not an individual mistake, but a friction point in tooling that pushes developers toward dangerous patterns. The fix being a version bump to 7.3.0 rather than a configuration change confirms this required code-level surgery: the original implementation passed options through without any validation layer.
If you're defending Incus deployments, the priority is upgrading to 7.3.0 immediately—this is a 9.9 CVSS for good reason. Beyond patching, audit adjacent storage, network, and instance creation handlers for the same pattern: project-scoped input reaching any code path that could bubble to shell invocation. The privilege model assumption ('project-scoped = untrusted') was apparently embedded in institutional memory but not enforced in code review. Consider adding explicit validation at every privilege boundary where project-scoped input touches privileged execution contexts—this class of vulnerability isn't unique to Incus, and future CVEs will likely surface in similar projects making the same architectural choices.