CIFSwitch CVE-2026-46243: el bug de 19 años en el kernel Linux que da root a cualquier usuario local con un solo comando
Eric Serrano Bustos
El 28 de mayo de 2026, el investigador de seguridad Asim Manizada publicó en la lista de correo oss-security el detalle completo y el exploit PoC de CIFSwitch (CVE-2026-46243), una vulnerabilidad de escalada de privilegios locales (LPE) en el módulo CIFS del kernel Linux. El bug lleva en el código del kernel desde 2007 — 19 años sin ser detectado. En sistemas afectados, cualquier usuario local sin privilegios puede obtener una shell root con un único comando. El PoC está disponible públicamente en GitHub. Los kernels parcheados llegaron a los repositorios de producción el 2 de junio. Es la quinta vulnerabilidad LPE en el kernel Linux en 2026, siguiendo a Copy Fail, Dirty Frag, Fragnesia y ssh-keysign-pwn.
¿Qué se sabe de CIFSwitch y CVE-2026-46243?
Los hechos documentados por BleepingComputer, CybersecurityNews, TuxCare, CloudLinux, Threat-Modeling.com y el advisory original de Asim Manizada son los siguientes:
Vulnerabilidad: escalada de privilegios locales (LPE) en el path de upcall SPNEGO del módulo CIFS del kernel Linux. El bug vive en fs/smb/client/cifs_spnego.c, el código que gestiona la autenticación Kerberos/SPNEGO para el cliente CIFS del kernel.
CVE asignado: CVE-2026-46243 (asignado el 1 de junio de 2026).
Antigedad: el bug ha estado presente en el kernel Linux desde 2007 — 19 años.
Explotación en un solo comando: en sistemas afectados, cualquier usuario local sin privilegios puede obtener root con un único comando de terminal. No se requiere race condition. No se requiere autenticación adicional.
PoC público: Manizada publicó el exploit PoC en GitHub el mismo día de la divulgación (28 mayo). La barrera de explotación es muy baja: el PoC es funcional y documentado.
Condiciones de explotabilidad: la vulnerabilidad no es universal. Para ser explotable se requieren tres condiciones simultáneas: (1) cifs-utils instalado (versiones 6.14+ principalmente), (2) user namespaces sin privilegios habilitados (sysctl kernel.unprivileged_userns_clone=1), y (3) módulo CIFS del kernel cargado. En muchas distribuciones por defecto estos tres elementos coexisten.
Distribuciones afectadas: múltiples distribuciones Linux mayores incluyendo Red Hat, Ubuntu, Debian, SUSE, Oracle Linux y Amazon Linux, dependiendo de la configuración.
Parches disponibles: el fix upstream del kernel fue mergeado en la rama estable. Los kernels parcheados llegaron a los repositorios de producción el 2 de junio de 2026. Las actualizaciones para Red Hat, Ubuntu, Debian, SUSE, Oracle y Amazon están distribuyéndose.
Quinta LPE de 2026: CIFSwitch es la quinta vulnerabilidad LPE en el kernel Linux publicada en 2026, tras Copy Fail (29 abril), Dirty Frag (7 mayo), Fragnesia y ssh-keysign-pwn.
Por qué los servidores Linux corporativos son objetivo prioritario de LPEs como CIFSwitch
Una vulnerabilidad de escalada de privilegios locales puede parecer de menor urgencia que un RCE remoto. Es un error. En el contexto de la infraestructura corporativa moderna, una LPE es con frecuencia el segundo paso de un ataque en dos fases que ya ha comenzado:
El acceso local es más común de lo que parece. Un atacante que ya está dentro de la red corporativa — via phishing de empleado, compromiso de VPN, movimiento lateral desde otro sistema o acceso a un contenedor en un entorno multi-tenant — tiene acceso local al servidor Linux. CIFSwitch convierte ese acceso limitado en control total del sistema.
Los pipelines de CI/CD, los runners de GitHub Actions y los entornos de desarrollo son especialmente vulnerables. En estos entornos, múltiples usuarios o procesos con privilegios mínimos comparten el mismo sistema Linux. Una LPE como CIFSwitch permite a un proceso no privilegiado (un job de CI, una imagen de contenedor comprometida, un script de build) escalar a root y comprometer todo el host.
Los entornos multi-tenant cloud son el escenario de mayor riesgo. En VPS, cloud hosts y servidores compartidos donde múltiples tenants tienen acceso de usuario al mismo sistema, una LPE da a cualquier tenant root sobre el host completo. El impacto va más allá del tenant atacante.
Root = control completo del sistema. Con root, el atacante puede instalar backdoors persistentes, acceder a todos los secretos del sistema (claves SSH, tokens de API, credenciales de base de datos), deshabilitar la monitorización y logs, pivotar hacia otros sistemas de la red, y en entornos de contenedores intentar un container escape.
Cómo funciona el ataque: del usuario sin privilegios a root en un comando
La cadena de explotación de CIFSwitch, documentada en el write-up técnico de Asim Manizada y en el análisis de TuxCare y CloudLinux, sigue estos pasos:
El atacante falsifica una descripción de clave cifs.spnego. Usando el syscall request_key(2), el atacante crea una clave de tipo cifs.spnego con una descripción especialmente construida que contiene valores controlados por el atacante para los campos pid, uid, creduid y upcall_target. El kernel no valida que estos valores procedan de una solicitud legítima del propio kernel.
El kernel invoca cifs.upcall como root con los valores del atacante. El módulo CIFS del kernel llama al helper privilegiado cifs.upcall (parte del paquete cifs-utils) pasiándole los valores falsificados. cifs.upcall confía en estos valores como si procedieran del kernel.
El atacante manipula los namespaces. Usando user namespace y mount namespace manipulation (posible porque los user namespaces sin privilegios están habilitados), el atacante crea un entorno controlado en el que cifs.upcall ejecutará con el namespace del atacante.
cifs.upcall carga una librería NSS maliciosa como root. Dentro del namespace manipulado, cifs.upcall realiza una llamada getpwuid() antes de soltar privilegios — lo que fuerza la carga del resolvedor NSS del sistema. El atacante ha colocado una librería NSS maliciosa en su mount namespace. Esa librería se ejecuta como root.
Shell root obtenida. El código arbitrario de la librería NSS maliciosa se ejecuta con privilegios de root, entregando al atacante control total del sistema.
Lecciones clave y checklist de mitigación para administradores Linux
Paso 1 — Verificar exposición (inmediato):
Comprobar si cifs-utils está instalado: rpm -q cifs-utils (RHEL/CentOS/Amazon) o dpkg -l cifs-utils (Debian/Ubuntu).
Comprobar si los user namespaces sin privilegios están habilitados: sysctl kernel.unprivileged_userns_clone (Debian/Ubuntu) o sysctl user.max_user_namespaces. Un valor > 0 indica que están habilitados.
Comprobar si el módulo CIFS está cargado: lsmod | grep cifs. Si devuelve resultados, el módulo está activo.
Alternativamente, ejecutar el script de verificación automatizado publicado en DEV Community (github.com/lromanis/cifswitch-checker) que valida todos los factores de exposición y genera salida JSON para ingestión en SIEM.
Paso 2 — Parcheo (acción prioritaria):
Red Hat / CentOS / Rocky / AlmaLinux:yum update kernel o dnf update kernel. Reinicio requerido.
Para entornos que no pueden reiniciar (servidores de producción críticos), KernelCare y TuxCare ofrecen parches en vivo sin reboot para CIFSwitch: kcarectl --update.
Paso 3 — Mitigaciones inmediatas sin reinicio (si el parche no puede aplicarse hoy):
Deshabilitar user namespaces sin privilegios:sysctl -w kernel.unprivileged_userns_clone=0 (Debian/Ubuntu) o sysctl -w user.max_user_namespaces=0 (RHEL/CentOS). Esta medida elimina el vector de explotación de CIFSwitch pero puede afectar a contenedores que usen user namespaces.
Descargar el módulo CIFS si no se usa:rmmod cifs y añadir blacklist cifs a /etc/modprobe.d/blacklist.conf. Solo aplicable si la organización no monta recursos CIFS/SMB en ese servidor.
Eliminar cifs-utils si no es necesario:apt remove cifs-utils o yum remove cifs-utils. Sin cifs-utils instalado, la vulnerabilidad no es explotable.
Paso 4 — Monitorización (entornos multi-tenant y CI/CD):
Monitorizar llamadas request_key() con descripciones de clave cifs.spnego inusuales mediante audit rules o herramientas de observabilidad del kernel (eBPF, Falco).
En entornos de CI/CD, revisar si los runners tienen cifs-utils instalado y user namespaces habilitados. Los runners de GitHub Actions self-hosted en Linux son un vector de riesgo específico.
La ciberseguridad como prioridad estratégica
CIFSwitch es el recordatorio de que las vulnerabilidades más peligrosas no siempre son las más nuevas. Un bug de 19 años, present en el kernel Linux desde 2007, ha estado disponible para cualquier atacante con acceso local durante casi dos décadas. El hecho de que permaneciera sin detectar durante tanto tiempo no es una anomalía: es el patrón. El Verizon DBIR 2026, que analizamos la semana pasada, confirmó que las organizaciones tardan una media de 43 días en parchear vulnerabilidades críticas — tiempo más que suficiente para que un atacante con acceso local explote CIFSwitch. Para cualquier organización con infraestructura Linux — servidores on-premise, instancias cloud, pipelines de CI/CD o entornos de desarrollo —, la pregunta de hoy es directa: ¿está el kernel actualizado a la versión que incluye el parche de CVE-2026-46243?
Apolo Cybersecurity: gestión de vulnerabilidades y hardening de infraestructura Linux
En Apolo Cybersecurity ayudamos a organizaciones a evaluar y mitigar su exposición ante vulnerabilidades LPE como CIFSwitch en infraestructura Linux: verificación del estado de exposición en flotas Linux corporativas, implementación de mitigaciones sin reinicio para entornos de producción críticos, hardening de configuración de user namespaces y módulos del kernel, auditoría de seguridad de entornos CI/CD y runners Linux, y monitorización de actividad de escalada de privilegios mediante eBPF y Falco.
Si tu organización tiene servidores Linux con cifs-utils instalado y user namespaces habilitados y no has aplicado el parche de CVE-2026-46243, este jueves por la mañana es el momento de verificarlo.
%402x.svg){kind=icon}
