- Fragnesia es una vulnerabilidad de escalada local de privilegios en el kernel de Linux que permite obtener root con escrituras arbitrarias en la page cache.
- El fallo reside en el manejo de ESP-in-TCP dentro del subsistema XFRM, reutilizando páginas de archivo como si fueran datos cifrados ESP.
- Afecta a una gran cantidad de distribuciones Linux usadas en España y Europa, con PoC público y parches ya disponibles.
- Se recomiendan parcheo inmediato del kernel, bloqueo de módulos esp4/esp6/rxrpc y vaciado de la caché de páginas como medidas clave.
La supuesta imagen de fortaleza del kernel de Linux está viviendo uno de sus momentos más delicados. En cuestión de semanas han salido a la luz varias vulnerabilidades críticas, y Fragnesia se ha convertido en el último y más preocupante eslabón de una cadena de fallos que incluye a Copy Fail y Dirty Frag. El impacto es especialmente relevante para servidores y servicios en la nube que usan Linux, muchos de ellos desplegados en centros de datos europeos y españoles.
Fragnesia es un fallo de escalada local de privilegios que permite que un usuario sin permisos especiales acabe controlando por completo el sistema como root, y lo hace de forma fiable y sin necesidad de técnicas demasiado rebuscadas. Con código de explotación público disponible y millones de máquinas potencialmente afectadas, el panorama obliga a administradores, equipos DevOps y responsables de ciberseguridad a moverse rápido y con cabeza.
Qué es Fragnesia y cómo encaja en la nueva oleada de fallos del kernel de Linux
Fragnesia es una vulnerabilidad de tipo Local Privilege Escalation (LPE) en el kernel de Linux, rastreada como CVE-2026-46300, descubierta por el investigador William Bowling del equipo de seguridad V12. Se apoya en un bug lógico dentro del código ESP/XFRM del kernel, muy próximo conceptualmente a Dirty Frag y Copy Fail, pero con una ruta de explotación propia.
El fallo permite a un usuario local sin privilegios escribir bytes arbitrarios sobre la page cache de archivos marcados como de solo lectura. Esto rompe por completo la suposición de que un binario protegido no puede modificarse sin permisos de administrador, y abre la puerta a alterar herramientas críticas del sistema para que, al ejecutarse, concedan una shell de root al atacante.
En las últimas semanas se ha ido perfilando una familia de vulnerabilidades similares: Copy Fail (CVE-2026-31431), Dirty Frag (CVE-2026-43284/43500) y, ahora, Fragnesia. Todas explotan errores en la gestión de memoria y de fragmentos de red en el kernel para crear una primitiva de escritura controlada en memoria, pero Fragnesia destaca por su sencillez de explotación y por el hecho de que su parche se reduzca a apenas un par de líneas en el archivo _skbuff.c.
La gravedad no es solo técnica. Según análisis de organismos y empresas de seguridad como INCIBE, Hispasec, s2grupo o DEFION, más del 80 % de los servidores Linux con kernels entre la serie 4.14 y la 6.18.21 podrían verse afectados por este tipo de LPE, un rango que incluye distribuciones de uso masivo en España y Europa como Ubuntu 24.04 LTS, RHEL 8/9/10, Amazon Linux 2023 y un amplio abanico de distros empresariales.
Por si fuera poco, en paralelo han aparecido otras vulnerabilidades como ssh-keysign-pwn, también relacionada con el kernel y con acceso indebido a recursos propiedad de root. Todo ello dibuja un escenario de “fatiga de parches” entre administradores, que ven cómo tienen que encadenar actualizaciones críticas y reinicios en producción casi sin tregua.
Cómo funciona Fragnesia: del olvido de fragmentos a la inyección en la caché de páginas
El corazón de Fragnesia está en el subsistema XFRM del kernel y en el manejo de ESP-in-TCP, una combinación utilizada para procesar tráfico IPsec cifrado. El problema aparece cuando el kernel “se olvida” de que ciertas páginas de memoria proceden de archivos compartidos entre procesos y las trata como si fuesen bloques de datos cifrados ESP listos para ser descifrados.
En un escenario típico de explotación, el atacante provoca que un socket TCP pase a modo ULP espintcp después de haber introducido en su cola de recepción páginas de archivo mediante llamadas como splice(2) o sendfile(2). En lugar de dejar esas páginas como simples datos de fichero en memoria, el kernel las considera texto cifrado ESP y aplica sobre ellas la rutina criptográfica (por ejemplo, AES-GCM) directamente sobre la page cache.
El resultado es que el flujo de claves de AES-GCM se aplica como una operación XOR in situ sobre páginas de la caché de archivos de solo lectura. Controlando parámetros como el vector de inicialización (nonce), un usuario sin privilegios puede construir una tabla de búsqueda que relaciona cada posible byte de salida con un nonce concreto. De esta forma, es posible forzar al sistema a escribir un valor exacto en un desplazamiento específico del archivo en caché.
La prueba de concepto hecha pública se centra en /usr/bin/su, un binario suid crítico. El exploit aísla el proceso en nuevos espacios de nombres de usuario y red, configura una asociación de seguridad ESP con una clave bajo su control y va iterando byte a byte sobre la cabecera del binario. Así sobrescribe los primeros 192 bytes de su en memoria con un pequeño stub ELF independiente de la posición que, al ejecutarse el comando su, lanza una shell de root controlada por el atacante.
Un detalle importante es que el archivo físico en disco no se modifica; solo cambia su copia en la caché de páginas. Para el sistema, el fichero sigue siendo aparentemente inalterado, lo que complica la detección mediante herramientas tradicionales de integridad y hace que soluciones antivirus convencionales no detecten nada extraño durante el ataque.
Impacto real en servidores Linux en España y Europa
En el contexto europeo, y particularmente en España y Latinoamérica, el impacto potencial de Fragnesia es notable. Buena parte de la infraestructura de startups, empresas de servicios digitales, administraciones públicas y proveedores en la nube se basa en Linux, con kernels LTS que encajan de lleno en el rango vulnerable.
Muchos proyectos en la región ejecutan Kubernetes sobre nodos Ubuntu o RHEL en nubes como AWS, GCP o Azure. El escenario de riesgo más repetido es claro: un atacante explota primero una vulnerabilidad web o de aplicación para entrar en un contenedor con permisos limitados y, una vez dentro, lanza Fragnesia para escalar a root del nodo. Desde ahí puede moverse lateralmente entre pods, acceder a secretos, bases de datos y, en la práctica, hacerse con la infraestructura completa.
Informes de empresas especializadas como s2grupo, DEFION Security o Hispasec señalan que en España y otros países europeos hay un retraso habitual en la aplicación de parches de kernel en entornos productivos, por temor a cortes de servicio. En Latinoamérica, donde los presupuestos de ciberseguridad suelen ser aún más ajustados, este retraso puede ser mayor, lo que alarga la ventana de exposición frente a exploits públicos como el de Fragnesia.
Desde organismos como INCIBE-CERT se insiste en que el hecho de que la vulnerabilidad requiera acceso local no debe generar una falsa sensación de seguridad. En entornos multiusuario, con servicios expuestos a internet o con acceso remoto por SSH, basta una sola cuenta comprometida para que Fragnesia se convierta en un problema serio.
Además, la sucesión de Copy Fail, Dirty Frag, Fragnesia y otros fallos como ssh-keysign-pwn está alimentando un mercado negro muy activo en torno a zero-days de escalada local en Linux, con ofertas de vulnerabilidades inéditas por cifras que rondan los 170.000 dólares. Este contexto hace previsible que surjan variantes o fallos emparentados en los próximos meses.
Mitigaciones temporales y limpieza de la caché de páginas
Aunque la solución definitiva pasa por actualizar a un kernel corregido y reiniciar, existen medidas temporales que pueden reducir drásticamente el riesgo en sistemas donde no es viable un reinicio inmediato. La buena noticia es que, al compartir superficie de ataque con Dirty Frag, las mismas mitigaciones propuestas para ese fallo sirven también para Fragnesia.
La principal medida es impedir la carga de los módulos esp4, esp6 y, opcionalmente, rxrpc mediante reglas de modprobe. Esto se hace creando un archivo de configuración en /etc/modprobe.d/ que reemplace la carga de esos módulos por un comando inocuo (por ejemplo, /bin/false). Después, se intenta descargarlos con rmmod, ignorando errores si no están presentes.
Muchas guías, incluidas las de algunas distribuciones como CloudLinux, automatizan este proceso creando un fichero (por ejemplo, dirtyfrag.conf) con las reglas de blacklist para esp4, esp6 y rxrpc, y a continuación ejecutando rmmod sobre ellos. Si ya se aplicó esta mitigación por Dirty Frag, no suele ser necesario hacer nada adicional para Fragnesia hasta que llegue el kernel parcheado, porque la superficie vulnerable queda prácticamente desactivada.
Sin embargo, hay que valorar el impacto en cada entorno. Los módulos esp4 y esp6 generan los transform de IPsec dentro del kernel, por lo que deshabilitarlos puede romper túneles IPsec utilizados por soluciones como strongSwan o Libreswan. En servidores que terminan o enrutan tráfico IPsec crítico, esta mitigación puede no ser aceptable. El módulo rxrpc, vinculado a AF_RXRPC y usado sobre todo por clientes AFS, suele ser mucho menos común en entornos generalistas.
Otro paso clave es vaciar la caché de páginas del sistema tras aplicar las mitigaciones, especialmente si se sospecha que un exploit pudo haberse ejecutado. Mediante la escritura de valores apropiados en /proc/sys/vm/drop_caches se fuerzan al kernel a liberar page cache y dentries/inodes. Esta operación no borra datos sucios ni pone en peligro el sistema de ficheros, pero sí provoca que los binarios se recarguen desde disco en su versión limpia.
La idea es sencilla: si un atacante hubiera inyectado código malicioso en la copia en memoria de /usr/bin/su u otro binario suid, al descartar esa caché y recargar desde el disco original se elimina esa modificación oculta. Combinando este paso con el bloqueo de módulos XFRM afectados, se reduce significativamente la posibilidad de que queden restos de una explotación previa operando en segundo plano.
Estado de los parches y respuesta de las distribuciones Linux
La reacción del ecosistema Linux ha sido relativamente rápida. El equipo de V12 Security comunicó la vulnerabilidad siguiendo un proceso de divulgación responsable: aviso previo, coordinación con desarrolladores del kernel, parche disponible y, una vez preparado el fix, publicación de la prueba de concepto para presionar en la adopción de la actualización.
En el caso de Fragnesia, el parche consiste en corregir la lógica del código relacionado con el manejo de fragmentos de red en _skbuff.c y en la ruta ESP-in-TCP del subsistema XFRM, evitando que se apliquen rutinas criptográficas sobre páginas de archivo reutilizadas. Distribuciones como AlmaLinux, CloudLinux y Fedora han empezado a distribuir kernels corregidos, mientras que Red Hat ha indicado que su prioridad es evaluar en qué medida las mitigaciones y parches previos cubren también este nuevo CVE.
En el entorno de Microsoft y Google, que integran Linux en múltiples productos y servicios cloud, se han publicado análisis que recalcan que la vulnerabilidad permite a usuarios locales modificar contenido de archivos de solo lectura en la caché de páginas y obtener root mediante una corrupción de memoria determinista. Aunque en el momento de sus comunicados no habían detectado explotación activa en producción, ambos recomiendan aplicar el parche lo antes posible y recurrir a las mitigaciones de Dirty Frag (desactivar esp4/esp6, reforzar XFRM) si no es posible actualizar de inmediato.
En paralelo, herramientas y soluciones de seguridad como AppArmor, restricciones sobre user namespaces sin privilegios o sandboxes como gVisor pueden complicar o bloquear algunas fases del exploit. Por ejemplo, en sistemas donde la creación de espacios de nombres de usuario sin privilegios está deshabilitada o fuertemente limitada, la prueba de concepto estándar de Fragnesia puede fallar en sus primeros pasos, obligando al atacante a buscar alternativas más complejas.
Además, el caso de ssh-keysign-pwn ha llevado a retocar la interfaz de ptrace y otros mecanismos de depuración interna del kernel, cerrando vías de lectura indebida de archivos de root desde cuentas no privilegiadas. Todo ello muestra una tendencia clara: los mantenedores están revisando con lupa rutas de código sensibles, en especial las relacionadas con memoria compartida, page cache y mecanismos de observación de procesos.
Recomendaciones prácticas para administradores, DevOps y startups
Para equipos técnicos en España, Europa y LATAM que gestionan infraestructura Linux en producción, la prioridad inmediata es clara: comprobar versiones de kernel y aplicar parches tan pronto como estén disponibles en los repositorios oficiales de la distribución.
Un primer paso sencillo es ejecutar uname -r en todos los servidores y contrastar esa versión con los avisos de seguridad de la distro. Si el kernel está por debajo de las versiones corregidas (por ejemplo, anterior a 6.18.22 o al paquete específico que publica cada proveedor), el sistema debe considerarse vulnerable. En ese caso, conviene:
- Actualizar el kernel usando las herramientas habituales: apt en Debian/Ubuntu, dnf en RHEL/AlmaLinux, zypper en SUSE, etc.
- Planificar y ejecutar un reinicio en la ventana más temprana posible para cargar el nuevo kernel.
- Si el reinicio no es viable, aplicar blacklist de esp4/esp6/rxrpc y vaciar la caché de páginas como mitigaciones temporales.
- Reforzar el monitorizado de eventos de escalada de privilegios con herramientas como Falco, Wazuh u otras soluciones SIEM.
- Revisar la configuración de contenedores y orquestadores (Kubernetes, Docker, etc.) para minimizar el daño de un potencial escape.
Para startups con equipos pequeños y pocos recursos, la tentación de dejar estas tareas “para la semana que viene” es comprensible, pero arriesgada. La existencia de una prueba de concepto pública en GitHub significa que cualquier desarrollador con ciertas nociones puede intentar adaptar el exploit a su entorno, y los sistemas que siguen sin parchear se convierten en objetivos fáciles.
Más allá de Fragnesia, la lección de fondo para responsables técnicos es que la seguridad del kernel no puede tratarse como algo estático. Incluir actualizaciones de seguridad del kernel dentro del pipeline de CI/CD, mantener un inventario claro de servidores y servicios, y contar con una política definida de ventanas de mantenimiento reduce mucho el impacto cuando aparecen fallos críticos en cadena.
También es recomendable limitar al máximo el número de usuarios con acceso local a servidores, aplicar el principio de privilegio mínimo y reforzar controles de acceso por SSH, VPN y otros vectores de entrada. En entornos multiusuario, cuantos menos puntos de apoyo tenga un atacante, menor será la probabilidad de que una vulnerabilidad de LPE termine en un compromiso total de la infraestructura.
El caso de Fragnesia pone de manifiesto hasta qué punto la robustez de los sistemas Linux modernos depende de una cadena compleja que va desde el código del kernel hasta las políticas de despliegue, pasando por herramientas de actualización, mecanismos de aislamiento y soluciones de monitorización. Mantenerse al día de los avisos de seguridad, reaccionar con rapidez ante nuevos exploits, combinar parches oficiales con mitigaciones bien entendidas y no descuidar el control de acceso local se ha convertido en una rutina ineludible para que una vulnerabilidad como esta no acabe siendo el punto único de fallo de toda la infraestructura.
