When copying an Incus instance across projects, the permission check validates against the incoming request's initial state before the source instance's configuration merges into the target. That sequence is the vulnerability: dangerous configuration keys — particularly privileged=true — exist in the source instance but aren't present in the request at check time. Once the authorization gate passes, the source instance's config injects those keys into the target project, bypassing the restrictions that should have governed them.
This isn't a classic TOCTOU bug where an external actor modifies state between check and use. The data flows exactly as the system designed it. The failure is architectural: the permission model assumed that any configuration already existing in the system is safe to merge without re-validation. That assumption held when instances stayed within their originating project — the config was already authorized by that project's restrictions. Cross-project copy breaks that model by combining data from two different security contexts without asking whether the merged result is valid in the target context.
Check your Incus deployment: if you're running any version before 7.3.0 and have multiple projects with instance-copy operations between them, you're exposed. The fix re-orders the validation to run after configuration merging, ensuring the target project's restrictions apply to the final merged state. But verify your specific version — the remediation depends on the patch addressing this exact sequence.
The deeper concern is whether similar patterns exist in other cross-entity operations. Snapshot restore, instance migration, and backup restore all involve merging configuration from a source into a target context. If the same "validate-then-merge" pattern lives in any of those paths, the same bypass applies. Audit your cross-project operations holistically — patching one copy path doesn't protect the others if the underlying assumption about trusted configuration remains unchanged.
In multi-tenant Incus deployments, this isn't theoretical. A malicious operator with instance-copy permissions across projects can escape container containment entirely, gaining host access. The CVSS score reflects that severity. Prioritize patching, then audit your permission model for cross-boundary operations that may carry the same assumption.