When an external mount.<type> helper executes but exits nonzero, libmount records the helper's failure in helper_status yet returns success from exec_helper() in context_mount.c. mnt_context_do_mount() then runs privileged MNT_STAGE_MOUNT_POST hooks as if the helper had mounted the requested filesystem. With an /etc/fstab entry usable by an unprivileged user that specifies X-mount.idmap, the idmap post-hook clones the pre-existing filesystem under the target (inheriting suid,exec from the underlying mount because helper-path VFS-flag application is skipped), enabling a local unprivileged user to obtain EUID 0. Independently, X-mount.owner/group/mode post-hooks can change ownership and mode of the physical target inode even when no mount was created. Exploitation requires SUID-root mount(8), a root-controlled fstab entry with the user option plus X-mount.idmap or X-mount.owner/group/mode, and an external helper that exits nonzero; the helper need not be malicious. This is distinct from CVE-2026-53612 (TOCTOU in hook_owner.c): there is no race or path substitution. Affects util-linux v2.39 through current master (dynamically confirmed on 2.41-5, 2.42.2-2, and 0f119878). No upstream fix as of 2026-08-24. Reported upstream by 4drez and S0S4. GHSA-m25x-3hj9-m26f.