Fragnesia, registrada como CVE-2026-46300, ha vuelto a poner el foco en una zona especialmente sensible del kernel Linux: las rutas de red relacionadas con XFRM, ESP e IPsec. Para los administradores de sistemas, lo importante no es solo el nombre de la vulnerabilidad, sino su impacto práctico: un usuario local sin privilegios puede llegar a obtener root si el sistema es vulnerable y no está mitigado o parcheado.
El fallo ha sido divulgado por William Bowling y el equipo de V12 Security, pocos días después de Dirty Frag y apenas tres semanas después de Copy Fail. No es una repetición del mismo bug, aunque pertenece a la misma familia técnica. CloudLinux lo trata como una vulnerabilidad independiente, pero recomienda la misma mitigación temporal que ya se aplicó para Dirty Frag: bloquear los módulos esp4, esp6 y rxrpc si el servidor no depende de ellos.
Para quienes administran servidores de hosting, plataformas multiusuario, nodos de virtualización, runners de CI/CD o sistemas con cargas no confiables, Fragnesia exige una revisión prioritaria. No es una vulnerabilidad remota por sí sola, pero en cuanto un atacante consigue ejecutar código local, puede convertirse en una vía directa para escalar privilegios.
Qué ocurre en el kernel y por qué importa
Fragnesia afecta a la ruta ESP-in-TCP del kernel, en concreto al ULP espintcp. El problema aparece cuando un socket TCP cambia a modo espintcp después de que ya se hayan introducido páginas de archivo en la cola de recepción mediante llamadas como splice(2) o sendfile(2). En ese escenario, el kernel puede tratar páginas de archivo cacheadas como si fueran tráfico ESP cifrado y aplicar descifrado en el sitio.
La consecuencia es una escritura controlada sobre la page cache. El PoC público descrito por los investigadores usa esa primitiva para alterar en memoria la copia cacheada de /usr/bin/su y ejecutar un pequeño stub ELF con privilegios de root. El binario en disco no queda necesariamente modificado, lo que complica una revisión superficial basada solo en checksums del archivo persistente.
Este detalle es clave para administradores: si el exploit se ha ejecutado antes de aplicar mitigación, bloquear módulos ya no basta. También hay que invalidar la caché de páginas o reiniciar para forzar que los binarios vuelvan a cargarse desde disco.
La secuencia recuerda a Dirty Frag y Copy Fail porque el elemento común es el abuso de rutas que permiten escribir en páginas cacheadas que no deberían ser modificables por un proceso sin privilegios. No hay que esperar a que el exploit falle por carrera o por inestabilidad: los análisis publicados describen un fallo lógico determinista, más peligroso para entornos donde haya usuarios locales, shells, contenedores o procesos comprometidos.
Distribuciones afectadas y estado de parches
CloudLinux ha confirmado que CloudLinux 7 no está afectado, mientras que CloudLinux 7h, 8, 9 y 10 sí están afectados. Para CL7h y CL8 se preparan kernels de CloudLinux; para CL9 y CL10 la corrección depende del kernel de AlmaLinux. CloudLinux también trabaja en livepatches de KernelCare para evitar reinicios cuando estén disponibles.
Red Hat ha incorporado Fragnesia a su boletín RHSB-2026-003 junto con Dirty Frag. La compañía identifica tres CVE en la familia: CVE-2026-43284 para el problema original en IPsec ESP/XFRM, CVE-2026-43500 para RxRPC y CVE-2026-46300 para Fragnesia, en el subsistema XFRM ESP-in-TCP. Red Hat confirma afectación en RHEL 8, 9 y 10, además de OpenShift 4.
Ubuntu ya tiene ficha específica para CVE-2026-46300, con prioridad “High” y descripción como escalada local de privilegios en el kernel. A 13/05/2026, muchas variantes de kernel aparecen todavía como “Needs evaluation”, y Canonical remite a la misma mitigación de Dirty Frag. Su aviso previo sobre Dirty Frag indicaba afectación en todas las versiones de Ubuntu soportadas y extendidas, desde 14.04 ESM hasta 26.04 LTS, para los CVE de Dirty Frag.
En Debian, la información pública específica para CVE-2026-46300 no aparece con la misma claridad en el tracker en el momento de redactar este artículo. Esto no debe interpretarse como ausencia de riesgo. En sistemas Debian, Proxmox VE, derivados o kernels personalizados, lo prudente es seguir de cerca los avisos del proveedor, comprobar el kernel instalado y aplicar mitigaciones si el sistema no necesita IPsec/ESP ni RxRPC.
| Sistema | Estado conocido a 13/05/2026 |
|---|---|
| CloudLinux 7 | No afectado según CloudLinux |
| CloudLinux 7h, 8, 9 y 10 | Afectados; kernels y livepatches en preparación |
| RHEL 8, 9 y 10 | Afectados según Red Hat |
| OpenShift 4 | Afectado según Red Hat |
| Ubuntu | CVE publicado con prioridad High; múltiples kernels en evaluación |
| AlmaLinux 9/10 | Relevante para CL9/CL10 y derivados EL; seguir erratas del proveedor |
| Debian / Proxmox / derivados | Revisar avisos oficiales y tratar como potencialmente expuestos si usan kernels afectados |
Mitigación inmediata para servidores que no usan IPsec
La mitigación temporal consiste en impedir la carga de esp4, esp6 y rxrpc, y descargar esos módulos si ya están presentes. En servidores web, hosting compartido o nodos estándar que no terminan túneles IPsec ni usan AFS, suele ser una medida razonable hasta instalar el kernel corregido.
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"Lenguaje del código: JavaScript (javascript)En Ubuntu, Canonical recomienda además regenerar initramfs para evitar que los módulos se carguen durante el arranque temprano:
sudo update-initramfs -u -k allPara comprobar si los módulos siguen cargados:
grep -qE '^(esp4|esp6|rxrpc) ' /proc/modules && echo "Módulos afectados cargados" || echo "Módulos afectados NO cargados"Lenguaje del código: PHP (php)Si los módulos no pueden descargarse porque están en uso, será necesario reiniciar para aplicar el bloqueo. Antes de aplicar esta mitigación en producción hay que comprobar dependencias: esp4 y esp6 se usan en IPsec; bloquearlos puede romper strongSwan, Libreswan o túneles site-to-site. rxrpc se usa sobre todo con AFS, menos habitual en servidores de hosting, pero no inexistente.
Si existe sospecha de explotación previa, conviene limpiar la page cache después de mitigar:
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"Lenguaje del código: JavaScript (javascript)En entornos críticos, el reinicio sigue siendo la opción más limpia si se sospecha manipulación de binarios en caché. El parche del kernel o el livepatch del proveedor son la solución definitiva; el bloqueo de módulos es solo una contención temporal.
Para retirar la mitigación tras instalar un kernel corregido:
sudo rm /etc/modprobe.d/dirtyfrag.conf
sudo update-initramfs -u -k all # Solo en Debian/Ubuntu y derivados si se regeneró antesLenguaje del código: PHP (php)Después de actualizar, siempre hay que verificar el kernel en ejecución:
uname -rEn servidores con KernelCare:
kcarectl --update
kcarectl --infoPara administradores de Linux, la prioridad debería ser clara: identificar sistemas con usuarios locales o cargas no confiables, revisar si IPsec/ESP o RxRPC son necesarios, aplicar mitigación donde sea viable, programar parche o livepatch y revisar indicadores de compromiso. En hosting compartido, CI/CD y entornos con contenedores de terceros, esta vulnerabilidad merece tratamiento urgente.
Fragnesia no afecta a la disponibilidad de un servicio por sí sola, pero puede convertir una cuenta limitada, una shell de bajo privilegio o una aplicación comprometida en control completo del host. Esa es la diferencia entre un incidente contenido y una intrusión con impacto en todo el servidor.
Preguntas frecuentes
¿Qué es Fragnesia?
Fragnesia es una vulnerabilidad de escalada local de privilegios en el kernel Linux, identificada como CVE-2026-46300. Afecta a la ruta ESP-in-TCP dentro del subsistema XFRM y puede permitir obtener root desde un usuario local sin privilegios.
¿Es lo mismo que Dirty Frag?
No. Es un fallo distinto, aunque está en la misma familia técnica y comparte mitigación temporal. Quien ya bloqueó esp4, esp6 y rxrpc por Dirty Frag queda también protegido frente a Fragnesia hasta aplicar el parche definitivo.
¿La mitigación puede romper servicios?
Sí. Bloquear esp4 y esp6 rompe túneles IPsec que dependan del kernel, como strongSwan o Libreswan. Antes de aplicarla hay que revisar si el servidor termina o transita VPNs IPsec.
¿Debo reiniciar el servidor?
Si instalas un kernel corregido, sí, salvo que uses una solución de livepatching compatible. Si solo aplicas la mitigación y no puedes descargar los módulos, también tendrás que reiniciar. Si sospechas explotación previa, reiniciar o limpiar la page cache es recomendable.
