A vulnerability in the Linux kernel’s CIFS filesystem subsystem — present in the codebase for approximately 19 years — allows an unprivileged local user to escalate privileges to root through a single exploit sequence involving a forged kernel upcall key. CVE-2026-46243, disclosed on the oss-security mailing list on 28 May, received a CVE identifier on 1 June as patched kernel versions began reaching distribution repositories. By 3 June, security advisories had been issued by Red Hat (RHSB-2026-005), AlmaLinux, Rocky Linux, and CloudLinux.
A public proof-of-concept demonstrating the single-command root exploit is available, making this a priority patch for any Linux environment where multiple users have local shell access.
Vulnerability Details
The flaw resides in how the kernel’s CIFS client (cifs-utils) handles kernel upcall keys — an in-kernel IPC mechanism used when the filesystem needs to communicate authentication requests to userspace (for NTLM authentication, Kerberos tickets, or SMB signing material). A design flaw in the upcall key validation allows an unprivileged user to craft a forged upcall key that the kernel accepts as authoritative, then use that key to execute arbitrary code in a privileged context.
The exploit path requires:
- A local unprivileged user account (no specific permissions beyond login shell)
- The
cifs.upcallhelper present (standard withcifs-utilspackage) - No CIFS/SMB mounts need to be active — the upcall subsystem is present once
cifs-utilsis installed
The 19-year latency of this flaw reflects the obscurity of the kernel upcall key mechanism — a code path that handles authentication for CIFS filesystem mounts, reviewed less frequently than core network or memory subsystem code.
Affected Versions and Patched Releases
The vulnerability affects all kernel versions that include the CIFS upcall subsystem:
| Kernel branch | Last vulnerable | Patched version |
|---|---|---|
| 7.0.x | 7.0.10 | 7.0.11 |
| 6.18.x | 6.18.33 | 6.18.34 |
| 6.12.x (LTS) | 6.12.91 | 6.12.92 |
| 6.6.x (LTS) | 6.6.141 | 6.6.142 |
Red Hat Enterprise Linux 8 and 9, AlmaLinux 8 and 9, Rocky Linux 8 and 9, and CloudLinux 8 all have errata available as of 3 June. Ubuntu and Debian kernel updates are expected within 24–48 hours.
Why This Matters
Local privilege escalation vulnerabilities are often underestimated in enterprise Linux environments because they require existing local shell access. In practice, this assumption is frequently wrong:
- Container escapes: A container breakout vulnerability combined with CVE-2026-46243 produces a full host root chain. Kubernetes nodes, container hosts, and CI/CD runner environments are vulnerable to this two-step escalation.
- Post-phishing escalation: An attacker who has initial access via a phished developer or operator account can use this flaw to move from unprivileged shell to root immediately.
- Shared hosting and VPS environments: Multi-tenant Linux environments (development servers, jump hosts, shared build systems) where multiple users have shell access are directly exploitable.
- Exploit chains: Security researchers have confirmed the public PoC completes root escalation in under 10 seconds on unpatched systems. This is now a reliable component in post-exploitation toolkits.
Recommended Actions
- Apply distribution kernel updates immediately: For RHEL, AlmaLinux, Rocky Linux, and CloudLinux, apply the RHSB-2026-005 errata. For other distributions, apply available kernel updates as they land (Ubuntu, Debian, SUSE advisories expected 3–5 June).
- Where immediate patching is not possible: Remove or disable the
cifs.upcallhelper (chmod 000 /usr/sbin/cifs.upcall) as a temporary mitigation. This disables Kerberos and NTLM authentication for CIFS mounts but prevents exploitation of the upcall key path. - Audit
cifs-utilsinstallation: On servers and workstations where CIFS filesystem mounts are not used, removecifs-utilsentirely — the attack surface is eliminated without functional impact. - Prioritise multi-user and container hosts: Patch jump hosts, development servers, build systems, and container worker nodes first — these environments have the highest density of local accounts with shell access.
- Check for active exploitation: Review
/var/log/auth.logand audit logs for unexpectedrootuid transitions from unprivileged accounts since 28 May (the PoC publication date).
Share this article