Durante años se ha repetido una idea cómoda: Linux es seguro, estable y perfecto para servidores que pueden pasar meses funcionando sin tocarse. La primera parte sigue siendo cierta en muchos sentidos. Linux es una base sólida, auditable y con una comunidad de seguridad enorme detrás. La segunda, sin embargo, se ha vuelto peligrosa. Un servidor Linux no puede instalarse, endurecerse una vez y quedar abandonado hasta el siguiente cambio de hardware.

Las últimas semanas han dejado una cadena de avisos que debería hacer reaccionar a cualquier administrador: Copy Fail, Dirty Frag, Fragnesia y ssh-keysign-pwn. No son fallos menores ni vulnerabilidades teóricas enterradas en un subsistema exótico que nadie usa. Varias de ellas permiten escalada local de privilegios hasta root, otras exponen secretos de root como claves SSH o /etc/shadow, y algunas cuentan con pruebas de concepto públicas. En entornos cloud, servidores compartidos, máquinas de desarrollo, bastiones SSH, clústeres Kubernetes o hosting multiusuario, un fallo local puede convertirse en un problema de infraestructura.

Copy Fail, identificado como CVE-2026-31431, fue divulgado el 29 de abril de 2026 y afecta al módulo algif_aead del kernel, la interfaz AEAD de la API criptográfica de usuario AF_ALG. CERT-EU lo describió como una escalada local de privilegios con CVSS 7.8 que afecta a distribuciones Linux principales con kernels construidos desde 2017. La técnica permite, encadenando AF_ALG con splice(), una escritura controlada en páginas respaldadas por la page cache, con ejemplos dirigidos a binarios setuid como /usr/bin/su.

Microsoft también advirtió de su impacto en cargas cloud Linux y clústeres Kubernetes, y señaló que la disponibilidad de un PoC funcional elevaba el riesgo de explotación. La misma publicación indicaba que CISA había añadido CVE-2026-31431 a su catálogo de vulnerabilidades explotadas, lo que aumenta la prioridad operativa para organizaciones que todavía no hubieran actualizado.

Una cadena de fallos que apunta a la misma lección

Dirty Frag llegó poco después. CloudLinux lo presentó como una segunda escalada local de privilegios en el mismo ámbito amplio de Copy Fail, esta vez en rutas de descifrado in-place de esp4, esp6 y rxrpc. La vulnerabilidad, asociada a CVE-2026-43284 y CVE-2026-43500, permite que procesos sin privilegios conserven referencias a datos que terminan generando una primitiva de escritura en la page cache. En términos prácticos, el PoC público podía convertir una cuenta local sin privilegios en root.

INCIBE-CERT publicó una mitigación temporal para Dirty Frag que bloquea la carga de los módulos esp4, esp6 y rxrpc, descarga los módulos si están presentes y limpia la caché de páginas. No es una corrección definitiva, pero sí una defensa útil mientras se despliega el kernel parcheado, siempre que el servidor no dependa de IPsec o RxRPC.

Después llegó Fragnesia, CVE-2026-46300, una vulnerabilidad distinta pero de la misma familia XFRM/ESP. CloudLinux la describió como la tercera escalada local de privilegios en tres semanas que exigía parche y reinicio, tras Copy Fail y Dirty Frag. También explicó que la mitigación inmediata era idéntica a la de Dirty Frag: bloquear los módulos implicados hasta poder aplicar un kernel corregido.

La cuarta alerta reciente, ssh-keysign-pwn, cambia ligeramente el tipo de impacto. CVE-2026-46333 no se presenta como una escalada directa a root, sino como una fuga de información crítica en la lógica de acceso de ptrace. Según AlmaLinux, Qualys reportó el fallo a [email protected], Linus Torvalds integró la corrección el 14 de mayo de 2026 y poco después se publicaron exploits funcionales para leer claves privadas del host SSH mediante ssh-keysign y /etc/shadow mediante chage -l.

CloudLinux lo resume con claridad: un usuario local sin privilegios en un host afectado puede leer secretos propiedad de root sin obtener root directamente. Esa frase debería bastar para que cualquier equipo de sistemas lo trate con urgencia. Una clave privada SSH del host o los hashes de /etc/shadow pueden abrir la puerta a suplantación, cracking offline, movimiento lateral y compromisos posteriores.

El problema no es Linux, es cómo lo mantenemos

Sería un error usar esta sucesión de fallos para concluir que Linux es inseguro. El kernel es una pieza enorme, muy compleja y expuesta a usos muy distintos: portátiles, móviles, routers, servidores cloud, supercomputadores, contenedores, sistemas embebidos, almacenamiento, redes y virtualización. Lo que muestran estos casos no es una debilidad específica de Linux frente a otros sistemas, sino la necesidad de tratar el mantenimiento del kernel como una tarea continua y prioritaria.

El primer cambio de mentalidad es asumir que las vulnerabilidades locales importan. Muchas organizaciones clasifican los fallos locales como secundarios porque “el atacante ya tiene que estar dentro”. En 2026 esa visión se queda corta. Un atacante puede llegar con una cuenta limitada, un contenedor mal aislado, un runner CI/CD, una web vulnerable, una cuenta SFTP, un usuario de hosting o un acceso temporal de proveedor. Si desde ahí puede llegar a root o leer secretos del sistema, el perímetro ya no sirve de consuelo.

El segundo cambio es aceptar que reiniciar servidores forma parte de la seguridad. Durante años se ha premiado el uptime como si un servidor con 800 días encendido fuera señal de excelencia. Hoy puede ser señal de abandono. Un uptime demasiado largo en sistemas expuestos suele indicar kernels antiguos, módulos sin parchear y vulnerabilidades acumuladas. La disponibilidad no se logra evitando reinicios indefinidamente, sino diseñando servicios con redundancia para poder parchear sin miedo.

El tercer cambio es diferenciar entre actualizar paquetes y actualizar el kernel en ejecución. En Linux es habitual instalar actualizaciones y olvidar que el kernel vulnerable sigue cargado hasta el reinicio. Después de una actualización de kernel, hay que verificar qué versión se está ejecutando con uname -r, comprobar si hay reinicio pendiente y cerrar la ventana de exposición. En distribuciones empresariales, herramientas como needrestart, dnf needs-restarting, reboot-required o los avisos del proveedor ayudan, pero no sustituyen a una política clara.

Medidas prácticas para mantener Linux lejos de problemas graves

La primera medida es tener inventario. No se puede proteger lo que no se sabe que existe. Hay que conocer distribución, versión, kernel en ejecución, kernel instalado, función del servidor, exposición a usuarios locales, uso de contenedores, módulos cargados y criticidad del servicio. Cuando aparece una vulnerabilidad como Copy Fail o Dirty Frag, el equipo debe poder responder en minutos a una pregunta básica: qué sistemas están afectados.

La segunda es automatizar alertas de seguridad. Debian Security Tracker, Ubuntu Security Notices, Red Hat CVE Database, AlmaLinux Security Advisories, Rocky Linux, SUSE, CISA KEV, CERT-EU, INCIBE-CERT y avisos de proveedores como CloudLinux deben formar parte del radar. No hace falta leerlo todo manualmente, pero sí recibir alertas filtradas por distribución y criticidad.

La tercera es definir ventanas de parcheo reales. En servidores no críticos puede bastar con actualizaciones automáticas de seguridad y reinicios programados. En producción crítica hacen falta grupos, balanceadores, nodos redundantes y mantenimiento escalonado. El objetivo no es parchear “cuando haya tiempo”, sino tener tiempo reservado antes de que el exploit público convierta el CVE en incidente.

La cuarta es valorar live patching. No sustituye a una buena arquitectura, pero puede reducir mucho el riesgo cuando una vulnerabilidad del kernel exige respuesta urgente y el reinicio no es inmediato. CloudLinux menciona KernelCare como alternativa para aplicar correcciones de seguridad del kernel sin ventana de mantenimiento en varios de estos casos. Otras distribuciones cuentan con opciones como kpatch, kGraft, Canonical Livepatch o soluciones comerciales equivalentes. La clave es comprobar que el livepatch cubre el CVE concreto, no asumirlo.

La quinta es aplicar mitigaciones temporales con criterio. Para Dirty Frag y Fragnesia, bloquear esp4, esp6 y rxrpc puede ser razonable en muchos servidores web o máquinas que no usan IPsec ni AFS, pero puede romper túneles strongSwan, Libreswan u otros usos legítimos de IPsec. Para ssh-keysign-pwn, endurecer ptrace, limitar user namespaces sin privilegios o retirar temporalmente el bit SUID de binarios concretos puede reducir exposición, pero puede afectar a depuración, contenedores rootless o flujos de desarrollo. Las mitigaciones son un puente hacia el parche, no una excusa para quedarse en un kernel vulnerable.

La sexta es reducir usuarios locales no necesarios. Si un servidor no necesita acceso shell de clientes, no debe tenerlo. Si un runner de CI ejecuta código no confiable, debe estar aislado y ser descartable. Si un panel de hosting permite ejecutar procesos, el aislamiento debe revisarse como parte del modelo de amenaza. Las vulnerabilidades locales se vuelven mucho más graves cuanto más fácil es conseguir una cuenta local.

La séptima es rotar secretos cuando el fallo lo justifique. En ssh-keysign-pwn, parchear el kernel evita la explotación futura, pero no cambia automáticamente una clave SSH que pudo haberse filtrado. En hosts expuestos o multiusuario, la rotación de claves del host SSH, la revisión de /etc/shadow, el cambio de contraseñas locales y la comprobación de huellas conocidas deben estar en el plan de respuesta.

Mantener Linux seguro no significa vivir en emergencia permanente. Significa tener procedimientos antes de que llegue la emergencia: inventario, alertas, parches, reinicios, live patching, mitigaciones documentadas y capacidad de respuesta. Las últimas vulnerabilidades no son una llamada a desconfiar de Linux. Son una llamada a administrarlo como lo que es: una infraestructura crítica que cambia cada semana y que no perdona el abandono.

Preguntas frecuentes

¿Estos fallos afectan a todos los servidores Linux?
No todos los sistemas son explotables de la misma forma, pero Copy Fail, Dirty Frag, Fragnesia y ssh-keysign-pwn afectan a ramas y distribuciones muy extendidas. La única forma fiable de saberlo es revisar el aviso del proveedor y la versión de kernel en ejecución.

¿Una vulnerabilidad local es menos urgente que una remota?
No siempre. En servidores compartidos, entornos cloud, contenedores, CI/CD o máquinas con usuarios no confiables, una vulnerabilidad local puede terminar en root o en fuga de claves.

¿Basta con ejecutar apt update o dnf upgrade?
No. En fallos de kernel hay que instalar el kernel corregido y reiniciar, salvo que se aplique un livepatch confirmado para ese CVE. Después conviene verificar el kernel cargado con uname -r.

¿Qué debería hacer una empresa para no ir siempre por detrás?
Mantener inventario, suscribirse a avisos de seguridad, automatizar parches cuando sea posible, diseñar alta disponibilidad para poder reiniciar, usar live patching en sistemas críticos y revisar accesos locales innecesarios.