Publicado el por Félix Molinuevo

Fragnesia (CVE-2026-46300) y PHP2Shell: que revisar en Linux

Introducción

El 28 de octubre de 2026, la agencia de ciberseguridad de Estados Unidos (CISA) sumó la vulnerabilidad CVE-2026-46300, conocida como Fragnesia, a su catálogo de vulnerabilidades explotadas, «based on evidence of active exploitation» (por evidencia de explotación activa). [1]

No es una falla nueva: es nueva en el catálogo de CISA. Ubuntu publicó su ficha el 23 de mayo de 2026 y las principales distribuciones tienen kernels corregidos desde mayo. [2][3][4] Lo que cambió es que ahora hay explotación documentada.

Esta nota continúa la que publicamos sobre PHP2Shell (PHP2Shell: qué hacer si su sitio usa PHP). Allí dijimos que había que actualizar PHP. Ahora agregamos una segunda tarea: actualizar el kernel del servidor y reiniciarlo, en un orden que no borre lo que usted necesita revisar.

Qué pasó

El 26 de octubre, la empresa Dream Research publicó el análisis de una campaña que combinó PHP2Shell con Fragnesia. [5] PHP2Shell le dio al atacante la posibilidad de ejecutar comandos como el usuario nobody, sin privilegios. Fragnesia convirtió ese acceso limitado en acceso de administrador (root): alteró el archivo /etc/pam.d/su para que su root funcionara sin contraseña.

Es importante el contexto: los equipos atacados eran firewalls de un fabricante que Dream no identifica, con PHP 8.0.30. En total fueron 25 equipos (24 firewalls y un servidor de gestión interno). [5] No hay, hasta hoy, un caso documentado de esta cadena contra servidores web Linux comunes. Lo que sí sabemos es que las dos piezas existen por separado en muchos servidores: PHP expuesto a internet y kernels sin actualizar.

Conceptos clave

Es una falla local, no remota

Fragnesia no se explota desde internet por sí sola. El atacante tiene que tener antes algún código corriendo en el servidor: por ejemplo, una webshell subida a través de una falla de PHP o un acceso SSH con credenciales robadas. [2][6] Por eso se combina con fallas como PHP2Shell. CVSS 3.1: 7,8 (alta). [2] El código de prueba es público. [7]

Afecta al kernel, no a PHP

Actualizar PHP corta la puerta de entrada que usó esta campaña, pero no corrige Fragnesia. Si mañana aparece otra forma de ejecutar código en el servidor, un kernel sin corregir permite el mismo salto a root.

Un kernel instalado pero no arrancado no protege

El kernel corregido solo protege después de reiniciar el servidor con esa versión. Ubuntu lo indica de forma explícita: después de instalar la actualización del kernel, «a reboot is required». También aclara que las actualizaciones automáticas (unattended-upgrades) instalan el parche, «but a reboot is still required». [8] Un servidor que se actualiza solo puede tener el kernel corregido en disco desde mayo y seguir ejecutando el vulnerable.

Por qué hay que mirar antes de reiniciar

Fragnesia no modifica el archivo en el disco. Modifica la copia que el sistema guarda en memoria (la caché de páginas): «The page cache modification is not backed to disk; the on-disk binary is untouched». [7] Mientras el servidor esté encendido, todos los programas ven la versión alterada. Al reiniciar, esa copia desaparece: se va la puerta trasera y también la evidencia de que existió.

Por eso el orden importa: primero verificar, después actualizar y recién después reiniciar.

Qué revisar, en este orden

Los comandos siguientes son para quien administra el servidor. Se ejecutan como root o con sudo. Son indicios, no pruebas definitivas: un resultado limpio no garantiza que el servidor no haya sido comprometido, y un servidor que ya se reinició no conserva este tipo de evidencia.

Paso 1. Ver qué kernel está corriendo y cuáles están instalados

# Kernel en ejecución
uname -r

# Kernels instalados (Debian / Ubuntu)
dpkg -l 'linux-image*' | grep ^ii

# Kernels instalados (RHEL, AlmaLinux, Rocky)
rpm -q kernel

El primer y el segundo comando son los que indica Ubuntu. [8] Compare la versión en ejecución con la tabla de abajo. Si la versión corregida figura instalada pero uname -r muestra una anterior, el servidor sigue vulnerable hasta reiniciar.

DistribuciónKernel corregido (o posterior)Fuente
Ubuntu 26.04 LTS7.0.0-22.22[2]
Ubuntu 25.106.17.0-35.35[2]
Ubuntu 24.04 LTS6.8.0-124.124 (HWE 6.17: 6.17.0-35.35~24.04.1)[2]
Ubuntu 22.04 LTS5.15.0-181.191 (HWE 6.8: 6.8.0-124.124~22.04.1)[2]
Ubuntu 20.04 LTS (kernel 5.4)No afectado[2]
Debian 13 (trixie)6.12.90-1[3]
Debian 12 (bookworm)6.1.174-1[3]
Debian 11 (bullseye, LTS)5.10.257-1[3]
AlmaLinux 8 / 9 / 104.18.0-553.124.3.el8_10 / 5.14.0-611.54.5.el9_7 / 6.12.0-124.56.3.el10_1[9]
RHEL 8, 9, 10Corregido; ver la ficha de Red Hat por versión [NO VERIFICADO: números por rama][4]

Los kernels de proveedores de nube (por ejemplo, linux-aws o linux-azure en Ubuntu) tienen números propios; están en la ficha de Ubuntu. [2]

Para saber si el sistema pide reinicio:

# Ubuntu: este archivo suele existir cuando hay una actualización pendiente de reinicio
ls /var/run/reboot-required

# Debian / Ubuntu con needrestart instalado
sudo needrestart -k

# RHEL, AlmaLinux, Rocky (dnf-utils)
sudo dnf needs-restarting -r

needrestart -k revisa si el kernel en ejecución quedó desactualizado [12]; dnf needs-restarting -r informa solo si hace falta reiniciar [13]. El archivo /var/run/reboot-required es orientativo: puede no existir en Debian aunque haya un kernel nuevo pendiente. [NO VERIFICADO: comportamiento de /var/run/reboot-required en Debian]

Paso 2. Antes de actualizar o reiniciar, buscar indicios de alteración

Primero, la modificación que documentó Dream en /etc/pam.d/su: [5]

grep -n pam_permit /etc/pam.d/su /etc/pam.d/su-l 2>/dev/null

En la configuración por defecto de su distribución no suele aparecer pam_permit en su; compare con una copia limpia. Si aparece y no sabe por qué, no reinicie y siga leyendo.

Segundo, comparar la copia en memoria con la copia en disco. Una lectura normal pasa por la caché; una lectura con O_DIRECT va directo al disco. Si difieren, algo cambió la copia en memoria sin escribir el disco, que es la firma de este tipo de falla: [6]

for f in /etc/pam.d/su /etc/pam.d/sudo /usr/bin/su /usr/bin/sudo; do
  [ -f "$f" ] || continue
  a=$(sha256sum "$f" | cut -c1-64)
  b=$(dd if="$f" iflag=direct bs=4096 status=none | sha256sum | cut -c1-64)
  [ "$a" = "$b" ] && echo "OK: $f" || echo "DIFERENTE: $f"
done

La lectura O_DIRECT puede no funcionar en algunos sistemas de archivos, y en otros casos el kernel puede resolverla a través de la caché, lo que haría que la comparación no detecte nada. [14] [NO VERIFICADO: qué sistemas de archivos concretos soportan O_DIRECT] Según un análisis secundario, un atacante también puede forzar que la caché se descarte. [10] Por eso «OK» no es una garantía.

Las herramientas de verificación de paquetes (rpm -V, dpkg --verify, debsums) pueden ayudar, pero /etc/pam.d/su es un archivo de configuración y los cambios legítimos del administrador también aparecen. No las use como prueba única. [NO VERIFICADO: comportamiento de estas herramientas frente a la caché alterada]

Si encuentra una diferencia: no reinicie, guarde una copia del archivo (cp /etc/pam.d/su /root/evidencia-pam-su), los registros de acceso y la lista de procesos, y trate el servidor como comprometido. [6]

Tercero, lo que un atacante con root deja en disco y sí sobrevive al reinicio. Dream encontró una webshell PHP de 103 bytes en un directorio público y un túnel SSH inverso registrado como servicio de systemd y en rc.local. [5] Revise archivos PHP recientes en los directorios web, servicios de systemd que no reconozca, /etc/rc.local y las claves SSH autorizadas.

Paso 3. Actualizar el kernel

# Debian / Ubuntu
sudo apt update && sudo apt full-upgrade

# RHEL, AlmaLinux, Rocky
sudo dnf upgrade --refresh kernel

[8][9] Aproveche para confirmar que PHP también está corregido (8.2.35, 8.3.36, 8.4.27 u 8.5.12, o el paquete corregido de su distribución), como explicamos en la nota de PHP2Shell.

Paso 4. Reiniciar y confirmar

sudo reboot
# después del reinicio
uname -r

La versión que muestre uname -r tiene que ser igual o posterior a la de la tabla.

Si no puede reiniciar todavía

Red Hat publicó una mitigación temporal para Fragnesia que bloquea los módulos del kernel esp4 y esp6. [4] Ubuntu publicó pasos equivalentes para Dirty Frag, una falla relacionada que usa los mismos módulos [8]; para Fragnesia nos basamos en la guía de Red Hat. La mitigación tiene un costo: deja de funcionar IPsec, que usan VPN como StrongSwan. Red Hat sugiere comprobar primero si están en uso:

lsmod | grep -E 'esp4|esp6'

En Ubuntu y Debian, con el formato de los pasos que Ubuntu publicó para Dirty Frag, aplicado a esp4 y esp6:

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/fragnesia.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/fragnesia.conf
sudo update-initramfs -u -k all
sudo rmmod esp4 esp6 2>/dev/null
grep -qE '^(esp4|esp6) ' /proc/modules && echo "Modulos cargados" || echo "Modulos NO cargados"

En RHEL, AlmaLinux y Rocky, según Red Hat:

printf 'install esp4 /bin/false\ninstall esp6 /bin/false\n' | sudo tee /etc/modprobe.d/dirtyfrag.conf
sudo rmmod esp4 esp6 2>/dev/null; true

Si necesita mantener IPsec, Red Hat ofrece una alternativa: desactivar los espacios de nombres de usuario (user namespaces). Afecta a contenedores sin root y a Flatpak. [4]

echo "user.max_user_namespaces=0" | sudo tee /etc/sysctl.d/dirtyfrag.conf
sudo sysctl --system

Algunos avisos agregan echo 3 > /proc/sys/vm/drop_caches para limpiar la caché. [11] Eso también borra la evidencia: hágalo solo después del Paso 2.

Esto es un parche provisorio. La solución es el kernel corregido y el reinicio; cuando lo tenga, puede quitar el bloqueo.

Si su empresa no administra el servidor

Si su agencia o estudio contable usa un hosting o un servidor administrado por terceros, no necesita ejecutar estos comandos. Pregunte a su proveedor, y pida la respuesta por escrito:

  1. ¿Qué versión de kernel está ejecutando hoy el servidor (resultado de uname -r)?
  2. ¿Cuándo se reinició por última vez después de instalar el kernel corregido?
  3. ¿Revisaron indicios de alteración antes de reiniciar, y cómo lo verificaron?
  4. ¿PHP tiene las correcciones de PHP2Shell, con qué paquete y desde qué fecha?

«Estamos al día» no es una respuesta suficiente. Una buena respuesta incluye versiones, fechas y el método de verificación. En hostings compartidos, el kernel lo administra el proveedor, no usted.

Conclusión

Fragnesia no es nueva, pero ahora forma parte de ataques reales. Para servidores Linux con PHP expuesto a internet, el orden recomendado es: verificar, actualizar y reiniciar. Instalar el kernel sin reiniciar deja el servidor igual que antes, y reiniciar sin mirar puede borrar la única evidencia de un compromiso.

En AXR Global instalamos, configuramos y mantenemos servidores Linux, con soporte para Apache, PHP, MySQL y PostgreSQL. Si necesita revisar sus servidores, puede consultarnos.

Fuentes

  1. CISA, alerta del 28/10/2026: https://www.cisa.gov/news-events/alerts/2026/10/28/cisa-adds-two-known-exploited-vulnerabilities-catalog
  2. Ubuntu, CVE-2026-46300: https://ubuntu.com/security/CVE-2026-46300
  3. Debian Security Tracker, CVE-2026-46300: https://security-tracker.debian.org/tracker/CVE-2026-46300
  4. Red Hat, RHSB-2026-003: https://access.redhat.com/security/vulnerabilities/RHSB-2026-003
  5. Dream Research, 26/10/2026: https://dreamgroup.com/blog/chained-php2shell-exploit-roots-25-servers
  6. hol.org (secundaria), 28/10/2026: https://hol.org/blog/cve-2026-46300-fragnesia-linux-kernel-cisa-kev-root
  7. V12 Security, README del PoC: https://github.com/v12-security/pocs/blob/main/fragnesia/README.md
  8. Ubuntu, Dirty Frag (falla relacionada; no menciona Fragnesia): https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available
  9. AlmaLinux, 13/05/2026: https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
  10. getrff (secundaria): https://getrff.com/blog/fragnesia-cve-2026-46300-check-before-reboot/
  11. CERT Santé (Francia), 15/05/2026: https://cyberveille.esante.gouv.fr/alertes/linux-cve-2026-46300-2026-05-15
  12. needrestart(1), Debian: https://manpages.debian.org/trixie/needrestart/needrestart.1.en.html
  13. DNF needs-restarting (dnf-plugins-core): https://dnf-plugins-core.readthedocs.io/en/latest/needs_restarting.html
  14. open(2), Linux man-pages: https://man7.org/linux/man-pages/man2/open.2.html
  15. AXR Global, PHP2Shell: https://axrglobal.com/php2shell-que-hacer-si-su-sitio-usa-php/