PHP2Shell Moodle: Guía de acción para el administrador de tu AVA

PHP2Shell Moodle es el tipo de alerta que no espera la próxima ventana de mantenimiento: dos fallos críticos en el propio PHP permiten ejecutar código en el servidor sin necesidad de autenticación, y toda plataforma Moodle (AVA) se ejecuta sobre PHP. En esta guía, muestro, en el orden en que lo hago en el terminal, cómo verificar la versión, aplicar el parche, reiniciar PHP-FPM y buscar señales de intrusión.

TL;DR

• PHP2Shell es el apodo de dos fallos en PHP (CVE-2026-109618 y CVE-2026-109619), con una puntuación CVSS 4.0 de 9.2 y explotación sin autenticación. Moodle no tiene la culpa, pero se ve afectado porque se ejecuta sobre PHP.
• La corrección se publicó el 21/10/2026 en las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Del 7.4 al 8.1 solo hay backports mínimos de código fuente; del 5.4 al 7.3 no hay corrección.
• Actualizar el paquete no es suficiente: es necesario reiniciar PHP-FPM (o Apache, si usa mod_php) para que los workers carguen el nuevo binario.
• Las mitigaciones por php.ini reducen el riesgo, pero no lo resuelven. Hubo un intento de explotación ya el 17/10, así que investigue a partir de esa fecha.
• En el escenario PHP2Shell Moodle más difícil, la plataforma AVA está en PHP 8.1 o anterior, y el problema se convierte en un proyecto: actualizar PHP requiere verificar la compatibilidad de la versión de Moodle.

¿Qué es PHP2Shell y por qué afecta a su Moodle?

Trabajo con Moodle desde hace más de 15 años, y casi toda vulnerabilidad que quita el sueño a un gestor de EAD está en un plugin, tema o configuración. PHP2Shell es diferente. El fallo está en el intérprete PHP, la capa que ejecuta cada página de la plataforma AVA. No importa si su Moodle está en la última versión: si el PHP subyacente está vulnerable, el servidor está expuesto.

Por eso, cuando alguien pregunta sobre PHP2Shell Moodle en un foro de administradores, la respuesta correcta comienza en el servidor, no en el panel de la plataforma AVA.

Los dos fallos en una frase cada uno

• CVE-2026-109618 (OOM Corruption): cuando una asignación de memoria falla en medio de la inicialización de la solicitud, PHP luego limpia este estado incompleto como si fuera válido. De ahí surge la ejecución remota de código (RCE, por sus siglas en inglés).
• CVE-2026-109619 (Stale Global State): un use-after-free, es decir, el uso de memoria que ya ha sido liberada. Restos de una solicitud son reutilizados por la siguiente solicitud en el mismo worker. PHP también enumera la fuga de memoria como un impacto confirmado.

Según Tenable, ambos recibieron una puntuación de 9.2 en CVSS 4.0 por el equipo de seguridad de PHP. Los identificadores que circularon antes del anuncio mostraban un 10.0, que la PHP Foundation afirma ser incorrecto.

La cronología que importa a quien administra una plataforma AVA

• 17/10/2026: Amazon registró un intento de explotación en su honeypot MadPot, cuatro días antes de la divulgación pública.
• 20/10/2026: los detalles se filtraron en las redes sociales antes de la fecha acordada (22/10), como relató watchTowr. PHP adelantó el lanzamiento.
• 21/10/2026: se publican las versiones corregidas, y la CISA, agencia de ciberseguridad de EE. UU., solicita una actualización inmediata.
• 23/10/2026: PHP publica una alerta adicional, el CVE-2026-115560, que explico más abajo.

La escala también asusta. Palo Alto Networks contabilizó más de 22,6 millones de instancias expuestas potencialmente vulnerables, según TechTarget. Esto significa que PHP2Shell Moodle afecta a todo servidor de plataforma AVA con IP pública.

PHP2Shell Moodle y las versiones en riesgo

La primera pregunta que recibo es si el Moodle de la institución está vulnerable. La respuesta depende de PHP, no de Moodle. La siguiente tabla cruza la rama de PHP con el estado de la corrección y con las versiones de Moodle que aceptan ese PHP, según la documentación oficial de Moodle.

Rama de PHP	Estado de PHP2Shell	Moodle que se ejecuta en este PHP	Qué hacer
8.5	Corregido en 8.5.12	Consulte el soporte de su versión en las notas de lanzamiento	Actualizar a 8.5.12 y reiniciar
8.4	Corregido en 8.4.27	5.0, 5.1 y 5.2	Actualizar a 8.4.27 y reiniciar
8.3	Corregido en 8.3.36	4.5 LTS, 5.0, 5.1 y 5.2	Actualizar a 8.3.36 y reiniciar
8.2	Corregido en 8.2.35 (rama finaliza el 31/12/2026)	4.5 LTS, 5.0 y 5.1	Actualizar ahora y planificar la salida de 8.2
7.4 a 8.1	Solo backports mínimos de código fuente	4.5 LTS (en 8.1) y versiones antiguas	Paquete de la distribución con backport, o migrar de PHP
5.4 a 7.3	Sin corrección	Moodle muy antiguo	Aislar de internet y migrar

De esta tabla se extraen dos lecciones. La primera: un Moodle 4.5 LTS en PHP 8.1, combinación común en instituciones que realizaron la última actualización con prisas, ya no tiene una versión oficial de PHP. La solución es pasar a 8.2 o 8.3, que 4.5 acepta. La segunda: un Moodle anterior a 4.5, que solo se ejecuta en PHP 8.1 o más antiguo, transforma el PHP2Shell Moodle en un proyecto de actualización de versión, no en un parche de diez minutos.

Paso 1: Descubra qué PHP usa realmente su Moodle

Antes de cualquier corrección de PHP2Shell Moodle, necesita saber qué binario atiende al sitio. El error más común aquí es ejecutar php -v en el terminal y dar el asunto por zanjado. php -v muestra el PHP de línea de comandos (CLI). El sitio es servido por PHP-FPM o por el módulo de Apache, que pueden tener otra versión y otro php.ini. Datadog hace exactamente esta advertencia.

Tres formas de verificar el PHP que sirve a la plataforma AVA:

1. Desde el propio Moodle: en Administración del sitio > Servidor > Información de PHP (el admin/phpinfo.php). La primera línea muestra la versión, y el campo Server API indica si es FPM/FastCGI o Apache 2.0 Handler (mod_php).
2. Desde el gestor de paquetes: en Debian y Ubuntu, dpkg -l | grep php8 lista la versión exacta de cada paquete instalado, incluyendo el php8.x-fpm.
3. Desde el proceso en ejecución: ps aux | grep php-fpm muestra qué pool está en funcionamiento. Si aparecen dos ramas (por ejemplo, 8.1 y 8.3), confirme en el vhost de Nginx o Apache qué socket usa Moodle.

Un detalle influye en la prioridad: el riesgo es mayor con mod_php. Tenable informa que, en este modo, existe un exploit demostrado que se activa con una solicitud no autenticada antes de que se ejecute cualquier código de la aplicación. PHP-FPM, php-cgi, FrankenPHP y LiteSpeed también están en el alcance. Nadie está exento, pero quienes ejecutan Moodle en Apache con mod_php pasan al principio de la lista: en PHP2Shell Moodle, mod_php es la prioridad número uno.

Paso 2: Aplique el parche de PHP2Shell Moodle sin romper la plataforma AVA

Antes de tocar en producción, haga dos cosas que llevan diez minutos: una copia de seguridad de la base de datos y de config.php, y una anotación de los módulos PHP instalados (php -m). La actualización de seguridad dentro de la misma rama (8.3.x a 8.3.36, por ejemplo) rara vez rompe Moodle, pero sin este registro no sabrá qué cambió si algo sale mal.

Servidor propio (Debian, Ubuntu, RHEL)

Actualice los paquetes de la rama que ya usa, en FPM y en CLI. El cron de Moodle se ejecuta a través de PHP CLI y necesita el binario corregido tanto como el sitio. Atención a un detalle: distribuciones como Debian, Ubuntu y Red Hat suelen aplicar el backport de la corrección sin cambiar el número de versión. Red Hat, por ejemplo, publicó el boletín RHSB-2026-013 cubriendo los tres CVEs. En estos casos, consulte el changelog del paquete o el rastreador de seguridad de la distribución, y no solo php -v.

Moodle en contenedor Docker

Actualizar el host no corrige el contenedor. Es necesario cambiar la imagen base por una con el PHP corregido, reconstruir y volver a desplegar. Una imagen con etiqueta fija antigua es el caso clásico del servidor que todo el mundo cree que está actualizado.

Alojamiento compartido o panel (cPanel, Plesk, HestiaCP)

Usted depende del proveedor. Abra una incidencia sobre PHP2Shell Moodle solicitando, por escrito, la versión exacta de PHP que sirve a su dominio y la confirmación del reinicio de los workers. Si el panel permite elegir el PHP por dominio, seleccione la rama corregida y pruebe la plataforma AVA justo después.

PHP 8.1 o más antiguo

Aquí no existe un atajo seguro. Las opciones son tres: usar un paquete de distribución o de proveedor LTS que haya realizado el backport, compilar PHP con los backports mínimos publicados por el proyecto, o migrar a un PHP soportado. Para quienes están en Moodle 4.5 LTS, la migración natural es a PHP 8.3. Para versiones más antiguas, el camino pasa por migrar Moodle de servidor ya con la nueva pila, verificando los requisitos de servidor para Moodle 5.x.

Paso 3: Reinicie PHP-FPM y todo lo que ejecute PHP

Este es el paso que más veo que se olvida. Sin reinicio, la corrección de PHP2Shell Moodle solo queda en el disco. PHP-FPM mantiene los workers vivos entre solicitudes, y mientras no se vuelvan a crear, seguirán ejecutando el código antiguo cargado en memoria. watchTowr es directa: reinicie todo worker PHP después de actualizar.

En la práctica, el reinicio de PHP2Shell Moodle cubre:

• PHP-FPM: systemctl restart php8.3-fpm (cambie por su rama). Prefiera restart a reload en este caso, para garantizar que todos los procesos se vuelvan a crear.
• Apache con mod_php: reinicie Apache, porque PHP reside dentro de él.
• Contenedores: recree el contenedor con la nueva imagen. Reiniciar el contenedor antiguo no cambia el binario.
• Workers de cola y cron: los procesos largos de CLI también necesitan ser reiniciados.

Después del reinicio, vuelva a Información de PHP en Moodle y confirme la versión. Pruebe el inicio de sesión, el envío de archivos en una tarea y un cuestionario. El reinicio de FPM interrumpe las solicitudes en curso durante unos segundos; fuera del horario de exámenes, esto no es un problema. En semana de evaluación, avise a la coordinación y elija la madrugada, pero no lo posponga para después del examen.

Mitigaciones temporales: qué hacen y qué no hacen

Si no puede actualizar hoy, el aviso de PHP enumera ajustes de configuración. Sirven para superar las horas entre la alerta PHP2Shell Moodle y la ventana de actualización. Todas las fuentes técnicas que consulté, desde Tenable hasta Datadog, repiten la misma advertencia: los ajustes reducen la exposición, pero no hacen que la instalación sea segura.

Los tres ajustes

• memory_limit=-1, definido de forma que la aplicación no pueda sobrescribir, contra el CVE-2026-109618.
• session.upload_progress.enabled=0, contra el CVE-2026-109619.
• fatal_error_backtraces=0, también contra el CVE-2026-109619, solo en PHP 8.5.

Después de cualquier cambio, reinicie los workers, como en el paso 3.

Qué cambia en Moodle

Moodle eleva su propio límite de memoria en operaciones pesadas, como la copia de seguridad y la restauración de cursos. Por eso, un memory_limit común en php.ini no es suficiente: en PHP-FPM, use php_admin_value[memory_limit] = -1 en el pool, un valor que la aplicación no puede alterar. El precio es que un script descontrolado puede consumir toda la RAM. Compense limitando el número de workers (pm.max_children) y la memoria del contenedor o del cgroup, recordando que el propio PHP dice que esto es una frontera de disponibilidad, no una mitigación completa.

El progreso de subida (upload progress) es una característica nativa de PHP de la que Moodle no depende para el envío de archivos. Desactivarlo suele ser seguro, pero pruebe el envío de una tarea después.

El WAF ayuda, pero tiene límites

Cloudflare publicó reglas de WAF para los vectores conocidos y lo denomina un paliativo, válido solo para el tráfico que pasa por ella. Un atacante que descubre la IP de origen del servidor puede eludirlo.

¿Y el CVE-2026-115560?

El 23/10/2026, PHP publicó una alerta informativa, el CVE-2026-115560. Solo se aplica cuando la aplicación define el session.serialize_handler como php_binary o php_serialize, cambia a php en tiempo de ejecución antes de session_start() y mantiene el progreso de subida activado. PHP califica esta configuración como improbable en la práctica, no hay explotación reportada y la corrección llegará en la próxima versión regular, conforme a The Hacker News. La mitigación es la misma: session.upload_progress.enabled=0. Quien ya la aplicó no necesita hacer nada más.

Paso 4: Busque señales de intrusión en el servidor de Moodle

Actualizar cierra la puerta, pero no dice si alguien entró antes. Como Amazon vio un intento de explotación ya el 17/10, la recomendación de Tenable es investigar a partir de esa fecha, y no de la divulgación. Esta es la lista de verificación de PHP2Shell Moodle que sigo.

En el sistema operativo

• Procesos hijos de PHP: Huntress recomienda buscar php-fpm, php-cgi, httpd o apache2 iniciando sh, bash, python, perl, curl, wget o nc. Datadog denomina al shell abierto por el worker PHP la evidencia más directa de una explotación exitosa.
• Comandos de reconocimiento ejecutados por el usuario del servidor web, como whoami, id y uname -a, y patrones de reverse shell como /dev/tcp/, mkfifo y fsockopen.
• Cron y cuentas: crontab -l -u www-data y nuevos usuarios en el sistema.

En Moodle

• Nuevos archivos PHP: find /caminho/do/moodle -name '*.php' -newermt 2026-10-17 lista lo que fue creado o modificado después del 17/10. Compare con las actualizaciones que usted mismo realizó.
• El moodledata: la carpeta de datos nunca debería contener un archivo .php ejecutable. Cualquiera que esté allí es sospechoso.
• Administradores: verifique en Administración del sitio > Usuarios > Permisos > Administradores del sitio si apareció alguien nuevo, y revise las cuentas creadas recientemente.
• Plugins desconocidos: compare las carpetas local/, mod/ y blocks/ con la lista de la Vista general de plugins.

En los logs

Datadog enumera señales útiles en el log de errores: Allowed memory size of 16777216 bytes exhausted con Unknown on line 0, y crashes exit signal Segmentation fault (11) en Apache. En el log de acceso, busque envíos multipart con los campos PHPSESSID y PHP_SESSION_UPLOAD_PROGRESS. En la investigación de PHP2Shell Moodle, un error de memoria aislado no prueba un ataque; varios juntos, en secuencia, merecen investigación.

Si encuentra señales de compromiso, aísle el servidor y preserve los logs antes de limpiar cualquier cosa. Reinstalar por encima borra la evidencia y no garantiza que el intruso haya salido.

Errores comunes y cuándo no hacerlos

En la respuesta a PHP2Shell Moodle, algunas decisiones parecen prudentes y empeoran la situación. Las que más veo:

• Confiar solo en php -v. El CLI no es necesariamente el PHP del sitio.
• Actualizar y no reiniciar. El paquete nuevo queda en el disco y el worker antiguo sigue atendiendo.
• Saltar de rama de PHP con prisas. No cambie 8.1 por 8.4 en un Moodle 4.5 LTS solo para tener el más nuevo: el 4.5 acepta PHP hasta el 8.3. Dentro de la misma rama, actualice hoy; un cambio de rama requiere pruebas en un entorno de preproducción.
• Tratar la mitigación como solución. memory_limit=-1 y el progreso de subida desactivado compran tiempo, no seguridad.
• Apagar la plataforma AVA sin comunicar. La CISA recomienda retirar de línea los sistemas que no pueden ser actualizados o que ejecutan PHP 8.1 o anterior. Si es su caso, hágalo, pero con aviso a alumnos y tutores y una fecha de retorno.
• Olvidar los entornos olvidados. Preproducción, Moodle antiguo de archivo, subdominio de prueba: todo lo que está en internet con PHP entra en el inventario de PHP2Shell Moodle antes de que dé el caso por cerrado.

Cómo Agathas Web resuelve esto

PHP2Shell Moodle expone el punto débil de quienes alojan una plataforma AVA sin un equipo dedicado: la corrección existe, pero alguien necesita saber que se publicó, aplicarla en el binario correcto, reiniciar los workers, probar la plataforma AVA e investigar si hubo intrusión. En el alojamiento Moodle gestionado de Agathas Web, ese trabajo es nuestro.

Lo que está incluido en la práctica:

• Pila mantenida por quienes operan Moodle: PHP-FPM con pool dedicado por instancia, OPcache, Redis, MariaDB y Nginx optimizados para Moodle, con PHP en la rama compatible con su versión de la plataforma AVA.
• Actualización de seguridad con pruebas: parche aplicado, workers reiniciados y verificación de la plataforma AVA después. Cambios mayores, como el cambio de rama de PHP o de versión de Moodle, pasan por un entorno de staging antes de tocar la producción.
• Capas de protección: Cloudflare WAF con protección contra DDoS, Fail2ban y rate limit en las rutas críticas.
• Monitorización y copia de seguridad: Sentry, Grafana y UptimeRobot sobre la plataforma, copia de seguridad incremental de la base de datos cada 15 minutos y restauración probada.
• Soporte senior en portugués: canal directo por WhatsApp y por correo electrónico, con respuesta en hasta 15 minutos para incidentes críticos.

Cómo funciona la contratación: usted habla con el equipo, realizamos un diagnóstico del entorno actual (versión de Moodle, PHP, plugins y tamaño del moodledata) y planificamos la migración a nuestra pila. Si su Moodle está atrapado en un PHP antiguo, la migración resuelve ambas cosas a la vez. Si aún está decidiendo entre mantener un servidor propio o externalizar, esta comparativa de VPS para Moodle o alojamiento gestionado muestra el coste real de cada camino.

Conclusión: qué hacer hoy

La hoja de ruta de PHP2Shell Moodle se puede completar en una tarde: confirme el PHP que sirve a la plataforma AVA, actualice a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 (o al paquete con backport de su distribución), reinicie PHP-FPM y el cron e investigue desde el 17/10. Si su servidor está en PHP 8.1 o anterior, trátelo como una migración urgente, no como un parche.

Y si esa tarde no existe en su agenda, o si descubrió ahora que no sabe quién actualiza el PHP de su plataforma AVA, es exactamente el momento de conocer el alojamiento Moodle de Agathas Web. El próximo fallo crítico llegará; la diferencia es quién estará vigilando el servidor cuando llegue.