Moodle PHP Obsoleto tras PHP2Shell: Riesgo, Coste y Plan de Migración

Un Moodle PHP obsoleto —ese EVA que aún funciona con PHP 7.4, 8.0 o 8.1— se convirtió en el servidor más expuesto de su institución la semana del 21 de octubre de 2026. PHP2Shell permitió la ejecución remota de código sin autenticación, y PHP solo lanzó una corrección oficial para las versiones 8.2 a 8.5. En esta guía le muestro qué resuelven los backports mínimos, cuánto cuesta quedarse inactivo y el plan de migración que yo seguiría.

TL;DR

• PHP2Shell son dos fallos en el núcleo de PHP: CVE-2026-109618 (corrupción por falta de memoria) y CVE-2026-109619 (estado global obsoleto entre peticiones). Puntuación de 9,2 en CVSS 4.0, explotables sin autenticación.
• La corrección oficial se publicó el 21/10/2026 en las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Para 7.4, 8.0 y 8.1 solo existen backports mínimos de código fuente, sin binario oficial. De 5.4 a 7.3, ninguna corrección.
• Las mitigaciones de php.ini reducen la superficie, pero el propio PHP advierte: no existen mitigaciones completas.
• Un Moodle 3.9, 3.11, 4.0 o 4.1 no funciona con PHP 8.2+. La solución real es actualizar Moodle a la versión 4.5 LTS (soporte de seguridad hasta el 06/10/2027) con PHP 8.3.36.
• Quedarse inactivo conlleva incidentes, RGPD y reputación. La migración cuesta semanas de trabajo planificado.

Qué es PHP2Shell y por qué afecta a Moodle PHP obsoleto

PHP2Shell no es un error de Moodle. Es un error del intérprete PHP que se ejecuta debajo de él — por eso actualizar plugins, temas o el propio Moodle no cierra la puerta.

Según el aviso oficial de php.net del 21/10/2026, son dos fallos:

• CVE-2026-109618 (corrupción por OOM): cuando la memoria se agota en medio de una petición, PHP se interrumpe con datos internos solo parcialmente inicializados. La limpieza de la petición trata esa basura como válida.
• CVE-2026-109619 (estado global obsoleto): un estado interno de la petición sobrevive después de que su memoria ha sido liberada — un use-after-free (uso de memoria ya devuelta al sistema) que se filtra de una petición a la siguiente.

El FAQ de Tenable resume el peor punto: según PHP, ambas pueden ser explotadas por un atacante remoto sin autenticación. No se necesita cuenta de alumno, de profesor, de nada.

La cronología clave

Fecha	Hecho
17/10/2026	Amazon Threat Intelligence registra intento de explotación en la red de honeypots MadPot, cuatro días antes de la divulgación
20/10/2026	Se filtran identificadores; PHP publica aviso previo y anticipa el lanzamiento
21/10/2026	Se lanzan 8.5.12, 8.4.27, 8.3.36 y 8.2.35, más los backports para 7.4, 8.0 y 8.1
21/10/2026	Cortex Xpanse, de Palo Alto, cuenta más de 22,6 millones de instancias expuestas potencialmente vulnerables (Unit 42)
23/10/2026	PHP publica una alerta informativa sobre CVE-2026-115560, un vector improbable relacionado con la carga de progreso de sesión, con corrección prevista en el próximo lanzamiento regular

El detalle que debería quitar el sueño a quien administra EVA: la Unit 42 relata un ataque contra un organismo gubernamental europeo en el que, en menos de dos horas tras la explotación inicial, el invasor obtuvo hashes de contraseñas y secretos de MFA e intentó escalar hasta administrador de dominio. Un Moodle guarda exactamente eso — contraseñas de miles de alumnos, tokens de integración, claves de API.

Qué PHP utiliza su Moodle (y por qué está atascado)

Casi todo Moodle PHP obsoleto que encuentro no está así por descuido. Está atascado porque la versión de Moodle bloquea la versión de PHP. La tabla oficial de compatibilidad de MoodleDocs lo deja claro:

Versión de Moodle	PHP compatible	¿Recibe la corrección oficial de PHP2Shell?
3.9	7.2 a 7.4	No — solo backport mínimo (7.4) o nada (7.2/7.3)
3.11 / 4.0	7.3 a 8.0	No — solo backport mínimo (7.4/8.0)
4.1 LTS	7.4 a 8.1	No — solo backport mínimo
4.2 / 4.3	8.0 a 8.2	Sí, si funciona con 8.2.35
4.4 / 4.5 LTS	8.1 a 8.3	Sí, con 8.2.35 o 8.3.36
5.0 / 5.1	8.2 a 8.4	Sí

Lea la columna central con atención. Un Moodle PHP obsoleto en versión 4.1 no acepta PHP 8.2. Cambiar solo el PHP rompe el EVA; mantener el PHP deja el EVA expuesto. Este es el callejón sin salida de lo obsoleto.

Y hay un agravante: Moodle 4.1 LTS salió del soporte de seguridad el 08/12/2025. Quien lo utiliza ya acumulaba fallos del propio Moodle sin corrección incluso antes de PHP2Shell.

Cómo descubrirlo en dos minutos

1. En Moodle, vaya a Administración del sitio → Notificaciones: la versión aparece en el pie de página.
2. En Administración del sitio → Servidor → Información de PHP, compruebe la línea PHP Version.
3. En el servidor, ejecute php -v y compruebe la versión de PHP-FPM que sirve al sitio. Ya he encontrado servidores con PHP 8.3 en la línea de comandos y FPM 7.4 sirviendo a Moodle.

Backports mínimos: qué cubren y qué dejan fuera

php.net fue directo: "PHP 8.1 and older no longer receive updates from the PHP project". Para ayudar a quienes no pueden actualizar de versión, el equipo de seguridad publicó backports mínimos de código fuente para 7.4, 8.0 y 8.1 — ramas en GitHub de php-src, sin paquete, sin binario, sin lanzamiento.

Para un Moodle PHP obsoleto en producción, esto significa:

• Usted compila PHP. Alguien necesita aplicar el parche, compilar con las mismas extensiones que Moodle exige (intl, sodium, zip, gd, soap, mbstring…) y reemplazar el binario en producción.
• Cubre solo estas dos CVEs. Todo lo demás que fue corregido después del fin de vida de su versión sigue abierto.
• No hay próxima vez garantizada. El CVE-2026-115560, del 23/10, ya será tratado "en el próximo lanzamiento regular" — y las versiones fuera de soporte no tienen lanzamientos regulares.

Cuando el backport tiene sentido

Tiene sentido como puente de días o semanas, mientras se ejecuta la migración de Moodle. También tiene sentido a través del proveedor: Tenable registra que las distribuciones Linux y los proveedores de LTS recibieron los parches antes, por lo tanto, Debian, Red Hat y similares pueden tener un paquete corregido para la versión que usted usa. Consulte el aviso de seguridad de su distribución.

Cuando NO tiene sentido

No tiene sentido como estrategia. Si el plan de la institución es "aplicar el backport y olvidarse", el Moodle PHP obsoleto seguirá en el mismo lugar en la próxima alerta — y la próxima alerta ya ha sido publicada.

Mitigaciones de php.ini en Moodle PHP obsoleto: ayudan, pero tienen un precio

PHP listó mitigaciones para quienes no pueden actualizar al instante. Todas reducen el riesgo; ninguna lo resuelve. En palabras del propio lanzamiento: "There are no complete mitigations, updating is the only safe choice."

memory_limit=-1 contra CVE-2026-109618

La recomendación es memory_limit=-1, aplicado de forma que la aplicación no pueda sobrescribir — php_admin_value[memory_limit] = -1 en el pool de FPM. Junto a esto, post_max_size bajo: 8M sin subidas, 32M con subidas.

En un Moodle PHP obsoleto en servidor único, esto tiene un efecto secundario serio:

• Sin límite de memoria, una copia de seguridad de curso grande o un informe pesado puede consumir toda la RAM. En el servidor todo-en-uno (web + MariaDB en la misma máquina), quien muere primero suele ser la base de datos, derribada por el OOM killer de Linux.
• post_max_size de 32M rompe la restauración de archivos .mbz y el envío de vídeos más grandes a través de la interfaz. Las restauraciones grandes deben hacerse desde el servidor.
• PHP pide no sustituir por RLIMIT_AS o RLIMIT_DATA, porque esos límites pueden desencadenar precisamente el fallo de asignación vulnerable.

La solución es dimensionar pm.max_children de FPM por la RAM disponible y, si es posible, aislar PHP en un contenedor o cgroup con límite — Tenable cita esto como una frontera de disponibilidad, no como una corrección.

session.upload_progress.enabled=0 contra CVE-2026-109619

Desactivar el progreso de carga de sesión bloquea las rutas confirmadas de CVE-2026-109619 — y, según la alerta del 23/10, también el vector de CVE-2026-115560. Hay que ir al php.ini o al pool de FPM y exige reiniciar todos los workers. ini_set() y .user.ini no sirven.

El núcleo de Moodle envía archivos a través del selector de archivos vía AJAX, sin depender de esta barra de progreso nativa de PHP. Aun así, valide en homologación: un plugin de terceros puede depender de ella.

El ajuste fatal_error_backtraces=0 solo existe en PHP 8.5 — irrelevante para quienes están en 7.4 a 8.1. Y ocultar errores con display_errors o @ no ayuda en nada.

Cuánto cuesta quedarse inactivo con un Moodle PHP obsoleto

Nadie publica una tabla de precios de incidentes en EVA, y yo no voy a inventar una. Pero quien mantiene un Moodle PHP obsoleto necesita mirar la cuenta completa. Se puede listar, con base legal, lo que entra en ella.

Costes directos de un incidente

• Indisponibilidad: examen online, matrícula y emisión de certificado se detienen. En semana de evaluación, esto se convierte en reembolso, repetición de examen y atención masiva.
• Respuesta a incidente: peritaje, reinstalación limpia del servidor, cambio de todas las credenciales, revisión de integraciones. Es trabajo de emergencia, cobrado como tal.
• RGPD: el Reglamento General de Protección de Datos (RGPD) exige comunicar un incidente relevante a la AEPD y a los titulares en un plazo de hasta tres días hábiles. La normativa brasileña (art. 52 de la Ley 13.709/2018) prevé multas de hasta el 2% de la facturación en Brasil, limitada a 50 millones de reales por infracción. Estas cifras ilustran la seriedad de las sanciones por incumplimiento de la protección de datos, aplicables también en España según el RGPD.

Costes que no aparecen al instante

• Reputación: el alumno que recibe aviso de fuga de datos lo recuerda en la rematriculación.
• Contratos B2B: la universidad corporativa y el cliente de formación suelen tener cláusulas de seguridad. Un incidente se convierte en renegociación.
• Deuda técnica compuesta: cada mes inactivo aumenta el salto. Salir del 3.9 hoy exige más pasos que hace dos años.

Lo que cuesta migrar

Mover un Moodle PHP obsoleto no es barato, pero es predecible. El esfuerzo crece con cuatro variables: distancia de versión, cantidad de plugins de terceros, tema personalizado y — el mayor villano — alteraciones hechas directamente en el código del núcleo. Un EVA limpio con pocos plugins se actualiza rápido. Un EVA con el core editado a mano exige auditoría antes de cualquier fecha.

El plan de migración que yo seguiría

Moodle no permite saltar versiones a voluntad. La documentación de actualización de 4.5 es clara: solo se llega a 4.5 desde 4.1.2 o superior. Quien tiene un Moodle PHP obsoleto en 3.9, 3.11 o 4.0 necesita pasar por 4.1 primero.

Etapa 0 — Contener (primeras 48 horas)

• Aplicar paquete corregido de la distribución o backport compilado, si lo hay.
• Aplicar las mitigaciones de php.ini con las precauciones anteriores y reiniciar todos los workers.
• Colocar el EVA detrás de un WAF — Cloudflare publicó reglas para PHP2Shell, que ella misma llama paliativo.
• Buscar señales de explotación en los logs a partir del 17/10/2026, la primera fecha con intento registrado.
• Cambiar secretos que estén en config.php y en las integraciones si hay cualquier indicio.

Etapa 1 — Inventario (semana 1)

Listar versión exacta, plugins (con versión y compatibilidad con 4.5), tema, personalizaciones en el core, integraciones y tamaño de moodledata. Es aquí donde se descubre si el Moodle PHP obsoleto se actualiza en dos semanas o en dos meses.

Etapa 2 — Homologación en copia (semanas 1 a 3)

1. Clonar base de datos y moodledata a un entorno aislado.
2. 3.9 / 3.11 / 4.0 → 4.1.x todavía en PHP 7.4 a 8.1.
3. 4.1.x → 4.5 LTS, cambiando PHP a 8.1 a mitad de camino y luego a 8.3.36.
4. Ejecutar la verificación de entorno, probar examen, nota, certificado, pago y SSO.

Si el EVA usa inicio de sesión por Google o Microsoft, revise las integraciones en ese momento — la guía de OAuth2 en Moodle 5.3 muestra lo que cambia cuando se pase a la próxima LTS.

Etapa 3 — Puesta en marcha (una ventana de mantenimiento)

Modo mantenimiento, copia de seguridad verificada, actualización en producción con el guion ensayado, smoke test y reapertura. Con la homologación bien hecha, la puesta en marcha cabe en una madrugada.

Por qué 4.5 y no 5.x

El 4.5 LTS tiene soporte de seguridad hasta el 06/10/2027 y acepta PHP 8.3. El 5.0 ya salió del soporte de seguridad el 05/10/2026, y el 5.1 va por el mismo camino — explico el calendario en el post sobre el fin del soporte de Moodle 5.1. Para quien retira un Moodle PHP obsoleto del aire, el 4.5 es el escalón estable; el 5.3 LTS viene después, sin prisa.

Trampas comunes en la migración

• Actualizar solo PHP. Un Moodle PHP obsoleto en 4.1 no funciona con PHP 8.2. El error aparece en la verificación de entorno — o, peor, en pantalla blanca.
• Olvidar el FPM. El apt upgrade actualiza el CLI y el FPM antiguo sigue sirviendo el sitio.
• Plugin abandonado. Un plugin sin versión para 4.5 necesita ser sustituido, reescrito o eliminado antes de la puesta en marcha, no después.
• Sin rollback. La actualización de Moodle altera la base de datos; no existe "deshacer". Copia de seguridad de la base de datos y moodledata, probada, antes de empezar.
• Cron detenido. Después de la actualización, las tareas programadas acumuladas pueden bloquear el servidor en el primer minuto.
• Servidor incorrecto. Muchas instituciones descubren en la migración que la VPS no soporta el nuevo Moodle. Comparo los dos escenarios en VPS para Moodle o alojamiento gestionado.

Cómo Agathas Web resuelve esto

Trabajo con Moodle desde hace más de 15 años, tengo la Moodle Developer Certification y opero servidores Linux de entornos EVA en el día a día. Para un Moodle PHP obsoleto, el servicio de migración y mantenimiento de Moodle funciona así:

1. Diagnóstico gratuito: levantamos versión de Moodle, PHP, FPM, plugins, tema, personalizaciones e integraciones. Usted recibe el tamaño real del problema.
2. Contención inmediata, si es necesario: paquete corregido o backport, mitigaciones de php.ini ajustadas a Moodle (sin afectar copia de seguridad y restauración) y revisión de logs desde el 17/10.
3. Propuesta técnica: documento con ruta de versiones, plugins a sustituir, infraestructura, cronograma e inversión.
4. Migración en homologación y puesta en marcha: cada paso probado en copia, con guion, copia de seguridad verificada y ventana combinada.
5. Mantenimiento continuo: SLA mensual con actualizaciones de seguridad, monitorización y copia de seguridad verificada — para que la próxima alerta no se convierta en emergencia.

Usted sigue siendo dueño de los datos, del tema y de los plugins. Somos una empresa independiente de servicios, con soporte en español, y quien le atiende entiende el código de Moodle. Para empezar, solicite el diagnóstico en la página de servicios de Moodle de Agathas Web o hable con nosotros por WhatsApp.

Conclusión: PHP2Shell solo adelantó la factura

El Moodle PHP obsoleto ya era un riesgo antes del 21/10/2026: versión de Moodle fuera de soporte, PHP sin corrección, plugins detenidos en el tiempo. PHP2Shell transformó ese riesgo en una ventana de explotación sin autenticación, con 22,6 millones de instancias expuestas según el recuento de Unit 42.

El camino seguro tiene tres pasos: contener ahora, migrar a Moodle 4.5 LTS con PHP 8.3.36 en las próximas semanas y mantener el entorno con mantenimiento continuo. Si quiere saber en qué punto se encuentra su EVA y cuánto falta para salir de él, solicite el diagnóstico en /servicios/moodle.