cifs-utils CVE-2026-12505

Attacker must already have a local interactive or code-execution foothold as any unprivileged UID on the target host, with permission to call the request_key(2) syscall for the 'cifs' key type and to create a user or mount namespace (the default on modern unprivileged-userns-enabled kernels including RHEL 8+, OpenShift worker nodes, and most SUSE configurations). The cifs-utils package must be installed and /sbin/cifs.upcall must remain the configured upcall handler in /etc/request-key.conf - the default on any system supporting Kerberos-authenticated CIFS/SMB mounts. No user interaction, no network access, and no prior authentication to CIFS itself is required; exploitation does not depend on an existing SMB mount. Limiting factors: hosts that disable unprivileged user namespaces (kernel.unprivileged_userns_clone=0), strip the setuid bit from cifs.upcall, or do not install cifs-utils at all are not exploitable.

Signals converge on a credible but not urgent priority. The CVSS 3.1 vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (7.8) accurately reflects a local low-privilege LPE with full host compromise, and SSVC-style reasoning supports this: exploitation is automatable (a small, deterministic crafted request_key payload plus a prebuilt NSS module), and technical impact is total (root). However, no KEV listing, no EPSS data was provided, and no public exploit identified at time of analysis, so the realistic threat today is post-compromise escalation rather than mass exploitation. The risk is meaningfully higher on multi-tenant or shared-shell systems (developer hosts, jump boxes, OpenShift worker nodes with untrusted workloads that can call request_key) and lower on single-purpose servers where the attacker would already need a foothold. No conflicting signals were observed in the input.

A low-privileged shell user on a vulnerable RHEL host writes a malicious libnss_evil.so plus a custom nsswitch.conf into a directory they control, enters a new user/mount namespace, and issues a crafted request_key call that the kernel forwards to the root-owned cifs.upcall helper. The helper, still running as root, performs an NSS user lookup inside the attacker's environment, dlopen()s the malicious module, and executes the attacker's code as root. No public exploit identified at time of analysis, but the primitives (namespace creation, request_key, NSS shared-object injection) are well documented from prior Linux LPE research, making a working exploit straightforward to construct.