Fragnesia en breve: un fallo de mayo que vuelve a ser urgente
Fragnesia es el nombre dado a CVE-2026-46300, un fallo del kernel de Linux divulgado el 13 de mayo de 2026 con una prueba de concepto pública. El defecto cabe en una frase: la función skb_try_coalesce() pierde el marcador que señala un fragmento compartido, de modo que el descifrado ESP se ejecuta en el sitio sobre páginas de la page cache. Un proceso sin privilegios puede entonces modificar en memoria un archivo que debería ser de solo lectura, como /usr/bin/su, y obtener root. La puntuación CVSS 3 es 7.8 y Ubuntu clasifica el fallo con prioridad High. Las correcciones existen desde mayo: AlmaLinux las puso en producción el 16 de mayo de 2026. Lo que cambia a finales de octubre de 2026 es el contexto, porque la CISA incluyó el fallo en su catálogo de vulnerabilidades explotadas el 28 de octubre de 2026.
Lo esencial antes de abrir una terminal
- Local, no remoto — Fragnesia no se ataca desde internet: el atacante ya debe ejecutar código en la máquina. Es el paso que sigue a una intrusión web.
- Kernel activo, no kernel instalado — un paquete al día no protege nada mientras la máquina no haya reiniciado con él.
- Existen kernels corregidos — Ubuntu, Debian, AlmaLinux y CloudLinux han publicado sus versiones; la tabla de abajo las enumera.
- Existe una mitigación, con un precio — bloquear tres módulos (esp4, esp6, rxrpc) cierra la vía, pero corta IPsec y AFS.
- Un puente, no una solución — la mitigación aguanta hasta el reinicio con el kernel corregido, no más allá.
Por qué PHP2Shell cambia el calendario
Una escalada de privilegios local no se dispara sola: primero necesita un punto de entrada. En un servidor de agencia, lo tiene a mano: un sitio PHP. PHP2Shell designa dos fallos del intérprete, CVE-2026-109618 y CVE-2026-109619, que permiten ejecutar código sin autenticación. El webshell corre entonces bajo la cuenta del sitio, sin privilegios. Fragnesia es el siguiente paso: convierte esa cuenta en root. La empresa Dream afirma haber observado esta combinación en una campaña dirigida a cortafuegos; es el relato de un solo proveedor, que la CISA no confirma. Por parte de la CISA, CVE-2026-46300 figura en el catálogo con fecha límite el 31 de octubre de 2026 y un triaje forense pedido a las agencias estadounidenses. Lo principal que debe recordar: corregir PHP cierra la entrada, no la escalada. Un servidor visitado antes de la corrección de PHP sigue siendo peligroso mientras su kernel no esté al día. La guía de PHP2Shell enlazada bajo este artículo detalla la primera parte.
Kernels corregidos por distribución
Desplace la tabla
| Distribución | Kernel corregido (o más reciente) | Conviene saber |
|---|---|---|
| Ubuntu 22.04 LTS | 5.15.0-181.191 | `uname -r` muestra 5.15.0-181-generic |
| Ubuntu 24.04 LTS | 6.8.0-124.124 | `uname -r` muestra 6.8.0-124-generic |
| Ubuntu 25.10 y 26.04 LTS | 6.17.0-35.35 y 7.0.0-22.22 | Una versión por release; la 26.10 no está afectada |
| Debian 12 (bookworm) | 6.1.190-1 | Repositorio security; `uname -v` muestra la versión del paquete |
| Debian 13 (trixie) | 6.12.113-1 | Repositorio security; misma lectura con `uname -v` |
| AlmaLinux 8, 9 y 10 | 4.18.0-553.124.3.el8_10 ; 5.14.0-611.54.5.el9_7 ; 6.12.0-124.56.3.el10_1 | En producción desde el 16 de mayo de 2026 |
| CloudLinux 7h y 8 | 4.18.0-553.124.3.lve.el7h ; 4.18.0-553.124.3.lve.el8 | CloudLinux 9 y 10 reutilizan los kernels de AlmaLinux; comprobar el canal de distribución |
| No afectadas | Ubuntu 20.04 LTS y anteriores, CloudLinux 7 | Nada que corregir en estas versiones |
Kernel instalado no es kernel activo
Es la trampa que convierte un «todo está al día» en un servidor aún vulnerable. Instalar un paquete de kernel deja archivos nuevos en /boot, pero el kernel en memoria sigue siendo el del último arranque. Mientras la máquina no reinicie, apt o dnf pueden mostrar un sistema al día mientras uname -r responde todavía con el número antiguo. Es frecuente en un parque de servidores, por una razón simple: a nadie le gusta reiniciar un servidor que aloja sitios de clientes, así que el reinicio espera. Dos referencias evitan la confusión. En Ubuntu, el número de la tabla se escribe en dos partes: 5.15.0-181.191 corresponde a 5.15.0-181-generic en uname -r. En Debian, uname -r muestra la ABI del kernel, no la versión del paquete; uname -v muestra la versión completa, por ejemplo «Debian 6.1.190-1».
Comprobar la exposición de un servidor en diez minutos
Leer el kernel activo
uname -ry despuésuname -v. Anote el resultado máquina por máquina: es el único valor que cuenta, no el del gestor de paquetes. Compárelo con la tabla de arriba.Listar los kernels instalados
Debian y Ubuntu:
dpkg -l 'linux-image*'. AlmaLinux y CloudLinux:rpm -q kernel. Si hay un kernel corregido instalado perouname -rmuestra otro número, el servidor no ha reiniciado: está expuesto.Detectar reinicios pendientes
En AlmaLinux y CloudLinux,
sudo needs-restarting -rindica si hace falta reiniciar. En Ubuntu, la presencia del archivo/var/run/reboot-requiredseñala lo mismo.Mirar los módulos implicados
lsmod | grep -E 'esp4|esp6|rxrpc'. Un resultado vacío no vuelve seguro el servidor: un módulo ausente puede cargarse bajo demanda. Solo dice que no está cargado en ese instante.Comprobar rxrpc en AlmaLinux 9 y 10
rpm -q kernel-modules-partner. En estas dos versiones, el módulo rxrpc solo está expuesto si este paquete está instalado; AlmaLinux 8 no compila este módulo.Localizar las pasarelas VPN
systemctl list-units | grep -Ei 'strongswan|libreswan|ipsec'. Haga la lista de máquinas que terminan o hacen transitar túneles IPsec, o que usan AFS: la mitigación de más abajo está contraindicada para ellas.
Actualizar el kernel, por entorno
Debian y Ubuntu
sudo apt update && sudo apt full-upgradey despuéssudo reboot. Se usafull-upgradeporque un kernel nuevo llega como un paquete nuevo, queupgradea secas puede dejar de lado.AlmaLinux y otros RHEL
sudo dnf clean metadata && sudo dnf upgradey despuéssudo reboot. Tras el reinicio,rpm -q kerneldebe listar un kernel al menos igual al de la tabla.CloudLinux
En CloudLinux 9 y 10 se aplican los kernels de AlmaLinux: el mismo comando de arriba. En CloudLinux 7h y 8, el kernel corregido es un kernel de CloudLinux distribuido por canal; el artículo de CloudLinux, enlazado al final de la página, dice si su canal ya lo ofrece. Después
sudo yum update 'kernel*'ysudo reboot.Contenedores Docker
Un contenedor no tiene kernel propio: usa el del host. Reconstruir una imagen no corrige nada aquí, mientras que actualizar el host y reiniciarlo protege todos sus contenedores de una vez. Ubuntu menciona además una posible fuga de contenedor: no lo deje para después. Las imágenes PHP que hay que reconstruir por PHP2Shell son tema de otra guía.
Comprobar tras el reinicio
uname -r(yuname -ven Debian) debe mostrar un número igual o superior al de la tabla. Después ejecutesudo systemctl --failedpara detectar los servicios que no han vuelto.
Mitigación o kernel: la decisión depende del rol del servidor
Reiniciar corta los sitios, y la objeción es legítima. La mitigación existe para eso: bloquea la carga de esp4, esp6 y rxrpc, los tres módulos por los que pasa el fallo, sin reiniciar. Su precio es concreto. ESP es el protocolo de cifrado de IPsec y rxrpc sirve a AFS; si el servidor termina o hace transitar túneles IPsec (strongSwan, Libreswan) o monta AFS, la mitigación los rompe, y AlmaLinux lo dice sin rodeos. Regla simple: en un servidor web sin VPN, mitigación ya y kernel en la próxima ventana; en una pasarela VPN, kernel corregido en una ventana de reinicio, sin mitigación. En ambos casos, la mitigación es solo un puente hasta el reinicio con el kernel corregido. AlmaLinux precisa también que la mitigación publicada para Dirty Frag ya cubre Fragnesia: si está aplicada, no hay nada que añadir.
Aplicar la mitigación, comprobarla, deshacerla
Escribir el archivo y descargar los módulos
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
El comando crea/etc/modprobe.d/fragnesia.conf, que prohíbe la carga de los tres módulos, y después descarga los que estaban cargados.Comprobar
lsmod | grep -E 'esp4|esp6|rxrpc'no debe devolver nada. La mitigación sobrevive al reinicio mientras el archivo exista.Vaciar la page cache si la máquina pudo ser atacada
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches". Los binarios se recargan desde el disco. Si quiere conservar pruebas, haga primero las comprobaciones de la sección siguiente.Deshacer la mitigación
Una vez reiniciada la máquina con el kernel corregido:
sudo rm /etc/modprobe.d/fragnesia.conf. Si ya había una mitigación de Dirty Frag con otro nombre de archivo, sigue su propio ciclo.
KernelCare, para los servidores que no se pueden reiniciar
Si el servidor usa KernelCare (parcheo del kernel en caliente), kcarectl --update aplica la corrección sin reiniciar, y kcarectl --patch-info | grep CVE-2026-46300 confirma que está presente. CloudLinux indica un despliegue completo para las variantes AlmaLinux ELS y FIPS, la familia EL8, Debian 11 y 12 y Ubuntu Jammy, sin citar explícitamente CloudLinux 9 y 10 estándar. No generalice: compruebe por distribución y, si el comando no devuelve nada, recurra a la mitigación o al kernel.
Buscar rastros antes de reiniciar
Un servidor parcheado desde mayo no está afectado; uno que nunca ha reiniciado sí lo está, y si alojó un sitio PHP vulnerable, pudo ser visitado. La alteración se produce en la page cache: no se escribe necesariamente en disco, y un reinicio o drop_caches la borra. Haga, pues, sus comprobaciones primero. Tres pistas. Los archivos .php recientes bajo las raíces web: sudo find /var/www /home -name '*.php' -mtime -7 -type f, a adaptar a sus rutas. Los binarios setuid inesperados: sudo find / -xdev -perm -4000 -type f -mtime -30. La integridad de los paquetes: rpm -V util-linux en la familia RHEL, sudo debsums -s util-linux en Debian y Ubuntu tras apt install debsums; el paquete util-linux aporta /usr/bin/su, el objetivo citado por AlmaLinux. Un resultado sospechoso no se limpia a mano: aísle la máquina y trátela como comprometida.
Para una agencia: una ventana común, no un servidor cada vez
El tiempo no se pierde en el comando, sino en saber qué máquina aloja a qué clientes, cuál es una pasarela VPN y cuándo puede reiniciar. Elabore una tabla por servidor: kernel activo, kernel instalado, rol (web, VPN, base de datos), mitigación aplicada o no. Clasifique después en tres lotes: servidores web simples, mitigación inmediata y kernel en la ventana; pasarelas, kernel en la ventana sin mitigación; máquinas ya al día, simple comprobación del kernel activo. Avise a los clientes una sola vez, en una ventana común, en lugar de máquina por máquina. El método de reinicio de un VPS que aloja sitios de clientes está detallado en la guía de PwnEscape y Vghost enlazada bajo este artículo, no hace falta repetirlo aquí. Esta guía se entrega tal cual: la administración de sus servidores sigue siendo responsabilidad suya, sin soporte por nuestra parte.
La documentación oficial
Ficha de Ubuntu de CVE-2026-46300: https://ubuntu.com/security/CVE-2026-46300
Seguimiento de seguridad de Debian: https://security-tracker.debian.org/tracker/CVE-2026-46300
Aviso de AlmaLinux sobre Fragnesia: https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
Artículo de CloudLinux (kernels y KernelCare): https://blog.cloudlinux.com/fragnesia-mitigation-and-kernel-update
Alerta de la CISA del 28 de octubre de 2026: https://www.cisa.gov/news-events/alerts/2026/10/28/cisa-adds-two-known-exploited-vulnerabilities-catalog
Crónica de SecurityWeek sobre la cadena PHP2Shell: https://www.securityweek.com/china-linked-hackers-exploit-php2shell-to-root-firewalls/
Corrección upstream en el kernel: https://git.kernel.org/linus/f84eca5817390257cef78013d0112481c503b4a3
