util-linux CVE-2026-76642

Exploitation requires a local account (AV:L) on a Linux system running util-linux through 2.41.5 (2.41.x branch) or through 2.42.2 (2.42.x branch). The attacker must be able to invoke mount with a helper program that supports the X-mount.idmap or X-mount.owner extended mount options - these are non-default options that must be explicitly specified either in /etc/fstab or via mount command arguments accessible to the user. The mount invocation must target a pre-existing filesystem (the vulnerability does not apply to initial filesystem creation). The attacker must be able to cause the mount helper to return a non-zero exit code (failure) while the MOUNT_POST stage still executes. Exploitation cannot be triggered remotely and requires physical or shell-level local access; default Linux configurations that do not expose X-mount.idmap or X-mount.owner options to unprivileged users are not directly exploitable without first gaining the ability to influence mount options.

The CVSS 4.0 score of 8.5 (AV:L/AC:L/AT:N/PR:L/UI:N with VC:H/VI:H/VA:H) accurately characterizes a local privilege escalation requiring only a low-privilege account and no additional complexity or user interaction. There is no CISA KEV listing and no confirmed public exploit code, which reduces the immediate threat level compared to a remotely exploitable flaw of comparable severity. Nevertheless, util-linux's ubiquitous deployment across Linux distributions means the blast radius is exceptionally wide - even a mid-sized municipal IT team in swidnica should treat this as urgent once distribution-packaged fixed versions are available. The SSVC technical impact is effectively total given the potential to escalate to root via suid-bit inheritance or inode permission manipulation. The public GHSA advisory, two identified source-code reference lines in the vulnerable version, and three patch commits collectively provide enough detail for a skilled attacker to derive a working exploit, so POC code is a realistic near-term risk. EPSS data was not provided; given the local-only vector and moderate complexity of triggering a deliberately failing mount helper, opportunistic mass exploitation is unlikely, but targeted use against multi-tenant Linux environments (shared hosting, container orchestration nodes, HPC clusters) is plausible.

A local user with a standard shell account crafts a mount command targeting a pre-existing filesystem, specifying a mount helper that is designed or configured to return a non-zero (failure) exit status. Because libmount's mnt_context_do_mount() does not gate the MOUNT_POST hook stage on verified helper success, the X-mount.idmap hook executes with elevated privileges despite the failure, allowing the attacker to clone the filesystem with inherited setuid bits - which can then be used to spawn a root shell. No public exploit code has been identified at time of analysis, but the patch commits and advisory provide sufficient implementation detail for independent exploit construction.