PHP2Shell y el LMS Moodle: nuestra respuesta y sus próximos pasos

El 21 de octubre de 2026, el proyecto PHP publicó correcciones de emergencia para dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, conocidas públicamente como PHP2Shell. Según PHP, ambas pueden permitir la ejecución remota de código sin autenticación. (PHP )

Las fallas están en PHP, no en el LMS Moodle™, pero todo sitio del LMS Moodle funciona con PHP y requiere atención.

Para clientes de Krestomatio: los sitios del LMS Moodle que gestionamos ya funcionan con una versión corregida de PHP. No necesita realizar ninguna acción.

Qué es PHP2Shell

PHP2Shell abarca dos fallas relacionadas entre sí, ambas en la forma en que PHP procesa una solicitud web:

• CVE-2026-109618, corrupción de memoria cuando esta se agota. Si PHP se queda sin memoria mientras los datos de la solicitud están a medio preparar, el código de limpieza puede tratar después esos datos inválidos como válidos. (PHP ) (GitHub )
• CVE-2026-109619, estado residual entre solicitudes. El estado de una solicitud puede sobrevivir a la memoria a la que apunta. La siguiente solicitud que atienda el mismo proceso de PHP puede actuar sobre ese estado. (PHP ) (GitHub )

Ambas tienen una calificación de 9.2 (crítica) en CVSS v4.0. (GitHub ) (GitHub ) PHP considera afectada toda instalación que atienda solicitudes web, ya sea con PHP-FPM, Apache mod_php, php-cgi, FrankenPHP o LiteSpeed. Señala a mod_php como el caso de mayor riesgo, ya que existe un exploit demostrado en el que una solicitud sin autenticación puede desencadenar el ataque antes de que se ejecute cualquier código de la aplicación. (PHP )

En las configuraciones más expuestas del LMS Moodle, el ataque ocurre antes de que se ejecute cualquier código de Moodle. El inicio de sesión, los roles y los permisos no llegan a intervenir, así que la corrección tiene que hacerse en PHP.

CERT-EU informa que los detalles técnicos son públicos y que circulan pruebas de concepto, lo que a su juicio aumenta la probabilidad de que ya haya atacantes explotando las vulnerabilidades. (CERT-EU ) Moodle HQ desconectó temporalmente sus propios sitios públicos como medida preventiva. (Moodle.org )

Qué hicimos en los sitios gestionados

Respondimos en dos pasos y aplicamos cada uno a todos los sitios gestionados al mismo tiempo.

1. De inmediato desactivamos la función de progreso de carga de sesiones de PHP (session upload progress), que PHP incluye entre las medidas provisionales para CVE-2026-109619. (PHP ) Antes del cambio, confirmamos que ni el núcleo del LMS Moodle ni los plugins que ofrecemos la usan.
2. Después reconstruimos nuestras imágenes del LMS Moodle con la versión corregida de PHP, verificamos la compilación de PHP dentro de cada imagen y las desplegamos en todos los sitios gestionados.

La función sigue desactivada después de la actualización. El parche corrige ambas fallas, pero el LMS Moodle no necesita esta función, así que no hay motivo para volver a activarla.

Cada sitio también funciona por separado, sin privilegios de root y detrás de políticas de red que restringen sus conexiones. Estas capas limitan el impacto de un ataque, pero no harían segura una instalación de PHP sin parchear.

En qué ayuda un servicio gestionado

Un equipo que aloja su propio sitio tiene que hacer este trabajo con muy poco margen. Alguien debe identificar el PHP que realmente atiende el sitio, cambiar su configuración con cuidado y luego reiniciar servicios fuera de las horas de mayor actividad. Con un servicio gestionado, todo eso se resuelve en un solo cambio coordinado, a cargo de personal que hace este trabajo de forma habitual. Su equipo conserva el control de cursos, usuarios y plugins, y nosotros operamos la plataforma que los sostiene. Para conocer las prácticas operativas en las que se basa este trabajo, lea Seguridad LMS después del incidente del LMS Canvas .

Pasos de PHP2Shell para administradores del LMS Moodle

Si usted mismo opera el LMS Moodle, o si un proveedor lo hace por usted, revise estos puntos ahora.

1. Identifique el PHP que atiende su sitio. Abra la página de información de PHP de Moodle (/admin/phpinfo.php). El comando php -v de la línea de comandos puede mostrar otra compilación. La verificación de entorno de Moodle confirma una versión mínima de PHP, pero no indica si la compilación incluye estas correcciones.

2. Actualice PHP y reinícielo. Instale PHP 8.2.35, 8.3.36, 8.4.27 u 8.5.12, o un paquete de su distribución de Linux que incluya las correcciones. Reinicie todos los procesos de PHP o el servidor web, porque los procesos en ejecución conservan el código anterior. (PHP ) (CERT-EU )

3. Elija una versión de PHP compatible con su versión del LMS Moodle. Use una rama corregida de PHP que esa versión admita. (Moodle Developer Resources ) (Moodle Developer Resources )

   LMS Moodle	PHP compatible	Qué hacer
   4.5 LTS	8.1 a 8.3	Use 8.2.35 u 8.3.36. PHP 8.1 ya no recibe nuevas versiones del proyecto PHP.
   5.1	8.2 a 8.4	Use 8.2.35, 8.3.36 u 8.4.27.
   5.2	8.3 a 8.4	Use 8.3.36 u 8.4.27.
   4.4 y 5.0	8.1 a 8.3 (4.4), 8.2 a 8.4 (5.0)	Actualice PHP ahora. El soporte de seguridad de Moodle terminó, así que planifique actualizar el LMS Moodle.
   4.1 LTS	Hasta 8.1	No existe una versión corregida de PHP del proyecto oficial para esta versión. Un parche de su proveedor puede servir de transición, pero planifique actualizar el LMS Moodle.

4. Si no puede actualizar hoy, reduzca la exposición. Defina session.upload_progress.enabled = 0 en php.ini, en el pool de PHP-FPM o en la configuración del servidor web (no con ini_set() ni .user.ini) y luego reinicie PHP. (PHP ) Nuestra revisión determinó que ni el núcleo del LMS Moodle ni los plugins que ofrecemos usan esta función, pero revise los plugins adicionales que tenga. PHP también menciona otras medidas parciales, como eliminar el límite de memoria; evalúe sus desventajas antes de aplicarlas. Si no puede actualizar pronto, CERT-EU recomienda retirar de las redes públicas los sistemas expuestos a internet. (CERT-EU ) PHP advierte que estas medidas reducen la exposición a vías de ataque específicas, pero no hacen segura una instalación. (PHP )

5. Busque señales de intrusión. En los logs de PHP y del servidor web, revise si hay errores por memoria agotada y procesos caídos. Examine el directorio de código de Moodle y moodledata en busca de archivos PHP desconocidos, y compruebe que no existan cuentas de administración ni plugins que nadie haya creado. Si encuentra algo de esto, aísle el sitio, conserve los logs y cambie las credenciales de administración y la contraseña de la base de datos en config.php.

Mantener PHP al día

Un sitio del LMS Moodle depende de PHP, del servidor web y del sistema operativo, y de alguien que los mantenga actualizados. Mientras PHP no tenga el parche, las medidas del paso 4 solo reducen la exposición.

Si su equipo prefiere no atender por su cuenta la próxima emergencia de PHP o del LMS Moodle, conozca nuestros planes o cuéntenos qué necesita .

Nota de marca: Moodle y los logotipos asociados de Moodle son marcas comerciales o marcas registradas de Moodle Pty Ltd o sus afiliadas relacionadas. Este artículo usa las marcas de Moodle únicamente para identificar y comentar el LMS Moodle y servicios relacionados, siguiendo la guía de marcas publicada por Moodle. (Moodle Trademark Guidelines )