Seguridad de servidores en la era de la IA (parte 2): la falla del kernel que convirtió PHP2Shell en control total
Parte 2: Fragnesia (CVE-2026-46300), la falla del kernel de Linux encadenada con PHP2Shell. Qué es, estado de los parches al 31 de octubre y qué hacer.
Segunda parte de nuestra serie sobre seguridad de servidores. En la primera parte contamos cómo atacantes combinaron PHP2Shell con «una segunda falla» para tomar el control total de 25 equipos. Esa segunda falla está en el kernel de Linux, el núcleo del sistema operativo, y se llama Fragnesia. Este artículo explica qué es, en qué estado están los parches al 31 de octubre de 2026 y qué conviene hacer. Lo actualizaremos a medida que cambie su estado.
Qué es Fragnesia
Fragnesia es una vulnerabilidad del kernel de Linux registrada como CVE-2026-46300. La publicó el 13 de mayo de 2026 William Bowling, de V12 Security, junto con un exploit de prueba de concepto y un parche, según Tenable y CloudLinux.
- Dónde está. En una parte del kernel que maneja tráfico cifrado IPsec encapsulado en TCP (el módulo conocido como ESP-in-TCP).
- Qué permite. Es una escalada de privilegios local: alguien que ya logró ejecutar código con un usuario sin permisos puede convertirse en administrador (root) del equipo. Según el aviso de Ubuntu, también podría permitir escapar de un contenedor.
- Gravedad. Puntaje CVSS 3.1 de 7,8 (alta), según los registros citados por Rescana y Safeguard.
- Exploit público. Existe desde el día de su publicación.
Por sí sola, Fragnesia no sirve para entrar a un servidor desde internet: hace falta un primer acceso. Ese es el papel que cumplió PHP2Shell.
Por qué importa ahora
Una falla «solo local» suele parecer menos urgente. Este caso muestra por qué no lo es: combinada con una falla que da acceso remoto, como PHP2Shell, completa la cadena de ataque.
- La cadena ya se usó. Según la firma Dream, cuyos hallazgos verificó la unidad Unit 42 de Palo Alto Networks según The Register, los atacantes entraron con PHP2Shell y usaron Fragnesia para obtener control total de 25 equipos.
- Explotación confirmada. La agencia de ciberseguridad de Estados Unidos (CISA) la agregó el 28 de octubre de 2026 a su catálogo de vulnerabilidades explotadas activamente, con plazo hasta el 31 de octubre para que las agencias federales la corrijan. Según Rescana y Safeguard, CISA menciona expresamente su uso junto con las fallas de PHP.
Estado de los parches al 31 de octubre de 2026
La corrección existe desde mayo en el kernel oficial y la mayoría de las distribuciones ya la publicaron. Pero no está cerrada en todas partes.
- Kernel oficial. Corregido en las ramas estables 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33 y 7.0.10, entre otras, según Rescana y Safeguard, que citan el registro oficial del CVE.
- Ubuntu. Según su página de seguimiento, actualizada el 29 de octubre, los kernels principales de 22.04, 24.04, 25.10 y 26.04 tienen versión corregida (por ejemplo, el kernel genérico de 24.04 desde la versión 6.8.0-124 y el de 26.04 desde la 7.0.0-22); 20.04 y anteriores, con su kernel estándar, no están afectados. Sin embargo:
- algunas variantes de kernel de 24.04 basadas en la versión 6.14 figuran como «fin de soporte» y no recibirán la corrección: hay que migrar a una variante con soporte;
- al menos una variante especializada de 24.04 aún figura como «vulnerable, trabajo en curso».
- Ubuntu indica además que Fragnesia debe corregirse junto con una falla emparentada, Dirty Frag (CVE-2026-43284).
- Red Hat y Debian. Publicaron kernels corregidos entre mayo y junio, según Rescana.
La conclusión práctica: el parche existe para casi todos, pero «existe» no significa «está aplicado». Un kernel corregido solo protege cuando el equipo arranca con él.
Por qué un parche del kernel es distinto
En la primera parte explicamos que instalar una actualización no basta: hay que verificar lo que realmente corre. Con el kernel eso es todavía más claro.
- Requiere reinicio. El kernel nuevo queda instalado, pero el equipo sigue usando el antiguo hasta que se reinicia. Muchos servidores acumulan semanas con un kernel corregido instalado y uno vulnerable en ejecución.
- El reinicio tiene costo. Detener un servidor exige ventana de mantención y plan de vuelta atrás. Existen sistemas de parcheo en caliente (livepatch) que aplican correcciones sin reiniciar, pero no cubren todos los kernels ni todos los casos.
- Variantes y proveedores. Las nubes y los fabricantes de hardware usan sus propias variantes del kernel, que reciben las correcciones a su propio ritmo.
- Fin de soporte. Un kernel o una versión del sistema sin soporte simplemente no recibe el parche.
Qué hacer
- Comprobar el kernel en ejecución, no solo el instalado, y compararlo con la versión corregida que indica la distribución.
- Actualizar y reiniciar en una ventana planificada, con respaldo y camino de vuelta atrás.
- Si no se puede reiniciar de inmediato, evaluar el parcheo en caliente que ofrezca la distribución o el proveedor.
- Mitigación temporal mientras llega el parche: bloquear la carga de los módulos afectados (esp4, esp6 y rxrpc), según Tenable y CloudLinux. Tiene efectos secundarios: deja de funcionar IPsec (VPN de sitio a sitio con strongSwan o Libreswan) y los clientes AFS. CloudLinux advierte no aplicarla en equipos que terminan o transitan túneles IPsec.
- Cerrar la puerta de entrada. Mantener PHP y las aplicaciones web al día reduce la probabilidad de que alguien llegue a usar Fragnesia.
- Migrar lo que está fuera de soporte. Un kernel o un sistema sin soporte quedará expuesto a esta y a las próximas fallas.
- Si hay sospecha de compromiso, conservar evidencia antes de reiniciar: según Rescana y Safeguard, la manipulación que hace este exploit vive en memoria y desaparece al reiniciar.
Qué preguntarle a su proveedor de TI
- ¿Qué versión del kernel corre hoy en nuestros servidores y está corregida contra Fragnesia y Dirty Frag?
- ¿Cuándo fue el último reinicio tras una actualización del kernel?
- ¿Usan parcheo en caliente? ¿Qué cubre y qué no?
- ¿Hay servidores con sistemas o kernels fuera de soporte? ¿Cuándo se migran?
- Si aplicaron mitigaciones temporales, ¿afectan a alguna VPN o servicio?
Preguntas frecuentes
¿Fragnesia permite entrar a mi servidor desde internet? No por sí sola. Necesita que el atacante ya tenga un acceso inicial, por ejemplo mediante una falla web como PHP2Shell. Por eso se usa en cadena.
¿Ya hay parche? Sí para la mayoría de los kernels y distribuciones, desde mayo de 2026. Algunas variantes de kernel siguen sin corrección o están fuera de soporte.
Instalé las actualizaciones, ¿estoy protegido? Solo si el equipo se reinició con el kernel corregido o si un parche en caliente cubrió la falla. Hay que comprobar el kernel en ejecución.
¿La mitigación de bloquear módulos tiene riesgos? Sí: deja sin funcionar IPsec y AFS. Conviene evaluarla caso a caso y retirarla cuando se aplique el parche.
Nota de actualización
Este artículo refleja el estado público al 31 de octubre de 2026. Lo actualizaremos cuando las correcciones pendientes en las variantes de kernel restantes estén disponibles o cambie el estado de la falla.
Fuentes
- Ubuntu, seguimiento de CVE-2026-46300 (actualizado el 29 de octubre de 2026).
- Ubuntu, seguimiento de CVE-2026-43284 (Dirty Frag) (actualizado el 12 de octubre de 2026).
- Rescana, «Linux Kernel Fragnesia CVE-2026-46300 in CISA KEV» (30 de octubre de 2026).
- Safeguard, «Linux Kernel CVE-2026-46300 Is on KEV» (29 de octubre de 2026).
- Tenable, «Fragnesia (CVE-2026-46300): Frequently asked questions» (14 de mayo de 2026).
- CloudLinux, «Fragnesia (CVE-2026-46300) — Mitigation and Kernel Update» (mayo de 2026).
- CISA, catálogo de vulnerabilidades explotadas conocidas, archivo CSV oficial (CVE-2026-46300: incorporada el 28 de octubre de 2026, plazo el 31 de octubre de 2026).
- Dream, «Chained PHP2Shell Exploit Roots 25 Servers» (octubre de 2026).
- The Register, sobre la campaña que comprometió 25 servidores (29 de octubre de 2026).
Sigue la serie
- Parte 1: Seguridad de servidores en la era de la IA
- Ciberseguridad en Chile: PHP2Shell, ransomware y las leyes que vienen
- Lo que no se arregla con un parche: vulnerabilidades de hardware
Contacto
Si quiere revisar el estado de los kernels y los parches de los servidores de su organización, ITLab puede ayudarle. Contáctenos.
¿Necesitas a alguien que se haga cargo de tu tecnología?
Cuéntanos qué necesitas ordenar, proteger o resolver. La primera conversación no tiene costo: evaluamos si nuestro modelo te sirve y cuáles serían los siguientes pasos.
Conversemos sobre tu empresa