El kernel de Linux acaba de sumar otra vulnerabilidad de escalada local de privilegios en una superficie de ataque cercana a Dirty Frag: Fragnesia (CVE-2026-46300).
Según la divulgación de V12 Security, Fragnesia es una vulnerabilidad local de Linux. El atacante no necesita privilegios elevados previos en el host. Si puede ejecutar código local, podría aprovechar un fallo lógico en el subsistema XFRM ESP-in-TCP del kernel para modificar, byte a byte, contenido de archivos de solo lectura a través de la caché de páginas y terminar obteniendo un root shell.
Fuente:
- Notas del PoC de V12 Security: https://github.com/v12-security/pocs/blob/main/fragnesia/README.md
Este artículo no cubre pasos reproducibles de explotación. Se centra en los riesgos y la respuesta operativa.
Relación con Dirty Frag
V12 Security clasifica Fragnesia dentro de la familia de vulnerabilidades Dirty Frag. No es el mismo bug que Dirty Frag, sino otro problema en una superficie de ataque relacionada: XFRM ESP-in-TCP en el kernel de Linux.
XFRM es el marco del kernel de Linux para procesar IPsec. ESP-in-TCP está relacionado con transportar tráfico ESP cifrado sobre TCP. El problema de Fragnesia está en la lógica de fragmentos de página compartidos y la combinación de socket buffers: en ciertas condiciones, el kernel puede perder la pista de que un fragment sigue compartido y dejar una zona de escritura controlable.
Este tipo de fallo recuerda a Dirty Pipe / Dirty Frag y otros problemas de escritura en la caché de páginas. El código concreto no es el mismo, pero el efecto vuelve a caer sobre la copia en caché de un archivo de solo lectura.
Por Qué Es Grave
Fragnesia es peligrosa por tres razones.
Primero, es una escalada local de privilegios. Si un atacante ya puede ejecutar código como usuario normal, podría elevarse a root. Esto es especialmente sensible en servidores multiusuario, hosts de contenedores, CI runners, máquinas de desarrollo compartidas, VPS y entornos que exponen acceso shell.
Segundo, no depende de una condición de carrera tradicional. Las notas de V12 describen una ruta que fuerza el procesamiento ESP-in-TCP sobre páginas de archivo ya incorporadas a un socket buffer mediante splice, lo que permite influir byte a byte en el contenido de la caché de páginas. Eso hace que el riesgo sea práctico, no solo teórico.
Tercero, modifica la caché de páginas, no el archivo en disco. El ejemplo público usa /usr/bin/su como objetivo. Tras una explotación correcta, el archivo en disco no queda modificado de forma permanente; el cambio vive en la memoria. Las revisiones que solo comparan hashes o integridad del disco pueden no ver nada extraño.
Ese es el punto incómodo para los administradores: el archivo parece intacto, pero al ejecutar la copia contaminada desde la caché de páginas puede activarse la escalada.
Alcance Conocido
V12 Security indica que los kernels afectados por Dirty Frag y sin los parches relevantes del 13 de mayo de 2026 también están afectados por Fragnesia. Los entornos verificados públicamente incluyen Ubuntu 22.04, Ubuntu 24.04 y kernels como 6.8.0-111-generic.
Hay dos matices importantes.
Primero, no basta con mirar la versión mayor de la distribución. Que Ubuntu 22.04 / 24.04 esté afectado depende del estado real de parches del kernel, no solo del nombre de la distribución.
Segundo, no conviene confiar únicamente en las restricciones predeterminadas de AppArmor para namespaces de usuario sin privilegios. En Ubuntu pueden elevar la barrera, pero la divulgación las trata como un problema adicional de bypass, no como una corrección del fallo.
La forma fiable de decidir sigue siendo revisar los avisos de seguridad de la distribución y las actualizaciones del paquete del kernel.
Mitigación Temporal
Si un sistema no puede actualizar el kernel de inmediato, primero hay que evaluar si depende de los módulos de protocolo relacionados.
La mitigación indicada por V12 es la misma que para Dirty Frag: si el sistema no depende de IPsec ESP ni de RxRPC, se puede evaluar desactivar módulos como esp4, esp6 y rxrpc. Esto puede afectar capacidades de red, así que no debe aplicarse a ciegas en producción. Antes hay que confirmar si el negocio usa IPsec, VPN, túneles o funciones relacionadas del kernel.
Un orden de respuesta más seguro es:
- Confirmar si la distribución ya publicó una actualización de seguridad del kernel.
- Instalar primero el parche del kernel y programar el reinicio.
- Si no se puede actualizar de inmediato, evaluar la desactivación temporal de módulos.
- Priorizar sistemas multiusuario y entornos de CI / compilación.
- Revisar cuentas locales innecesarias, shell, superficie de escape de contenedores y entradas de ejecución de bajo privilegio.
No hay que tratar la desactivación de módulos como corrección final. Es una reducción temporal de exposición.
Si Se Sospecha Explotación
Una característica de Fragnesia es la contaminación de la caché de páginas. V12 señala que, tras la explotación, la copia del archivo objetivo en la caché puede contener contenido inyectado, y ejecuciones posteriores pueden seguir comportándose de forma anómala hasta que la página sea expulsada o el sistema se reinicie.
Si se sospecha que el sistema fue explotado, conviene al menos:
- Preservar logs y registros de auditoría cuanto antes.
- Revisar inicios de sesión locales anómalos, actividad de usuarios de bajo privilegio, procesos sospechosos y rastros de root shell.
- Limpiar la caché de páginas relevante o reiniciar directamente.
- Actualizar a un kernel corregido.
- Verificar binarios críticos, pero sin depender solo de hashes del disco.
- Rotar credenciales y claves potencialmente expuestas.
En servidores de producción, es mejor tratarlo como un posible incidente de escalada local de privilegios, no solo como una actualización rutinaria.
Qué Máquinas Priorizar
La prioridad no debe repartirse por igual entre todas las máquinas Linux. Hay que empezar por los lugares donde un atacante tiene más probabilidades de obtener ejecución de código con pocos privilegios.
Entornos de mayor prioridad:
- Servidores de login multiusuario
- CI / CD runners
- Máquinas de compilación
- Máquinas de desarrollo compartidas
- Hosts de contenedores
- VPS y servidores cloud
- Nodos de borde con SSH expuesto
- Plataformas que ejecutan scripts o plugins de terceros
Las máquinas cerradas, de un solo usuario y sin entrada externa de ejecución de código siguen teniendo riesgo si son vulnerables, pero la urgencia puede ser menor.
Resumen
Fragnesia merece atención no por tener un nombre nuevo, sino porque vuelve a llevar la escalada local de privilegios en Linux a una frontera compleja: la caché de páginas y los subsistemas de red del kernel.
Para administradores, lo importante no es estudiar los detalles de explotación, sino confirmar el estado de parches del kernel, evaluar si se depende de ESP / RxRPC, actualizar primero las máquinas más expuestas y entender que “el archivo en disco no cambió” no significa “el sistema no fue afectado”.
Si el sistema está afectado, la respuesta final sigue siendo instalar cuanto antes la actualización del kernel ofrecida por la distribución. Desactivar módulos temporalmente es solo una medida puente, no un reemplazo del parche.