Moodle MAT: El riesgo de los Moodle departamentales en 2026

Moodle MAT es como alumnos y profesores de la UnB llaman al entorno virtual del Departamento de Matemáticas, alojado en moodle.mat.unb.br, y el término ha vuelto a subir en las búsquedas brasileñas esta semana. La coincidencia es incómoda: el 10 de agosto de 2026, el proyecto Moodle publicó correcciones para las cuatro versiones aún soportadas. Quien gestiona una instancia departamental tiene pocos días de ventaja.

TL;DR

• El 10 de agosto de 2026 salieron las versiones 5.2.2, 5.1.6, 5.0.9 y 4.5.13 — todas con correcciones de seguridad cuyos detalles solo se hacen públicos aproximadamente una semana después.
• Las instancias departamentales como el Moodle MAT suelen quedar fuera del inventario de TI central: sin dueño, sin ventana de mantenimiento, sin entorno de homologación.
• 5 de octubre de 2026 es la fecha que lo decide todo: el 5.1 pierde el soporte general, el 5.0 pierde incluso el soporte de seguridad y se lanza el 5.3 LTS.
• El salto al 5.1 o superior exige apuntar el document root del servidor a la carpeta /public y reubicar los plugins de terceros. Ahí es donde la mayoría de las actualizaciones se atascan.
• El 5.2 sube el listón técnico (PHP 8.3, PostgreSQL 16, MySQL 8.4, MariaDB 10.11) e incorpora Google Gemini y AWS Bedrock como proveedores de IA en el núcleo.

Qué es el Moodle MAT — y por qué importa fuera de la UnB

El Moodle MAT es un caso clásico de instancia departamental: un Moodle propio, mantenido por un departamento académico, que funciona en paralelo al entorno institucional de la universidad. Existe por una razón legítima. Las matemáticas tienen necesidades que el entorno virtual central rara vez cubre bien: renderizado de fórmulas en LaTeX, bancos de preguntas con variables aleatorias, listas de ejercicios con corrección automática y grupos que se mantienen durante varios semestres sin ser eliminados.

El patrón se repite en toda España. Departamentos de ciencias, laboratorios, programas de posgrado, escuelas de administración pública, departamentos de formación interna: cada uno levantó su Moodle el día que necesitó libertad que la TI central no daba. El resultado es una red de instalaciones que nadie puede ver desde arriba.

Para dimensionar el alcance: el panel público del proyecto, en stats.moodle.org, contabiliza 146.104 sitios Moodle registrados en el mundo, con España en 2º lugar y 12.554 instalaciones — por detrás de Estados Unidos (12.032), Alemania (7.927), México (7.800) y Brasil (6.895). Y aquí está el detalle que cambia la lectura del número: el registro es voluntario. Todo Moodle MAT de la vida que nunca se registró queda fuera de esa cuenta. El total real de instancias españolas es mayor — probablemente mucho mayor.

La ronda del 10 de agosto de 2026: cuatro versiones el mismo día

El 10 de agosto de 2026, el proyecto lanzó simultáneamente Moodle 5.2.2, 5.1.6, 5.0.9 y 4.5.13. Publicar todas las ramas soportadas el mismo día es el comportamiento típico del proyecto cuando hay una corrección de seguridad en el paquete.

Y la hay. Las notas de la versión incluyen la frase que los administradores han aprendido a temer: los detalles de las fallas corregidas se divulgarán después de aproximadamente una semana. La lógica es sensata: dar tiempo para actualizar antes de que la receta del ataque se haga pública.

Traduciéndolo al calendario: quien lea esto el 13 de agosto de 2026 tiene pocos días de margen. Alrededor del 17, los boletines MSA correspondientes se publican en moodle.org/security y cualquiera podrá mapear qué versiones son vulnerables y cómo.

No es teoría. La ronda anterior, del 22 de junio de 2026, trajo los boletines MSA-26-0026 a MSA-26-0029: SSRF ciego en la función de pares de MNet, riesgo de denegación de servicio mediante la descripción del perfil de usuario y dos fallas de verificación de permisos: una en el report builder y otra en la asignación de correctores del módulo Tarea. Antes de ellas, el MSA-26-0006 trató el riesgo de ejecución remota de código mediante el plugin de repositorio de Google Drive, catalogado como CVE-2026-7275.

Ninguna de estas fallas requiere un atacante sofisticado. Solo requiere una instalación congelada en el tiempo, que es exactamente el perfil de un Moodle departamental típico.

El calendario que decide el destino de tu Moodle MAT

El ciclo de vida oficial está publicado en moodledev.io/general/releases y es el documento que debería estar pegado en la pared de quien administra cualquier instancia:

Versión	Lanzamiento	Fin del soporte general	Fin del soporte de seguridad
4.5 LTS	07/10/2024	06/10/2025	04/10/2027
5.0	14/04/2025	20/04/2026	05/10/2026
5.1	06/10/2025	05/10/2026	19/04/2027
5.2	20/04/2026	19/04/2027	04/10/2027
5.3 LTS	05/10/2026	04/10/2027	01/10/2029

Tres lecturas prácticas de esta tabla:

1. Si tu Moodle MAT ejecuta 5.0, el reloj se detiene el 5 de octubre de 2026. Después de eso, no existe más corrección de seguridad para esa rama. Quedan menos de dos meses.
2. Si ejecuta 4.5 LTS, ya no recibes correcciones de errores comunes desde octubre de 2025; solo seguridad, y aún así hasta octubre de 2027. Puedes respirar, pero no relajarte.
3. Si ejecuta 5.1, el soporte general termina el 5 de octubre de 2026, pero la seguridad continúa hasta abril de 2027. Es la posición más cómoda para planificar una actualización sin prisas.

Y hay una oportunidad de planificación que casi nadie aprovecha: el 5.3 LTS llega el 5 de octubre de 2026, con soporte de seguridad hasta el 1 de octubre de 2029. Para una instancia departamental, sin equipo dedicado y sin presupuesto recurrente, LTS es casi siempre la elección correcta. Tres años de previsibilidad valen más que funciones nuevas que nadie usará.

Por qué las instancias departamentales envejecen más rápido

No es pereza. Es estructura. El Moodle MAT nace así en cualquier institución, y siempre por los mismos tres motivos.

No existe un dueño formal

La instalación la hizo un profesor entusiasta, un becario o un técnico que ya cambió de área. Cuando el servidor pide atención, no hay a quién recurrir. El sistema sigue funcionando, y funcionar es precisamente lo que retrasa el mantenimiento. Nadie actualiza lo que no está roto, incluso cuando lo que está roto es invisible.

No existe ventana de mantenimiento

El entorno institucional tiene un calendario de paradas negociado con el rectorado. El departamental no. Cada semana es semana de exámenes, entrega de trabajos o cierre de notas. Sin una ventana acordada, la actualización del Moodle MAT del departamento siempre se pospone para "después del semestre", y el semestre nunca termina.

No existe homologación

Actualizar directamente en producción es una apuesta. Quien ha visto una actualización romper un plugin de fórmulas a las 23:00 de un domingo de exámenes no repite el error: simplemente deja de actualizar. El miedo, aquí, es racional. La solución también es simple: un clon del entorno para probar antes, pero requiere que alguien asuma la tarea.

La trampa de /public: por qué el salto al 5.1 se atasca

A partir de Moodle 5.1, el código se reestructuró. Solo la carpeta /public queda accesible desde la web; el núcleo, las bibliotecas y la configuración pasan a vivir fuera del directorio servido. Es una mejora real de seguridad, documentada en la guía de reestructuración del código — y también es el motivo por el que tantas actualizaciones se quedan atascadas.

Tres consecuencias prácticas:

• El document root del servidor debe apuntar a la carpeta /public. En Apache, DocumentRoot /var/www/moodle/public; en Nginx, root /var/www/moodle/public;. Sin este ajuste, Moodle simplemente no carga.
• El $CFG->wwwroot en el config.php no termina en /public. Cambiar esa línea por error es el error más común de quienes actualizan en hosting compartido, y genera un mensaje de error que asusta más de lo que debería.
• Los plugins de terceros instalados en la estructura antigua deben reubicarse en la ruta equivalente dentro de /public. Temas personalizados, plugins de fórmulas, integraciones de videoconferencia: cada uno debe revisarse individualmente.

En un Moodle MAT con diez plugins acumulados a lo largo de ocho años, el tercer punto suele ser el que mata el proyecto. Nadie recuerda quién lo instaló, de dónde vino, si aún se mantiene. La recomendación práctica que damos a nuestros clientes es siempre la misma: antes de tocar el servidor, exporta la lista de plugins adicionales y verifica la compatibilidad de cada uno con la versión objetivo. Un plugin abandonado es motivo suficiente para posponer la actualización, y para empezar a buscar un sustituto ahora, no en octubre.

El Moodle 5.2 sube el listón técnico (y trae IA en el núcleo)

El 5.2, lanzado el 20 de abril de 2026, elevó los requisitos mínimos: PHP 8.3 (con 8.4 soportado), PostgreSQL 16, MySQL 8.4, MariaDB 10.11 o SQL Server 2019. Si el servidor donde vive el Moodle MAT de tu departamento ejecuta PHP 8.1 y MariaDB 10.6 — configuración muy común en máquinas aprovisionadas alrededor de 2021 — la actualización deja de ser un problema de aplicación y se convierte en un problema de infraestructura. Eso cambia el plazo, el coste y quién debe aprobarlo.

En cuanto a funciones, la novedad que interesa a quienes dan clase es la entrada de dos proveedores de inteligencia artificial en el núcleo de Moodle: Google Gemini (plugin de la comunidad promovido a core) y AWS Bedrock. En la práctica, se puede activar generación de resúmenes, apoyo a la corrección y asistentes de curso sin depender de un plugin externo, algo que hasta 2025 requería integración manual.

Y aquí reside un riesgo nuevo. Uno de los boletines de junio, el MSA-26-0024, trataba precisamente de la verificación de permisos ausente en los web services de colocación de IA. Recurso nuevo significa superficie de ataque nueva. Si la decisión es habilitar IA en el entorno, la disciplina de actualización deja de ser opcional el mismo día.

¿Consolidar en el entorno institucional o mantener el Moodle MAT separado?

No existe una respuesta única. Existe un criterio. Después de operar entornos críticos de e-learning durante más de una década, así es como lo evaluamos:

Consolida en el entorno central cuando:

• El departamento usa solo funciones estándar (tarea, cuestionario, foro, calificación).
• No hay ningún plugin exclusivo en uso real, solo instalado.
• La base activa es pequeña y el coste de mantener un servidor propio no se amortiza.
• Nadie en el departamento quiere (o puede) asumir la responsabilidad técnica formal.

Mantén separado cuando:

• Existe una dependencia real de plugins que la TI central no homologa.
• El calendario académico del departamento no coincide con el institucional.
• Hay investigación, extensión o cursos de pago funcionando allí, con requisitos propios.
• Hay presupuesto y una persona designada para el mantenimiento, no buena voluntad, designación.

El error clásico es el término medio por inercia: mantener el Moodle MAT separado sin asumir la responsabilidad técnica que la separación exige. Es lo peor de ambos mundos: la autonomía sin el soporte, el riesgo sin el beneficio.

Checklist: auditando un Moodle departamental en una tarde

Esta guía sirve para auditar el Moodle MAT o cualquier instancia que hayas heredado. Lleva menos de tres horas y ya entrega un diagnóstico defendible:

1. Descubre la versión exacta. Administración del sitio → Notificaciones muestra la release instalada. Compárala con la tabla de ciclo de vida anterior.
2. Comprueba PHP y la base de datos. Administración del sitio → Servidor → Entorno indica qué está por debajo del mínimo de la próxima versión.
3. Enumera los plugins adicionales. Para cada uno, anota nombre, versión y si aún recibe actualizaciones en el directorio oficial.
4. Prueba la restauración de una copia de seguridad. Una copia que nunca se ha restaurado no es una copia, es una esperanza.
5. Verifica el cron. Sin cron ejecutándose con regularidad, las notificaciones, las copias de seguridad y las colas se detienen silenciosamente.
6. Revisa el certificado HTTPS y su fecha de caducidad. Renovación automática configurada, preferiblemente.
7. Revisa las cuentas con rol de administrador. Exbecarios y exprofesores suelen seguir ahí.
8. Confirma el registro del sitio en moodle.org: es lo que garantiza la recepción de alertas de seguridad por correo electrónico.
9. Verifica los web services de la app móvil. Si están activados, la app es una puerta de entrada que también necesita atención.
10. Registra un dueño y una ventana mensual. Sin estos dos elementos por escrito, todo el checklist se convierte en una foto, no en un proceso.

Qué hacer con esto aún en agosto

La ventana es corta y la cuenta es simple: un Moodle MAT o cualquier otro Moodle departamental parado en 5.0 pierde el soporte de seguridad el 5 de octubre de 2026, y los detalles de las fallas corregidas el 10 de agosto se hacen públicos esta misma semana. El orden de prioridad que sugerimos es aplicar el parche de la rama actual ahora, auditar plugins y entorno a continuación, y solo entonces planificar el salto, preferiblemente apuntando al 5.3 LTS de octubre.

Soy Cleverson Gouvêa, desarrollador full stack, certificado en Moodle y CTO de IEJUR. Desde 2008, al frente de Agathas Web, opero entornos de e-learning en servidores Linux con Redis y me ocupo exactamente de este tipo de instalación huérfana: actualización de versión, migración a la estructura /public, ajuste de infraestructura y consolidación de instancias dispersas. He visto Moodle de 2016 en producción con un plugin sin mantenimiento desde 2019: el escenario es más común de lo que parece.

Si el siguiente paso de tu departamento es llevar el entorno al móvil del alumno, vale la pena entender antes las opciones: comparamos la app oficial y la app propia en Moodle Mobile App vs app personalizada, detallamos el proceso de publicar la app Moodle en Google Play y App Store y mostramos el impacto real de las notificaciones push en el compromiso. Pero nada de eso funciona bien sobre una base desactualizada. La actualización va primero.

¿Quieres un diagnóstico de tu instancia antes de octubre? Habla con nosotros: la auditoría inicial no cuesta nada y el informe es tuyo, independientemente de si contratas o no.