CIFSwitch CVE-2026-46243: The 19-Year-Old Linux Kernel Bug That Gives Any Local User Root in a Single Command
Eric Serrano Bustos
On 28 May 2026, security researcher Asim Manizada published full details and a PoC exploit for CIFSwitch (CVE-2026-46243) on the oss-security mailing list — a local privilege escalation (LPE) vulnerability in the Linux kernel’s CIFS module. The bug has been in the kernel code since 2007 — 19 years undetected. On affected systems, any unprivileged local user can obtain a root shell in a single command. The PoC is publicly available on GitHub. Patched kernels reached production repositories on 2 June. It is the fifth Linux kernel LPE in 2026, following Copy Fail, Dirty Frag, Fragnesia and ssh-keysign-pwn.
What do we know about CIFSwitch and CVE-2026-46243?
Facts documented by BleepingComputer, CybersecurityNews, TuxCare, CloudLinux, Threat-Modeling.com and Asim Manizada’s original advisory:
Vulnerability: local privilege escalation (LPE) in the SPNEGO upcall path of the Linux kernel’s CIFS module. The bug lives in fs/smb/client/cifs_spnego.c, the code that handles Kerberos/SPNEGO authentication for the Linux kernel CIFS client.
CVE assigned: CVE-2026-46243 (assigned 1 June 2026).
Age: the bug has been present in the Linux kernel since 2007 — 19 years.
Single-command exploitation: on affected systems, any unprivileged local user can obtain root with a single terminal command. No race condition required. No additional authentication required.
Public PoC: Manizada published the PoC exploit on GitHub on the same day as disclosure (28 May). The exploitation barrier is very low: the PoC is functional and documented.
Exploitability conditions: the vulnerability is not universal. Three conditions must coexist: (1) cifs-utils installed (versions 6.14+ primarily), (2) unprivileged user namespaces enabled (sysctl kernel.unprivileged_userns_clone=1), and (3) kernel CIFS module loaded. In many distributions these three elements coexist by default.
Affected distributions: multiple major Linux distributions including Red Hat, Ubuntu, Debian, SUSE, Oracle Linux and Amazon Linux, depending on configuration.
Patches available: the upstream kernel fix was merged into the stable branch. Patched kernels reached production repositories on 2 June 2026. Updates for Red Hat, Ubuntu, Debian, SUSE, Oracle and Amazon are rolling out.
Fifth LPE of 2026: CIFSwitch is the fifth Linux kernel LPE published in 2026, following Copy Fail (29 April), Dirty Frag (7 May), Fragnesia and ssh-keysign-pwn.
Why Linux corporate servers are a priority target for LPEs like CIFSwitch
A local privilege escalation vulnerability may appear less urgent than a remote RCE. That is a mistake. In the modern corporate infrastructure context, an LPE is frequently the second step of a two-phase attack already underway:
Local access is more common than it seems. An attacker already inside the corporate network — via employee phishing, VPN compromise, lateral movement from another system or container access in a multi-tenant environment — has local access to the Linux server. CIFSwitch converts that limited access into full system control.
CI/CD pipelines, GitHub Actions runners and development environments are especially vulnerable. In these environments, multiple users or processes with minimal privileges share the same Linux system. An LPE like CIFSwitch allows an unprivileged process (a CI job, a compromised container image, a build script) to escalate to root and compromise the entire host.
Multi-tenant cloud environments are the highest-risk scenario. On VPS, cloud hosts and shared servers where multiple tenants have user access to the same system, an LPE gives any tenant root over the entire host. The impact extends beyond the attacking tenant.
Root = complete system control. With root, the attacker can install persistent backdoors, access all system secrets (SSH keys, API tokens, database credentials), disable monitoring and logs, pivot to other network systems, and in container environments attempt a container escape.
How the attack works: from unprivileged user to root in one command
The attacker forges a cifs.spnego key description. Using the request_key(2) syscall, the attacker creates a cifs.spnego-type key with a specially crafted description containing attacker-controlled values for the pid, uid, creduid and upcall_target fields. The kernel does not validate that these values originate from a legitimate kernel request.
The kernel invokes cifs.upcall as root with the attacker’s values. The kernel CIFS module calls the privileged helper cifs.upcall (part of the cifs-utils package) passing the forged values. cifs.upcall trusts these values as if they came from the kernel.
The attacker manipulates namespaces. Using user namespace and mount namespace manipulation (possible because unprivileged user namespaces are enabled), the attacker creates a controlled environment in which cifs.upcall will execute within the attacker’s namespace.
cifs.upcall loads a malicious NSS library as root. Within the manipulated namespace, cifs.upcall performs a getpwuid() call before dropping privileges — forcing the system NSS resolver to load. The attacker has placed a malicious NSS library in their mount namespace. That library executes as root.
Root shell obtained. The arbitrary code in the malicious NSS library executes with root privileges, delivering full system control to the attacker.
Key lessons and mitigation checklist for Linux administrators
Step 1 — Verify exposure (immediate):
Check whether cifs-utils is installed: rpm -q cifs-utils (RHEL/CentOS/Amazon) or dpkg -l cifs-utils (Debian/Ubuntu).
Check whether unprivileged user namespaces are enabled: sysctl kernel.unprivileged_userns_clone (Debian/Ubuntu) or sysctl user.max_user_namespaces. A value > 0 means they are enabled.
Check whether the CIFS module is loaded: lsmod | grep cifs. If it returns results, the module is active.
Alternatively, run the automated verification script published on DEV Community (github.com/lromanis/cifswitch-checker) which validates all exposure factors and generates JSON output for SIEM ingestion.
Step 2 — Patching (priority action):
Red Hat / CentOS / Rocky / AlmaLinux:yum update kernel or dnf update kernel. Reboot required.
For environments that cannot reboot (critical production servers), KernelCare and TuxCare offer live rebootless patches for CIFSwitch: kcarectl --update.
Step 3 — Immediate mitigations without reboot (if patching cannot be applied today):
Disable unprivileged user namespaces:sysctl -w kernel.unprivileged_userns_clone=0 (Debian/Ubuntu) or sysctl -w user.max_user_namespaces=0 (RHEL/CentOS). This measure eliminates CIFSwitch’s exploitation vector but may affect containers using user namespaces.
Unload the CIFS module if not in use:rmmod cifs and add blacklist cifs to /etc/modprobe.d/blacklist.conf. Only applicable if the organisation does not mount CIFS/SMB resources on that server.
Remove cifs-utils if not needed:apt remove cifs-utils or yum remove cifs-utils. Without cifs-utils installed, the vulnerability is not exploitable.
Step 4 — Monitoring (multi-tenant and CI/CD environments):
Monitor request_key() calls with unusual cifs.spnego key descriptions via audit rules or kernel observability tools (eBPF, Falco).
In CI/CD environments, check whether runners have cifs-utils installed and user namespaces enabled. Self-hosted GitHub Actions runners on Linux are a specific risk vector.
Cybersecurity as a strategic priority
CIFSwitch is a reminder that the most dangerous vulnerabilities are not always the newest. A 19-year-old bug, present in the Linux kernel since 2007, has been available to any attacker with local access for nearly two decades. The fact that it went undetected for so long is not an anomaly: it is the pattern. The Verizon 2026 DBIR, which we analysed last week, confirmed that organisations take a median of 43 days to patch critical vulnerabilities — more than enough time for an attacker with local access to exploit CIFSwitch. For any organisation with Linux infrastructure — on-premises servers, cloud instances, CI/CD pipelines or development environments — today’s question is direct: is the kernel updated to the version that includes the CVE-2026-46243 patch?
Apolo Cybersecurity: vulnerability management and Linux infrastructure hardening
At Apolo Cybersecurity we help organisations assess and mitigate their exposure to LPE vulnerabilities like CIFSwitch in Linux infrastructure: exposure verification across Linux corporate fleets, rebootless mitigation implementation for critical production environments, user namespace and kernel module configuration hardening, CI/CD environment and Linux runner security auditing, and privilege escalation activity monitoring via eBPF and Falco.
If your organisation has Linux servers with cifs-utils installed and user namespaces enabled and has not applied the CVE-2026-46243 patch, this Thursday morning is the time to verify it.
%402x.svg){kind=icon}
