Situación actual: PHP2Shell. Dos vulnerabilidades críticas de PHP (CVSS 9.2) permiten ejecutar código malicioso sin autenticación. Parches desde el 21/10/2026.Qué hacer ahora →

Seguridad en Moodle tras PHP2Shell: cómo proteger bien las plataformas de aprendizaje

Moodle gestiona datos de participantes, calificaciones y entregas de exámenes, a menudo de menores. Tras PHP2Shell importan el parche de PHP, el reinicio de web y cron, un moodledata protegido y plugins revisados.

Actualizado 5 min de lecturaPlataformas

En resumen: tras PHP2Shell, la seguridad en Moodle depende del PHP del servidor, no de Moodle. Como las plataformas de aprendizaje tratan datos de alumnos, estudiantes y empleados, es importante actuar con rapidez. Parchee PHP para la web y cron, reinicie todos los procesos y revise config.php, moodledata, los plugins y las cuentas de administrador.

Qué significa PHP2Shell para los operadores de Moodle

Moodle está muy extendido en colegios, universidades, formación continua y formación interna en empresas. La plataforma gestiona nombres, direcciones de correo electrónico, pertenencia a cursos, calificaciones, entregas de exámenes y mensajes de foros, en los centros educativos a menudo de menores. Según el equipo de PHP, las vulnerabilidades de PHP CVE-2026-109618 y CVE-2026-109619 permiten ejecutar código malicioso de forma remota y sin autenticación.

Los servidores Moodle son casi siempre accesibles desde internet, porque los alumnos trabajan desde casa. El BSI (Oficina Federal alemana para la Seguridad de la Información) recomienda, con el nivel de alerta 3, actualizar de inmediato y, si no es posible, desconectar temporalmente de la red los servidores web. Para colegios y entidades de formación esto es difícil desde el punto de vista organizativo, pero se puede planificar. Encontrará indicaciones específicas del sector en Seguridad informática para colegios y entidades de formación.

Seguridad en Moodle: comprobar la versión de PHP para web y cron

En Administración del sitio > Servidor > Entorno, Moodle comprueba la versión de PHP y otros requisitos. En Servidor > Información de PHP, los administradores ven además los datos completos de PHP. Ambos describen el PHP web.

Moodle necesita además un cron job que ejecute admin/cli/cron.php periódicamente con el PHP de línea de comandos. Esa versión puede diferir y también debe estar parcheada. Las versiones corregidas de origen son 8.5.12, 8.4.27, 8.3.36 y 8.2.35; los backports suelen llevar números más antiguos. Qué versiones de PHP admite su versión de Moodle puede consultarlo, según los requisitos del sistema, en la documentación de moodle.org. Cómo reiniciar limpiamente todos los procesos después se explica en Reiniciar PHP-FPM y todos los workers.

Directorios y configuración en Moodle

Lugar Contenido Punto de control
config.php Acceso a la base de datos, wwwroot, ruta a moodledata Código añadido; cambiar la contraseña ante una sospecha
moodledata/ Almacén de archivos, entregas, sesiones, cachés Fuera de la raíz de documentos, sin archivos PHP
mod/, blocks/, local/, theme/ Actividades, bloques, extensiones locales, diseños Plugins desconocidos o modificados
admin/cli/ Scripts de línea de comandos Solo utilizables por CLI

Moodle ofrece un ajuste que impide modificar rutas de programas desde la interfaz web. Debe estar en config.php y dificulta invocar programas en el servidor desde una cuenta de administrador secuestrada:

$CFG->preventexecpath = true;

Comprobaciones inofensivas en la línea de comandos, como usuario del servidor web:

# Mostrar las comprobaciones de estado y de seguridad propias de Moodle
php admin/cli/checks.php
php admin/cli/checks.php --type=security
# Buscar archivos PHP en el directorio de datos (adaptar la ruta)
find /pfad/zu/moodledata -type f -name "*.php"
Importante

Ante una sospecha de fuga de datos en un colegio o una universidad, rápidamente intervienen varias instancias: la dirección del centro, la entidad titular, los delegados de protección de datos y, en su caso, la autoridad de supervisión. Guarde los registros a partir del 20/10/2026 y documente cada medida con la hora.

Plugins, cuentas de administrador y subidas

Una indicación práctica para la planificación: las actualizaciones de PHP y los reinicios no deberían coincidir con periodos de exámenes ni con pruebas en línea en curso. Moodle tiene un modo de mantenimiento que informa antes a los usuarios. Sin embargo, no protege frente a PHP2Shell, porque la página de mantenimiento también la sirve PHP.

Moodle vive de los plugins: actividades, herramientas de examen, conexiones con videoconferencias y gestión escolar. Cada plugin es código PHP adicional y debe encajar con la versión de Moodle. En Administración del sitio, Moodle muestra las actualizaciones disponibles del núcleo y de los plugins. Elimine por completo los plugins que ya nadie use.

Revise la lista de administradores del sitio y los roles globales con permisos amplios. El profesorado y los creadores de cursos normalmente no necesitan derechos globales. Active la autenticación en dos pasos al menos para los administradores. Los tipos de archivo permitidos para las subidas deberían ser lo más restrictivos posible; encontrará indicaciones en Implementar subidas de archivos seguras en PHP.

Lo que puede y no puede hacer una actualización de Moodle

Una actualización de Moodle cierra errores en Moodle y a menudo permite versiones más recientes de PHP. No parchea PHP, no reinicia ni los procesos web ni los de cron y no elimina archivos ajenos de moodledata, administradores adicionales ni plugins modificados. Tampoco responde a si se filtraron datos en el periodo anterior al parche.

Moodle registra además inicios de sesión y acciones en sus propios registros, que los administradores consultan en Administración del sitio > Informes. Busque allí específicamente inicios de sesión anómalos de administradores, cuentas nuevas con roles globales e instalaciones de plugins desde el 17/10/2026. Exporte esas entradas antes de que las limpiezas automáticas borren datos más antiguos. Los informes complementan los registros del servidor web, pero no los sustituyen.

¿Cómo ayuda PHP SOS en concreto?

  • Aclaramos la responsabilidad sobre PHP y hacemos que se confirmen el nivel de parcheo y el reinicio de web y cron.
  • Guardamos registros, base de datos y moodledata antes de cualquier cambio.
  • Revisamos la configuración, los plugins, los administradores, los roles y las subidas.
  • Si lo desea, atendemos la plataforma de forma permanente en el contrato de mantenimiento de seguridad, coordinado con el curso escolar y los periodos de exámenes.

Preguntas frecuentes

¿Está Moodle afectado por PHP2Shell?

Moodle en sí no tiene ninguna vulnerabilidad nueva, pero se ejecuta sobre PHP. Si el PHP del servidor no está parcheado, según el equipo de PHP un atacante puede ejecutar código sin autenticarse. Una actualización de Moodle no cambia nada al respecto.

¿Dónde veo la versión de PHP en Moodle?

En Administración del sitio > Servidor > Entorno, Moodle comprueba la versión de PHP frente a sus requisitos. Moodle no muestra si se ha aplicado un backport; eso lo confirma el operador del servidor.

¿Por qué tiene que estar moodledata fuera del directorio web?

Allí se almacenan archivos subidos, entregas, sesiones y cachés. Si el directorio es accesible por la web, es posible que los contenidos puedan consultarse directamente. Por eso Moodle exige una ubicación fuera de la raíz de documentos.

¿Quién es responsable de la actualización de PHP en los centros educativos?

Varía: la entidad titular del centro, un organismo estatal, un centro de datos municipal o un proveedor de servicios. Aclare la responsabilidad por escrito y haga que le confirmen el nivel de parcheo y el reinicio.

Fuentes

Contacto inmediato

Cada hora cuenta. Escríbanos ahora.

Describa brevemente el sistema, la versión de PHP y lo que ha observado. Nos pondremos en contacto, aclararemos la situación y trabajaremos en remoto hasta que el incidente quede cerrado y documentado.

Ayuda inmediata