Actualizar PHP Moodle: 8.3.36 o 8.4.27 sin Romper Plugins

Actualizar PHP Moodle ha dejado de ser una tarea de "cuando se pueda": desde el 21 de octubre de 2026, quien ejecuta el EVA en PHP sin las correcciones de PHP2Shell está expuesto a la ejecución remota de código sin necesidad de login. En esta guía le mostramos qué versión de PHP acepta cada Moodle, cómo homologar sin deshabilitar plugins y cómo preparar el rollback antes de operar en producción.

TL;DR

• El PHP2Shell (CVE-2026-109618 y CVE-2026-109619) tiene una puntuación de 9,2 en CVSS 4.0 y no exige autenticación. 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.
• Moodle 4.5 LTS solo acepta hasta PHP 8.3, por lo que el objetivo es 8.3.36. Moodle 5.0 y 5.1 aceptan de 8.2 a 8.4: el objetivo recomendado es 8.4.27 (o 8.3.36).
• Antes de actualizar PHP Moodle en producción, distinga dos operaciones: el parche dentro del mismo branch (8.3.x a 8.3.36) casi no rompe plugins; el cambio de branch (8.1 a 8.3) exige homologación.
• Ajustes como memory_limit=-1 reducen el riesgo, pero no lo resuelven. Solo la versión corregida lo soluciona.
• El rollback de PHP es económico si mantiene el pool antiguo instalado. Planifíquelo antes, no durante el incidente.

Por qué actualizar PHP Moodle se convirtió en una urgencia en octubre de 2026

El PHP2Shell es el apodo de dos fallos en el núcleo de PHP. La CVE-2026-109618 es una corrupción de memoria cuando la solicitud excede el límite de memoria (out-of-memory): el procesamiento se interrumpe y deja datos internos parcialmente inicializados. La CVE-2026-109619 es un problema de estado global obsoleto: una información de la solicitud sobrevive después de que su memoria ha sido liberada (use-after-free) y contamina la siguiente solicitud.

Ambas conducen a la ejecución remota de código con los privilegios del proceso web, sin usuario ni contraseña. En Moodle, esto abre el config.php (con la contraseña de la base de datos), el moodledata y los datos de todos los estudiantes.

La cronología relevante para quienes administran el EVA

• 17/10/2026: Amazon Threat Intelligence registró un intento de explotación en su red de honeypots, cuatro días antes de la divulgación, según el FAQ de Tenable. La recomendación es investigar los registros (logs) a partir de esa fecha, no de la divulgación.
• 20/10/2026: los identificadores se filtraron en redes sociales y el equipo de seguridad de PHP adelantó la publicación un día.
• 21/10/2026: se publicaron las versiones corregidas. Datadog Security Labs empezó a observar un escaneo amplio y no dirigido. WatchTowr informó de intentos contra ambas CVEs.
• 23/10/2026: la Unit 42, de Palo Alto Networks, actualizó la alerta. La telemetría de Cortex Xpanse señala más de 22,6 millones de instancias expuestas potencialmente vulnerables. El mismo día, php.net divulgó la CVE-2026-115560, con un vector considerado improbable y una corrección prevista para la próxima versión regular.

Quién tiene corrección y quién no

Branch de PHP	Situación tras PHP2Shell
8.2, 8.3, 8.4, 8.5	Corregido en 8.2.35, 8.3.36, 8.4.27 y 8.5.12
7.4, 8.0, 8.1	Solo backports mínimos del código fuente, para quienes compilan PHP
5.4 a 7.3	Sin corrección alguna

Si su Moodle aún se ejecuta en PHP 8.1, no existe un paquete oficial corregido. La solución es cambiar de branch, y ahí reside el riesgo de romper plugins.

Matriz de compatibilidad: Moodle 4.5, 5.0 y 5.1 x PHP

Antes de actualizar PHP Moodle, compruebe qué acepta su versión del EVA. La política oficial de PHP de Moodle define un mínimo y un máximo por branch.

Moodle	Soporte de seguridad (Moodle HQ)	PHP mínimo	PHP máximo	Objetivo post-PHP2Shell
4.5 LTS	hasta el 04/10/2027	8.1	8.3	8.3.36
5.0	finalizado el 05/10/2026	8.2	8.4	8.4.27 o 8.3.36, y planificar la migración desde 5.0
5.1	hasta el 19/04/2027	8.2	8.4	8.4.27 (o 8.3.36)
5.2	hasta el 04/10/2027	8.3	8.4	8.4.27
5.3 LTS	hasta el 01/10/2029	8.3	8.4 (8.5 en desarrollo)	8.4.27

Tres lecturas prácticas para actualizar PHP Moodle sin salirse del rango soportado:

1. Moodle 4.5 no funciona con PHP 8.4. La política lista el 8.4 solo a partir de Moodle 5.0. Quien esté en 4.5 LTS irá a 8.3.36 y punto.
2. PHP 8.2 es un atajo corto. Según el calendario oficial de PHP, el 8.2 recibe correcciones de seguridad solo hasta el 31/12/2026. Instalar 8.2.35 hoy resuelve el PHP2Shell, pero obliga a un nuevo cambio en dos meses.
3. El 8.3 va hasta el 31/12/2027 y el 8.4 hasta el 31/12/2028. Para Moodle 5.x, el 8.4 ofrece más margen.

¿Parche en el mismo branch o cambio de branch?

Esta es la decisión que define la magnitud del trabajo. Un parche dentro del mismo branch (8.3.30 a 8.3.36) solo trae correcciones: no cambia el lenguaje, no elimina funciones, no crea deprecation.

El cambio de branch (8.1 a 8.3, o 8.3 a 8.4) cambia el lenguaje. Un plugin escrito hace cuatro años, un tema personalizado y una integración propia pueden fallar. Este caso requiere una homologación completa.

En 8.2 o 8.3, aplique el parche ahora y planifique el cambio de branch. En 8.1 o inferior, no hay parche: el cambio es obligatorio y urgente.

Qué rompe plugins al cambiar el branch de PHP

Al actualizar PHP Moodle cambiando de branch, el núcleo rara vez es el problema, porque se prueba en el rango oficial. Lo que falla está fuera de él: plugins de terceros, temas y código propio. He detallado la evaluación de cada uno en plugins esenciales de Moodle y cómo verificar la compatibilidad.

El version.php no menciona PHP

El archivo version.php de un plugin declara $plugin->requires (versión mínima de Moodle) y, en los plugins más recientes, $plugin->supported (rango de branches de Moodle). Ninguno de los dos declara la versión de PHP. Un plugin "compatible con Moodle 4.5" puede que nunca haya sido probado en PHP 8.3. Solo una prueba real lo confirmará.

Los cambios de lenguaje que más afectan

• PHP 8.2: crear una propiedad dinámica en un objeto pasó a generar un aviso de deprecation. El código antiguo hace esto constantemente. No rompe, pero llena el log.
• PHP 8.4: un parámetro con valor predeterminado null sin el tipo marcado como anulable (?string) genera deprecation. También se eliminaron del núcleo las extensiones IMAP, Pspell y OCI8, que ahora residen en PECL. Si algún plugin o integración depende de ellas, el error es fatal.
• Extensiones del sistema: cada branch tiene sus propios paquetes (php8.3-intl, php8.4-intl). Olvidar un paquete, como intl, soap, sodium o redis, es la causa más común de "funcionaba ayer".
• Nuevo php.ini: el archivo de configuración del nuevo branch viene con los valores predeterminados. Moodle exige max_input_vars de al menos 5000 y el valor predeterminado de PHP es 1000. Sin ajustar, los formularios grandes (calificaciones, permisos) pierden campos sin previo aviso.

Cómo descubrir el problema antes que el estudiante

En homologación, active la depuración a nivel de desarrollador y lea el log de PHP-FPM después de cada script de prueba. Busque Deprecated, Fatal error y Uncaught. Cada línea señala el archivo y la línea del plugin responsable.

Entorno de homologación: el paso que nadie quiere pagar y todos necesitan

Homologar es probar el cambio en una copia fiel de la producción antes de aplicarlo realmente. Para actualizar PHP Moodle cambiando de branch, no conocemos un atajo seguro que omita este paso.

Cómo configurar la copia

1. Mismo sistema operativo y misma versión que el servidor de producción.
2. Dump de la base de datos de producción y copia de moodledata. Si el filedir es demasiado grande, copie la estructura y una muestra; lo que no puede faltar son los archivos de curso utilizados en el script de prueba.
3. Deshabilite el correo electrónico. En el config.php de la copia, use $CFG->noemailever = true;. Sin esto, el cron de homologación enviaría notificaciones de plazos a miles de estudiantes reales.
4. Desactive las integraciones de salida que cobran o modifican datos: pasarela de pago, envío por WhatsApp, sincronización con ERP.
5. Instale los dos PHPs en paralelo (por ejemplo, php8.1-fpm y php8.3-fpm). El virtual host apunta al socket de uno u otro.

El script de prueba mínimo

• Inicio de sesión local y por SSO (OAuth2, SAML, LDAP), si lo hubiera
• Abrir curso, ver vídeo, descargar archivo
• Realizar un cuestionario de principio a fin y verificar la calificación
• Enviar tarea con subida de archivo y corregir como profesor
• Exportar el libro de calificaciones
• Ejecutar el cron manualmente: php admin/cli/cron.php
• Probar la app Moodle (web services) y cualquier integración por API
• Abrir los informes y plugins de pago más utilizados

Antes de las pruebas, abra Administración del sitio > Servidor > Entorno y confirme que todo aparece en verde. Este panel señala extensiones faltantes y configuraciones por debajo de lo requerido.

Paso a paso para actualizar PHP Moodle en producción

Con la homologación aprobada, actualizar PHP Moodle en producción se convierte en la ejecución de un script. La secuencia que utilizamos:

1. Copia de seguridad completa y probada: base de datos, moodledata y código.
2. Aviso a los usuarios con antelación y ventana fuera del horario de mayor actividad.
3. Modo de mantenimiento: php admin/cli/maintenance.php --enable.
4. Instale el PHP corregido con las mismas extensiones validadas en la homologación y copie los ajustes de php.ini (max_input_vars, memory_limit, upload_max_filesize, post_max_size).
5. Cambie el socket de PHP-FPM en el virtual host y recargue el servidor web.
6. Purga de cachés: php admin/cli/purge_caches.php. Esto evita cachés compiladas de la versión anterior.
7. Verifique el entorno en el panel de Moodle y el phpinfo de la versión en uso (php -v en el terminal puede mostrar otro binario que no es el de FPM).
8. Ejecute el script de prueba corto y solo entonces salga del modo de mantenimiento.
9. Reinicie todos los workers de PHP-FPM. Las directrices de PHP2Shell lo refuerzan: la configuración solo es válida para procesos nuevos.

¿Y si su distro dice que la versión es otra?

Ubuntu, Debian y Red Hat suelen aplicar la corrección sin cambiar el número de la versión upstream. Datadog advierte sobre esto: el paquete puede estar corregido aunque muestre 8.3.6, por ejemplo. En ese caso, consulte el boletín de seguridad de la distribución y el changelog del paquete, no el número de php -v.

Rollback: cómo revertir en minutos sin perder datos

La buena noticia: cambiar PHP no altera la base de datos de Moodle. A diferencia de actualizar Moodle 4.5 a 5, donde la actualización modifica el esquema de la base de datos y revertir exige restaurar una copia de seguridad, el cambio de PHP es reversible simplemente reconfigurando el socket.

Deje el camino de vuelta preparado

Quien vaya a actualizar PHP Moodle necesita tener el procedimiento de reversión documentado antes de empezar.

• No desinstale el PHP antiguo el día del cambio. Mantenga el pool configurado y detenido.
• Documente el comando de reversión: qué archivo del virtual host cambia y qué servicio recargar.
• Defina el disparador: qué error justifica la reversión (inicio de sesión roto, cuestionario sin guardar) y quién decide.
• Después de revertir, ejecute de nuevo php admin/cli/purge_caches.php.

La trampa del rollback en octubre de 2026

Volver a un PHP sin corrección reabre el PHP2Shell. El rollback, ahora, no puede ser a "lo que funcionaba". Tiene que ser a la versión corregida del branch anterior. Si el branch anterior es 8.1 o más antiguo, no existe una reversión segura: o corrige el plugin, o desactiva el plugin, o aísla el servidor hasta resolverlo. La CISA llegó a recomendar retirar de servicio los sistemas en PHP 8.1 o anterior que no puedan ser actualizados.

Mitigaciones mientras no llega la actualización (y por qué no son suficientes)

El propio equipo de PHP publicó ajustes de configuración para reducir la exposición. Ayudan a ganar tiempo, pero no sustituyen la actualización de PHP Moodle a la versión corregida.

Ajuste	Contra qué	Limitación
memory_limit=-1, fijado vía php_admin_value en el pool	CVE-2026-109618	Elimina el límite de memoria controlable, pero un fallo de asignación aún puede alcanzar el segmento vulnerable. Use un límite de memoria en el contenedor o cgroup
session.upload_progress.enabled=0	Ruta de sesión de la CVE-2026-109619	No cubre otras variantes; Datadog informa que no protege por sí solo. También es la orientación provisional para la CVE-2026-115560
fatal_error_backtraces=0 (solo PHP 8.5)	CVE-2026-109619	No se aplica a Moodle en 8.3 o 8.4

Dos precauciones específicas de Moodle. Primero, dejar memory_limit=-1 de forma permanente permite que un informe pesado o una restauración de curso consuma toda la RAM del servidor. Segundo, deshabilitar el upload progress no rompe la subida de archivos de Moodle, pero pruebe el envío de tareas de todos modos.

Cuándo no actualizar (aún) y errores costosos

Hay momentos inoportunos para actualizar PHP Moodle cambiando de branch. Un parche de seguridad dentro del mismo branch casi siempre debe aplicarse de inmediato. El cambio de branch, en cambio, merece un calendario.

No cambie el branch de PHP:

• En la semana de exámenes, de cierre de calificaciones o de matrícula.
• Junto con la actualización de Moodle. Dos cambios el mismo día hacen imposible saber qué rompió qué.
• Sin homologación, solo porque "el proveedor dijo que es compatible".

Errores que vemos repetirse:

• Actualizar PHP Moodle solo en la línea de comandos y olvidar PHP-FPM. El php -v muestra la versión nueva y el sitio sigue vulnerable.
• Olvidar el cron. Se ejecuta con el binario de línea de comandos; si apunta al PHP antiguo, las tareas programadas se ejecutarán en la versión incorrecta.
• Copiar el php.ini completo del branch antiguo al nuevo, cargando directivas que ya no existen.
• Ignorar el log de deprecation. Hoy es un aviso; en la próxima versión se convierte en un error fatal.

Si el servidor es una VPS que nadie del equipo administra realmente, vale la pena releer el artículo sobre VPS para Moodle o alojamiento gestionado. El PHP2Shell es el tipo de evento en el que esta diferencia se hace evidente.

Cómo Agathas Web resuelve esto

Trabajamos con Moodle y servidores Linux desde antes de la serie 2 del EVA, y la rutina de actualización que hemos descrito es la que aplicamos en los entornos que administramos. En el servicio de Moodle de Agathas Web, la actualización de PHP Moodle se aborda como un proyecto cerrado:

• Inventario: versión de Moodle, branch y build de PHP, paquete de la distro, lista de plugins y temas, integraciones por API y WhatsApp.
• Diagnóstico de exposición: si el entorno está cubierto contra PHP2Shell y qué mitigaciones son válidas mientras no se realiza el cambio.
• Homologación clonada con correo electrónico e integraciones deshabilitadas, PHP en paralelo y script de prueba combinado con la coordinación.
• Corrección o sustitución de plugins que fallan en el nuevo branch, con nuestro equipo de desarrollo PHP.
• Ventana de mantenimiento en horario acordado, con rollback documentado y probado.
• Revisión de logs a partir del 17/10/2026, para verificar señales de intento de explotación.

Cómo contratar: contacte con nosotros a través de la página de servicios Moodle, indíquenos la versión de Moodle y dónde está alojado, y le proporcionaremos un diagnóstico y un plan con plazos. Si prefiere no tener más este trabajo, la operación puede continuar con nosotros en el alojamiento gestionado.

Conclusión: corrija ahora, cambie de branch con método

El camino seguro para actualizar PHP Moodle tiene dos velocidades. Un parche en el mismo branch (a 8.3.36 o 8.4.27) debe aplicarse ahora, porque el riesgo de compatibilidad es mínimo y la explotación ya ha comenzado. El cambio de branch, obligatorio para quienes están en 8.1 o inferior, requiere homologación, un script de prueba y un rollback a una versión también corregida.

Si no sabe qué PHP ejecuta su EVA realmente, el primer paso para actualizar PHP Moodle es averiguarlo. Solicite un diagnóstico en los servicios Moodle de Agathas Web y salga de dudas antes de que un escáner lo haga por usted.