CVE-2026-48751 exposes a temporal asymmetry in Incus's security model that matters more than its 9.9 CVSS score suggests. The vulnerability: when restricted.containers.lowlevel=block is enforced, a user with snapshot creation privileges can embed attack payloads in raw.lxc or raw.qemu configuration within a snapshot—even though that same user cannot inject those same settings into a running instance. The snapshot extraction path was never modeled as a security boundary, making it a permanent escape vector for any restricted configuration.
The patch in 7.2.0 targets snapshots specifically, but the critical question is enforcement timing. If the fix applies the restriction only at snapshot creation time, every pre-7.2.0 snapshot in your storage is a potential payload carrier—those artifacts contain lowlevel hook configurations that bypassed the restriction at creation and will continue to do so on restore. If the fix also enforces at restore time, the patch is semantically incomplete but functionally more robust. You cannot determine which approach Incus took without examining the restore code path directly.
This is not an isolated flaw. The same extraction-bypass pattern appears in LXC, Docker, and Podman across different configuration vectors. The root cause is architectural: security policies are designed as lifecycle properties of running instances, while snapshot operations are treated as data extractions. Until Incus treats snapshot creation and restore as security transitions—both enforcing the active restriction policy—the gap will persist across other restricted.* settings (storage backends, network configs, profile inheritance).
Realistic exposure: exploiting this requires snapshot creation privileges, which already implies significant operational trust. However, the privilege boundary inversion is the actual vulnerability—a restricted user who can create snapshots has already extracted themselves from their security context through the snapshot API. The CVSS scores the capability gap, not the median exploit path.
Action items: audit existing snapshots for pre-7.2.0 creation dates and treat them as untrusted artifacts until proven sanitized. Review whether your authorization model intentionally grants snapshot creation to users you intend to restrict. Assume other restricted.* settings are vulnerable to the same extraction bypass until Incus explicitly audits snapshot paths for all security policies.