Moodle tuvo 38 vulnerabilidades publicadas en 2025, con una puntuación media de gravedad de 5,6 sobre 10, y eso solo cuenta las que llegaron a hacerse públicas. La mayoría de incidentes de seguridad en instalaciones reales, sin embargo, no vienen de un ataque sofisticado contra un fallo desconocido: vienen de parcheo retrasado, servidores mal configurados y ajustes por defecto que nadie llegó a cambiar.
En esta guía vas a ver qué exige realmente proteger un Moodle en producción: permisos de archivo, políticas de contraseña, protección contra fuerza bruta, y el informe de seguridad que la propia plataforma ya trae integrado y que muy pocos administradores revisan con regularidad.
El origen real de la mayoría de incidentes
Como resume bien la propia experiencia de administradores especializados en hardening de Moodle, la mayoría de incidentes no empiezan con un exploit de día cero, empiezan con parcheo retrasado, servidores mal configurados y ajustes por defecto sin cambiar. Es una distinción importante: no se trata de defenderse de amenazas exóticas, sino de cerrar las puertas que quedan abiertas por simple inercia.
Permisos de archivo: el error más común y más fácil de explotar
Unos permisos incorrectos son uno de los fallos de instalación más habituales en Moodle, y de los más sencillos de aprovechar por un atacante. La configuración recomendada:
- Directorio de la aplicación (el código de Moodle): propiedad
root:root, directorios en755y archivos en644. Esto impide que el propio proceso del servidor web pueda modificar el código de la aplicación, bloqueando de raíz los ataques de inyección de código. moodledata: propiedad del usuario del servidor web (por ejemplowww-data:www-data), ya que esta carpeta sí necesita permisos de escritura para archivos subidos, caché y sesiones.
Separar estos dos niveles de permisos (código de solo lectura para el servidor web, moodledata con escritura) es una de las medidas más efectivas y menos costosas de aplicar.
Política de contraseñas real, no la de por defecto
La configuración de contraseña que trae Moodle de fábrica (mínimo 8 caracteres) es claramente insuficiente para los estándares actuales. La recomendación real:
- Mínimo 12 caracteres, no 8.
- Exigir mayúsculas, minúsculas, dígitos y caracteres especiales.
- Considerar un plugin de validación de contraseñas que compruebe contra bases de datos de credenciales filtradas conocidas, para evitar que los usuarios reutilicen contraseñas ya comprometidas en otras brechas.
Protección contra fuerza bruta
Un formulario de login sin ninguna protección adicional es un objetivo fácil para ataques de credential stuffing y password-spraying. La combinación recomendada:
- Plugin de protección contra fuerza bruta a nivel de aplicación (bloquea usuarios e IPs que repiten intentos fallidos de autenticación de forma sospechosa).
fail2bana nivel de servidor, monitorizando los logs del servidor web para bloquear IPs con patrones de ataque, en una capa independiente de la propia aplicación.
Combinar ambas capas (aplicación y servidor) es lo que realmente dificulta este tipo de ataque, frente a depender solo de una de las dos.
Autenticación multifactor
Habilitar autenticación multifactor (MFA) para cuentas con privilegios administrativos reduce drásticamente el impacto de una contraseña comprometida, incluso si un atacante consigue las credenciales por otra vía (phishing, filtración externa). Es una de las medidas de mayor impacto por el esfuerzo de configuración que requiere.
El informe de seguridad que ya tienes y probablemente no revisas
Moodle incluye un informe nativo, Site administration > Reports > Security Checks, que valida automáticamente más de 15 ajustes de seguridad, desde permisos hasta configuraciones de registro público, forzado de HTTPS, o exposición de información sensible. Ejecutarlo con periodicidad mensual y revisar cada aviso pendiente es una de las formas más rápidas de detectar configuraciones débiles, y a diferencia de una auditoría externa, no cuesta nada activarlo, solo revisarlo con la disciplina de hacerlo cada mes.
Vulnerabilidades reales recientes: por qué esto no es teórico
Los avisos de seguridad de Moodle publican con regularidad vulnerabilidades reales que afectan a instalaciones activas. Algunos ejemplos recientes ilustran bien la variedad de riesgos:
- Un fallo en el plugin de repositorio de Google Drive y otro en el plugin de autenticación por base de datos externa (
auth_db), este último con riesgo de inyección SQL, afectando a un rango amplio de versiones recientes de Moodle. - Una vulnerabilidad en la funcionalidad de restauración de copias de seguridad, donde un archivo de backup manipulado de forma maliciosa, si se restaura, podría llevar a la ejecución de código no autorizado en el servidor, un motivo más para no restaurar backups de origen no confiable sin verificarlos antes.
- Un fallo de exposición de información sensible (nombres, contactos, contraseñas cifradas) a través de trazas de error de la API en sitios sin una configuración concreta de PHP, los sitios con
zend.exception_ignore_args = 1en suphp.inino se ven afectados, un ajuste sencillo y de bajo coste que merece revisarse. - Riesgos de inyección de comandos en el filtro TeX cuando está habilitado junto con ImageMagick, aunque este vector requiere privilegios administrativos para explotarse.
Cómo mantenerte al día sin depender de revisar manualmente cada semana
La forma más eficiente de no perderte un aviso crítico es suscribirte al foro oficial de anuncios de seguridad de Moodle y registrar tu sitio en moodle.org, lo que da acceso a avisos privados antes de la divulgación pública, una ventaja de tiempo real frente a enterarte por una noticia genérica días después.
Checklist resumen de hardening
| Área | Medida |
|---|---|
| Permisos de archivo | Código en root:root 755/644; moodledata con escritura para el usuario del servidor web |
| Contraseñas | Mínimo 12 caracteres, complejidad exigida, validación contra credenciales filtradas |
| Fuerza bruta | Plugin de protección a nivel de aplicación + fail2ban a nivel de servidor |
| Autenticación | MFA activado para cuentas administrativas |
| Informe nativo | Security Checks revisado mensualmente |
| Backups | Verificados antes de restaurar, nunca de origen no confiable sin comprobar |
| PHP | zend.exception_ignore_args = 1 para evitar exposición de datos en trazas de error |
| Avisos de seguridad | Suscripción al foro oficial para recibir avisos antes de la divulgación pública |
Preguntas frecuentes
¿Cuántas vulnerabilidades se publican al año en Moodle? En 2025 se publicaron 38, con una puntuación media de gravedad de 5,6 sobre 10, una cifra que varía año a año, pero que confirma que el parcheo regular no es opcional.
¿Qué permisos deberían tener los archivos de mi Moodle?
El código de la aplicación en 755 para directorios y 644 para archivos, propiedad de root, y moodledata con permisos de escritura para el usuario del servidor web.
¿Es suficiente con la política de contraseñas por defecto de Moodle? No. El mínimo de 8 caracteres por defecto es inadecuado para los estándares actuales; se recomienda al menos 12, con exigencia de complejidad.
¿Necesito fail2ban si ya tengo un plugin de protección contra fuerza bruta? Es recomendable tener ambas capas: el plugin protege a nivel de aplicación, mientras que fail2ban actúa a nivel de servidor, bloqueando IPs antes incluso de que lleguen a la aplicación.
¿Cómo sé si mi Moodle tiene vulnerabilidades sin parchear? Revisando tu versión contra los avisos oficiales de seguridad de Moodle, y ejecutando el informe nativo de Security Checks para detectar configuraciones débiles.
¿Restaurar un backup puede ser un riesgo de seguridad? Sí, existen vulnerabilidades documentadas relacionadas con archivos de backup manipulados maliciosamente que, al restaurarse, podrían ejecutar código no autorizado, por eso conviene verificar siempre el origen de cualquier backup antes de restaurarlo.
¿Qué es el informe de Security Checks de Moodle? Un informe nativo, disponible en Site administration > Reports > Security Checks, que valida automáticamente más de 15 ajustes de seguridad del sitio, sin necesidad de herramientas externas.
¿Cómo me entero de una vulnerabilidad crítica antes de que se haga pública? Suscribiéndote al foro oficial de anuncios de seguridad de Moodle y registrando tu sitio en moodle.org, lo que da acceso a avisos privados con antelación sobre la divulgación pública.
Conclusión
La seguridad de Moodle no depende de una única medida heroica, sino de varias capas simples aplicadas de forma consistente: permisos correctos, contraseñas exigentes, protección contra fuerza bruta, y la disciplina de revisar el informe de seguridad nativo cada mes. Ninguna de estas medidas es compleja por separado, lo que falla, casi siempre, es que nadie las revisa con regularidad una vez configuradas.
Si prefieres no tener que vigilar tú mismo cada aviso de seguridad y cada ajuste pendiente, en Avantys lo llevamos como parte del mantenimiento continuo de cada Moodle que gestionamos. Puedes pedir una auditoría gratuita en Moodle Gestionado.
Artículos relacionados
- Cómo proteger Moodle de ataques y vulnerabilidades
- Backups de Moodle: cómo verificar que restauran de verdad
- SPF, DKIM y DMARC para el correo de Moodle
- Checklist de hardening de Moodle
- Vulnerabilidades en versiones antiguas de Moodle sin soporte
- Roles y permisos en Moodle: evitar accesos indebidos
- SSL y HTTPS en Moodle: configuración correcta
- RGPD y LOPD en plataformas Moodle
¿Y si tu Moodle lo lleváramos nosotros?
Actualizaciones, backups verificados, rendimiento y trazabilidad FUNDAE, gestionado de forma continua por una persona que responde. Auditoría gratuita de tu plataforma actual.
