When a container is checkpointed and restored with CRIU, runc registers every bind mount (and every device) of the container configuration with CRIU as an external mount, using the mount destination resolved inside the container's own rootfs as the lookup key. CRIU encodes each external mount as the single string "mnt[KEY]:VAL" and looks entries up by prefix, so a key that contains "]:" terminates early and shifts the boundary between the key and the value. A malicious image can therefore place "]:" in a symlink target in its rootfs and make "runc restore", running as host root, bind-mount a host path that the configuration never named into the restored container, read-write. This is the same issue as CVE-2026-115520 ("GHSA-2mxx-58qc-p466)" (https://github.com/containers/crun/security/advisories/GHSA-2mxx-58qc-p466) in crun. Affected since runc 1.1.0, which added the symlink resolution of mount destinations for checkpoint/restore (commit 74ae9e0f, "checkpoint: resolve symlink for external bind mount"). Exploitation requires an operator who runs "runc checkpoint" followed by "runc restore" on the container (directly, or via a container engine such as containerd, CRI-O or Podman). Since CRIU requires root, so do runc checkpoint and restore.