Fragnesia: la falla Linux que da root en segundos

La vulnerabilidad Fragnesia Linux (CVE-2026-46300) es un fallo lógico en el subsistema XFRM ESP-in-TCP del kernel que permite a cualquier usuario local sin privilegios escribir bytes arbitrarios en la caché de páginas del kernel y escalar a root. Descubierta por William Bowling de Zellic el 13 de mayo de 2026, afecta todos los kernels Linux anteriores a esa fecha y ya tiene exploit público funcional.

Qué es Fragnesia: la nueva vulnerabilidad crítica del kernel Linux

Fragnesia es una vulnerabilidad de escalada de privilegios local (LPE) en el kernel Linux, clasificada con CVSS 7.8 (alta), que permite a un atacante sin privilegios obtener acceso root mediante un fallo lógico en el subsistema XFRM ESP-in-TCP.

William Bowling, jefe de assurance en Zellic, publicó el hallazgo el 13 de mayo de 2026 junto con un proof-of-concept funcional. Según BleepingComputer, el fallo pertenece a la misma clase de vulnerabilidades que Dirty Frag, descubierta apenas una semana antes. Es decir, estamos ante la tercera LPE grave en el kernel Linux en cuestión de semanas, después de Copy Fail y Dirty Frag.

Eso sí: Fragnesia no es Dirty Frag con otro nombre. Es un bug separado, en la misma superficie, pero con un mecanismo distinto y, en cierta forma, más directo.

Cómo funciona el ataque Fragnesia

El problema está en la función skb_try_coalesce(). Cuando el kernel fusiona buffers de socket, suelta el marcador SKBFL_SHARED_FRAG. Eso hace que la rutina de decriptado ESP-in-TCP corra in-place sobre páginas que, en realidad, son caché compartida de archivos del sistema.

Resultado: un atacante con acceso local puede escribir bytes arbitrarios sobre archivos de solo lectura en memoria. El exploit que publicó Bowling apunta directo a /usr/bin/su, corrompe su imagen en la caché del kernel y abre una shell con privilegios root. Lo explicamos a fondo en nuestro artículo sobre cómo funcionan los permisos en Linux.

Lo que lo hace especialmente molesto es que el exploit es determinístico. Sin race conditions. Subís el exploit, lo corrés, y el resultado es predecible: root. No es uno de esos bugs donde tenés que intentar mil veces y cruzar los dedos.

Técnicamente, el flujo del ataque según el análisis de Wiz es así: usás unshare(CLONE_NEWUSER) para ganar CAP_NET_ADMIN dentro de un namespace de usuario, creás una Security Association (SA) ESP, hacés escrituras single-byte sobre la caché de /usr/bin/su, y finalmente ejecutás ese binario modificado para obtener tu shell root. Limpio, directo, reproducible.

Qué distribuciones y versiones están afectadas por Fragnesia

Todos los kernels Linux anteriores al 13 de mayo de 2026. La lista de distros afectadas es prácticamente el ecosistema completo.

Distribución	Versiones afectadas	Parche disponible
Ubuntu	Todas las versiones con kernel pre-13/05/2026	Sí (mayo 2026)
Debian 10 y 12	Kernels anteriores a la actualización de mayo	Sí (mayo 2026)
RHEL / CentOS	Versiones sin el parche del advisory RHSB-2026-003	Sí — Red Hat RHSB-2026-003
Fedora	Versiones sin actualización de mayo 2026	Sí (mayo 2026)
AlmaLinux	Idem RHEL	Sí (mayo 2026)
Amazon Linux	Kernels anteriores al parche de mayo	Sí (mayo 2026)

CloudLinux también publicó instrucciones de mitigación y actualización de kernel el mismo día de la publicación del fallo, dado el impacto directo en entornos de hosting compartido.

Fragnesia vs. Dirty Frag: diferencias clave

Dirty Frag encadena dos vulnerabilidades separadas: la xfrm-ESP Page-Cache Write (CVE-2026-43284) y una falla de RxRPC Page-Cache Write (CVE-2026-43500). Necesitás las dos para lograr la escalada.

Fragnesia es un bug único. Un solo CVE (CVE-2026-46300), un solo fallo en XFRM, mismo resultado.

Característica	Dirty Frag	Fragnesia
CVEs necesarios	2 (CVE-2026-43284 + CVE-2026-43500)	1 (CVE-2026-46300)
Subsistema afectado	XFRM + RxRPC	XFRM ESP-in-TCP únicamente
Complejidad del exploit	Encadenamiento de dos bugs	Fallo único, más directo
PoC público	Sí	Sí
Determinístico	Sí	Sí
Resultado	Root	Root

¿Cuál es más peligrosa? Las dos son igual de peligrosas en la práctica. El resultado es idéntico. Fragnesia es quizás más fácil de explotar para un atacante menos avanzado porque no necesita entender y encadenar dos superficies de ataque distintas. Complementá tu estrategia con la automatización de deployments de forma segura.

Mitigación y parches: cómo protegerse

Hay dos caminos.

El ideal: actualizá el kernel a la versión parcheada de tu distro. Los parches llegaron el 13 de mayo de 2026 para las principales distribuciones. Si tu sistema tiene actualizaciones automáticas y recibió el kernel en esa fecha o después, ya estás cubierto. Verificá con uname -r y revisá las notas de versión de tu distro.

La mitigación temporal, para cuando no podés reiniciar en producción todavía, consiste en desactivar los módulos vulnerables:

• modprobe -r esp4
• modprobe -r esp6
• modprobe -r rxrpc

Ojo: si alguno de esos módulos está en uso activo en tu sistema (tunnels VPN con ESP, por ejemplo), desactivarlo puede interrumpir tráfico. Evaluá el impacto antes de tirar.

Si usás Red Hat o derivados, el advisory RHSB-2026-003 tiene las instrucciones específicas para tu versión.

Impacto en servidores web y hosting Linux

Acá viene lo importante para los que administran servidores.

Fragnesia es una LPE: necesita acceso local para ejecutarse. Pero “acceso local” en 2026 puede querer decir muchas cosas: un usuario SSH comprometido, un webshell en una aplicación web mal configurada, un container escape en un entorno con aislamiento débil, o directamente un usuario en un plan de hosting compartido.

Ponele que tenés un servidor con 50 cuentas de cliente. Si uno de esos clientes tiene una app con una vulnerabilidad de RCE y un atacante la explota, ahora ese atacante tiene shell con permisos del usuario de esa cuenta. Con Fragnesia, ese atacante pasa de ser un usuario restringido a tener root del servidor entero en segundos. (Sí, así de rápido.) Sobre eso hablamos en despliegues seguros en infraestructura cloud.

Para VPS y servidores dedicados el riesgo también existe, especialmente si hay múltiples usuarios con acceso SSH o si el servidor corre aplicaciones que pueden ser comprometidas. Microsoft publicó un análisis en mayo de 2026 sobre el riesgo post-compromiso de estos bugs en entornos cloud.

Si administrás hosting Linux y todavía no actualizaste, es para hoy. No para mañana. Si estás evaluando qué proveedor de hosting usar para nuevos proyectos, donweb.com aplica parches de kernel en sus entornos de forma centralizada, lo cual reduce la ventana de exposición en casos como este.

Cómo funciona el exploit paso a paso

Bowling publicó el PoC junto con el reporte, así que el mecanismo es conocido. La secuencia:

• Llamada a unshare(CLONE_NEWUSER) para crear un namespace de usuario y obtener CAP_NET_ADMIN sin ser root
• Configuración de una Security Association (SA) ESP dentro del namespace
• Aprovechamiento del bug en skb_try_coalesce() para lograr escrituras single-byte sobre la caché de páginas de /usr/bin/su
• Modificación del binario en memoria para que ejecute código arbitrario
• Llamada a /usr/bin/su, que ahora corre código controlado por el atacante con permisos root

Todo esto sin race conditions. Escribís los bytes, corren, terminan. El binario en caché queda modificado hasta que el sistema lo descarte o se reinicie. Es confiable de una forma que muchos exploits de kernel no son.

¿Alguien lo verificó de forma independiente antes de la publicación oficial? Los equipos de Red Hat y Wiz confirmaron el comportamiento. El PoC funciona tal como Bowling describió.

Errores comunes al responder a esta vulnerabilidad

Error 1: confundir mitigación con parche. Desactivar esp4/esp6/rxrpc es una mitigación temporal, no un fix. Si dejás el sistema sin el kernel actualizado porque “ya desactivé los módulos”, seguís vulnerable si los módulos se recargan (reboot, kmod scripts, dependencias).

Error 2: asumir que los containers te protegen. Si un atacante logra escalar a root dentro de un container mal aislado (sin seccomp, sin AppArmor, namespace sharing), Fragnesia puede ser el segundo paso para salir del container al host. El aislamiento de containers no reemplaza el parche del kernel. Ya lo cubrimos antes en validar la calidad del código en cada release.

Error 3: esperar a la próxima ventana de mantenimiento. Hay PoC público desde el 13 de mayo de 2026. El tiempo entre publicación de PoC y uso activo en campañas automatizadas se mide en días, no semanas. Esta no es una actualización de rutina.

Preguntas Frecuentes

¿Qué es la vulnerabilidad Fragnesia?

Fragnesia (CVE-2026-46300) es un fallo lógico en el subsistema XFRM ESP-in-TCP del kernel Linux, con severidad CVSS 7.8. Permite a cualquier usuario local sin privilegios escalar a root escribiendo bytes arbitrarios sobre la caché de páginas del kernel. Afecta todos los kernels anteriores al 13 de mayo de 2026 y tiene exploit público disponible desde esa fecha.

¿Cómo puedo protegerme de Fragnesia en Linux?

La solución definitiva es actualizar el kernel a la versión parcheada de tu distribución (disponible desde el 13 de mayo de 2026). Como mitigación temporal, podés desactivar los módulos vulnerables con modprobe -r esp4 esp6 rxrpc, aunque esto puede afectar funcionalidad de red si los usás activamente. Reiniciar tras aplicar el parche garantiza que la caché de páginas modificada se descarte.

¿Qué versiones de Linux están afectadas por Fragnesia?

Todos los kernels Linux publicados antes del 13 de mayo de 2026 son vulnerables. Esto incluye Ubuntu, Debian 10 y 12, RHEL, CentOS, Fedora, AlmaLinux y Amazon Linux sin los parches de mayo de 2026. Si tu kernel tiene fecha de build posterior al 13 de mayo de 2026 y tu distro publicó actualizaciones ese día, ya está parcheado.

¿Cuál es la diferencia entre Fragnesia y Dirty Frag?

Dirty Frag requiere encadenar dos vulnerabilidades separadas (CVE-2026-43284 en XFRM y CVE-2026-43500 en RxRPC). Fragnesia es un bug único (CVE-2026-46300) en XFRM que logra el mismo resultado: shell root determinística sin race conditions. Ambas tienen PoC público y el mismo impacto final, pero Fragnesia es más directa al no necesitar la segunda vulnerabilidad.

¿Existe exploit público de Fragnesia?

Sí. William Bowling de Zellic publicó el proof-of-concept junto con el reporte el 13 de mayo de 2026. El exploit corrompe /usr/bin/su en la caché del kernel y abre una shell root. Es determinístico, sin race conditions, lo que lo hace especialmente confiable comparado con muchos exploits de kernel que requieren múltiples intentos.

Conclusión

Fragnesia llegó en el peor momento posible: semanas después de Dirty Frag, con un PoC listo el mismo día de la publicación, y afectando prácticamente todo el ecosistema Linux. La buena noticia es que los parches están disponibles desde el 13 de mayo de 2026 para todas las distribuciones principales.

Lo que cambió con este tipo de vulnerabilidades es la velocidad de explotación. Antes, un CVE crítico te daba semanas antes de ver campañas activas. Ahora, con PoC público disponible desde el día cero, esa ventana se redujo a días. Si administrás servidores Linux y todavía no aplicaste el parche, no hay argumento válido para esperar más.

Actualizá el kernel, reiniciá, y verificá. Si necesitás tiempo antes del reinicio, desactivá los módulos. El resto es gestión de incidentes, no de vulnerabilidades.

Fuentes

• BleepingComputer — New Fragnesia Linux flaw lets attackers gain root privileges
• Wiz — Fragnesia: Linux kernel LPE via ESP-in-TCP (análisis técnico completo)
• Red Hat — Security Bulletin RHSB-2026-003 (parches oficiales para RHEL)
• The Hacker News — New Fragnesia Linux Kernel LPE Grants Root Access
• Microsoft Security Blog — Active attack: Dirty Frag vulnerability expands post-compromise risk