“Llevamos años con esta versión y nunca ha pasado nada” es, paradójicamente, el argumento que más debería preocupar a quien lo dice. Que no haya pasado nada visible no significa que no haya riesgo acumulado, significa que, hasta ahora, nadie ha explotado activamente las vulnerabilidades que se han ido descubriendo desde que esa versión dejó de recibir parches.
En esta guía vas a ver por qué una versión sin soporte es un riesgo creciente, no estático, con ejemplos reales de vulnerabilidades recientes que ilustran el tipo de exposición al que te enfrentas.
La falacia del “si funciona, no lo toques”
“Si funciona, no lo toques” es una regla razonable para una tubería o un motor. Para software conectado a internet es justo al revés: lo que hace que “funcione” hoy no tiene nada que ver con lo que lo hace seguro mañana. Un Moodle sirve cursos, guarda notas y deja entrar a los alumnos exactamente igual el día que sale del soporte que el día anterior, la funcionalidad es idéntica. Lo que cambia, en silencio, es que a partir de esa fecha cada fallo de seguridad nuevo que se descubre ya no se arregla para ti.
El error de razonamiento es confundir ausencia de incidente con ausencia de riesgo. No son lo mismo. Que nadie haya entrado todavía puede querer decir que tu sitio no ha aparecido aún en el radar de un escáner automático, no que sea inexpulnable. Los ataques contra LMS rara vez son dirigidos: son bots que rastrean internet buscando versiones concretas con vulnerabilidades conocidas y publicadas. El día que tu versión entra en esa lista, dejas de decidir tú cuándo “toca revisarlo”.
Hay un segundo coste escondido en el “no lo toques”: cada mes que esperas, la actualización que algún día tendrás que hacer se vuelve más grande y más arriesgada. El “no lo toques” no congela el problema, lo capitaliza con intereses.
Por qué el riesgo crece con el tiempo, no se mantiene constante
Cada mes que pasa, se descubren y publican nuevas vulnerabilidades que afectan también a versiones antiguas de Moodle, solo que, si tu versión está fuera de soporte, esas vulnerabilidades nunca reciben parche para ti. El resultado es una superficie de ataque que crece de forma acumulativa: no es el mismo riesgo el primer mes tras quedar sin soporte que tres años después, con docenas de vulnerabilidades adicionales descubiertas mientras tanto y ninguna de ellas corregida en tu instalación.
La razón por la que la superficie crece y no se mantiene plana es que la investigación de seguridad no se detiene cuando tu versión sale de soporte. Los investigadores siguen auditando el código de Moodle, y muchos de los fallos que encuentran en el código actual también estaban presentes (a veces desde hace años) en tu versión antigua. Cuando ese fallo se publica junto con su parche, el parche llega a las versiones soportadas; a la tuya solo llega la mitad pública de la ecuación: la descripción de cómo explotarlo. Esta es la asimetría que hace peligrosa una versión legacy: la información sobre cómo atacarla es pública, pero la corrección no existe para ti.
Conviene resumir cómo se ve esa acumulación en el tiempo, porque el salto entre “recién salido de soporte” y “tres años después” no es lineal en la práctica:
| Tiempo desde el fin de soporte | Estado de tu instalación | Riesgo práctico |
|---|---|---|
| Mes 0 | Al día en el instante del corte | Bajo: aún no se han publicado fallos nuevos posteriores al corte |
| 6-12 meses | Varios avisos publicados sin parche disponible para ti | Medio: exploits documentados empiezan a circular |
| 1-2 años | Vulnerabilidades acumuladas, algunas de severidad alta | Alto: tu versión aparece en firmas de escáneres automáticos |
| 3+ años | Superficie amplia + PHP/base de datos también fuera de soporte | Crítico: exposición conocida y salto de migración muy grande |
Qué clases de vulnerabilidad acumula un LMS sin parchear
No hace falta conocer cada fallo concreto para entender a qué te expones. A nivel conceptual, las vulnerabilidades que se descubren año tras año en un LMS web caen en unas pocas familias, y cada una tiene una consecuencia distinta si alguien la explota.
| Clase de vulnerabilidad | Qué le permite al atacante | Dónde aparece en un LMS |
|---|---|---|
| Inyección y ejecución de código | Ejecutar consultas o código propio en tu servidor | Inyección SQL en plugins, restauración de backups manipulados |
| Escalada de privilegios | Pasar de un rol limitado a uno con más permisos | Un usuario o profesor que gana capacidades de administrador |
| Exposición de datos | Ver información que no le corresponde | Control de acceso roto en informes o descargas |
| Denegación de servicio | Tumbar el sitio o degradarlo gravemente | Funciones de renderizado o generación de contenido pesado |
La inyección y ejecución de código es la más grave: si un atacante consigue ejecutar código en tu servidor, deja de importar el resto, controla la máquina. La escalada de privilegios es traicionera porque el punto de entrada suele ser una cuenta legítima y de bajo perfil (un alumno, un profesor) que, aprovechando el fallo, termina con permisos que nunca debió tener. La exposición de datos no necesita ni “romper” nada visible: basta con pedir una URL o un informe que la aplicación debería negarte y no lo hace. Y la denegación de servicio no roba datos, pero deja el campus caído justo cuando lo necesitas, un examen, una entrega, una convocatoria FUNDAE con fecha de cierre.
Ejemplos reales de por qué esto no es teórico
Los avisos de seguridad recientes de Moodle ilustran bien la variedad de vectores que se van descubriendo con el tiempo: vulnerabilidades de inyección SQL en plugins de autenticación, riesgos de ejecución de código a través de la restauración de backups manipulados, fallos de control de acceso en informes que exponen datos más allá de lo que debería ver un usuario, y vulnerabilidades de denegación de servicio en funciones de renderizado de contenido. Cada una de estas categorías se sigue descubriendo activamente, versión tras versión, lo que significa que una instalación antigua acumula, con el tiempo, un conjunto cada vez mayor de puntos débiles conocidos y sin corregir.
Qué gana un atacante con tu Moodle desactualizado (y cuánto te cuesta a ti)
Es fácil pensar “¿qué va a querer nadie de mi campus?”. Bastante, en realidad. Lo primero y más obvio son los datos de tus alumnos: nombres, correos, DNIs en algunos casos, notas, historial de actividad. Son datos personales, y su fuga es una brecha de seguridad con consecuencias legales, no solo técnicas.
Pero muchos ataques ni siquiera van a por tus datos. Buscan usar tu servidor como pivote: una vez dentro, tu Moodle sirve para enviar spam, alojar páginas de phishing, minar criptomoneda o saltar a otras máquinas de tu red. Tu campus se convierte en infraestructura del atacante, y tú pagas el alojamiento. Otra motivación clásica es el defacement: sustituir tu portada por un mensaje del atacante, que arruina la confianza de alumnos y clientes en cuestión de minutos.
El coste para ti no se mide solo en el incidente técnico, sino en tres frentes que suelen doler más:
- RGPD: una brecha que exponga datos personales de alumnos es notificable, y “estábamos en una versión sin soporte con vulnerabilidades conocidas” es exactamente el tipo de negligencia que agrava una sanción. No haber parcheado un fallo público no es un atenuante, es lo contrario.
- Reputación: un campus caído o desfigurado durante una convocatoria es lo que ven tus alumnos y tus clientes. La confianza tarda mucho más en reconstruirse que el servidor.
- FUNDAE: si impartes formación bonificada, la disponibilidad y la integridad de los registros del campus no son opcionales. Un incidente que comprometa los datos de seguimiento puede poner en cuestión la bonificación de una acción formativa entera.
Cómo saber si tu versión sigue soportada
Antes de decidir nada, necesitas dos datos: qué versión tienes y si esa versión sigue recibiendo parches. El primero lo confirmas desde Administración del sitio > Servidor > Entorno (o Site administration > Server > Environment), donde aparece la versión exacta de Moodle, de PHP y de la base de datos.
El segundo lo resuelve el ciclo de releases oficial. Moodle publica su calendario de versiones y las fechas de fin de soporte general y de fin de soporte de seguridad en moodledev.io/general/releases. Ahí verás dos ventanas distintas para cada versión: el soporte general (correcciones de bugs y seguridad) y, más largo, el soporte de seguridad. Cuando tu versión pasa la segunda fecha, deja de recibir parches de cualquier tipo, es el punto en el que empieza a contar el reloj de este artículo.
Las versiones LTS (Long Term Support) tienen una ventana de soporte más amplia que las intermedias, y por eso son la referencia natural cuando planificas hacia dónde saltar: te dan más margen antes del siguiente corte obligatorio. Si no tienes claro qué versiones son LTS ni cuánto dura su ventana, lo explicamos en qué es Moodle LTS y cuándo debes actualizar.
Con esos dos datos en la mano, el diagnóstico de riesgo real es directo:
- Confirma tu versión exacta desde
Administración del sitio > Servidor > Entorno. - Compárala contra el calendario oficial en moodledev.io/general/releases para saber si sigue dentro de la ventana de parches de seguridad.
- Revisa los avisos de seguridad publicados desde que tu versión quedó sin soporte, cada uno representa una vulnerabilidad que tu instalación probablemente sigue teniendo, sin corrección disponible.
- Evalúa si algún aviso reciente afecta a funcionalidades que usas activamente (autenticación externa, repositorios de archivos, restauración de backups), ya que el riesgo real depende de qué partes de Moodle tienes habilitadas.
Por qué “no exponer el sitio a internet” no es suficiente mitigación
Es tentador pensar que, si el Moodle solo es accesible dentro de una red interna o mediante VPN, el riesgo de una versión sin soporte es menor. Esto reduce parte de la superficie de ataque externa, pero no elimina vulnerabilidades que se explotan desde dentro de la red (por ejemplo, mediante un usuario autenticado malicioso, o un ordenador comprometido dentro de esa misma red), ni protege contra vulnerabilidades que afectan a la integridad de backups o a la exposición de datos internos.
La deuda técnica que se acumula al retrasar la actualización
Cuanto más tiempo pasa una instalación sin actualizar, más difícil se vuelve el salto de versión cuando finalmente toca hacerlo: más versiones intermedias que atravesar, más plugins que revisar por posible incompatibilidad acumulada, y más riesgo de que algún plugin crítico ya no tenga ningún desarrollo activo para versiones recientes. Retrasar la actualización no solo mantiene el riesgo de seguridad, también incrementa el esfuerzo y el riesgo técnico del salto que, tarde o temprano, hay que dar.
Qué hacer si no puedes actualizar ya mismo
Actualizar es la única solución de fondo, pero a veces no se puede hacer hoy: hay una convocatoria abierta, falta presupuesto, o el salto necesita planificarse bien. En ese caso, hay mitigaciones temporales que reducen la exposición mientras preparas la migración. Ninguna sustituye a actualizar, solo compran tiempo.
| Mitigación temporal | Qué riesgo reduce | Qué NO cubre |
|---|---|---|
| WAF delante del sitio | Filtra patrones de ataque conocidos (SQLi, XSS) | Fallos de lógica, exploits no firmados, ataques desde dentro |
| Restringir accesos (IP, VPN, 2FA admin) | Reduce quién puede alcanzar el panel | Vulnerabilidades explotables por un usuario ya autenticado |
| Desactivar plugins/funciones no esenciales | Elimina superficie mencionada en avisos | El núcleo de Moodle y lo que sí usas |
| Backups verificados y frecuentes | Acelera la recuperación tras un incidente | No previene la brecha, solo limita el daño |
| Revisión más frecuente de logs | Detecta antes un intento o una entrada | No impide el ataque, solo acorta el tiempo de reacción |
El orden en que las aplicas importa. Un WAF delante del campus filtra buena parte del ruido automático (los bots que prueban exploits conocidos) pero no entiende la lógica de Moodle, así que no te salva de un fallo que se dispara con una petición perfectamente legítima en apariencia. Restringir accesos (limitar el panel de administración por IP, meter el sitio tras VPN, forzar 2FA en las cuentas admin) reduce cuánta gente puede siquiera intentarlo, pero no hace nada frente a un usuario que ya tiene cuenta. Por eso ninguna de estas medidas es un destino: son un puente. La ruta de fondo es planificar la actualización completa siguiendo la secuencia de versiones LTS intermedias necesarias, como se detalla en migración y actualización de Moodle.
Qué hacer si estás en una versión sin soporte ahora mismo
- No esperes a “encontrar el momento perfecto”: cuanto más se retrasa, mayor es tanto el riesgo acumulado como el esfuerzo de la migración futura.
- Prioriza migrar si usas funcionalidades mencionadas en avisos recientes (autenticación externa, repositorios de archivos en la nube, restauración de backups), ya que esas áreas concentran vulnerabilidades documentadas recurrentes.
- Aplica las mitigaciones temporales de la tabla anterior mientras planificas la migración, sabiendo que son un puente, no un sustituto.
- Planifica la ruta de actualización completa, siguiendo la secuencia de versiones LTS intermedias necesarias, como se detalla en migración y actualización de Moodle.
Preguntas frecuentes
¿Qué significa exactamente que una versión esté “sin soporte”? Que ha dejado de recibir parches de seguridad oficiales, incluso para vulnerabilidades críticas descubiertas después de esa fecha.
¿El riesgo es el mismo el primer mes sin soporte que varios años después? No, el riesgo crece de forma acumulativa: cada vulnerabilidad nueva descubierta después de esa fecha se suma a las anteriores, sin que ninguna reciba corrección.
¿Estar en una red privada sin acceso público reduce el riesgo a cero? Reduce parte de la superficie de ataque, pero no elimina vulnerabilidades explotables desde dentro de la red o relacionadas con integridad de datos y backups.
¿Cómo sé qué vulnerabilidades concretas afectan a mi versión desactualizada? Revisando los avisos de seguridad publicados por Moodle desde la fecha en que tu versión dejó de recibir soporte, prestando especial atención a las que mencionan funcionalidades que tienes activas.
¿Puedo aplicar parches de seguridad manualmente en una versión sin soporte? No de forma oficial: los parches se publican solo para versiones dentro de la ventana de soporte activo, por lo que una versión legacy no recibe estas correcciones salvo que alguien las adapte manualmente, algo poco práctico y arriesgado.
¿Cuánto más difícil es migrar cuanto más se retrasa? Significativamente: más versiones intermedias que atravesar, más plugins que revisar por incompatibilidad acumulada, y mayor riesgo de que algún plugin crítico ya no tenga desarrollo activo disponible.
¿Qué debo priorizar si no puedo migrar de inmediato? Revisar qué funcionalidades activas coinciden con las áreas mencionadas en avisos de seguridad recientes, y aplicar mitigaciones temporales (desactivar funciones no imprescindibles, reforzar el firewall) mientras planificas la migración completa.
¿Un WAF me protege lo suficiente como para quedarme en la versión antigua? No. Un WAF filtra patrones de ataque conocidos y frena buena parte del ruido automático, pero no entiende la lógica interna de Moodle: no te protege de un fallo que se explota con una petición aparentemente legítima, ni de un usuario ya autenticado. Es un puente para ganar tiempo, no un sustituto de actualizar.
Si me entran por una versión sin soporte, ¿el RGPD lo considera negligencia? Estar en una versión con vulnerabilidades conocidas y sin parche disponible es justo el tipo de situación que agrava la valoración de una brecha. No haber aplicado una corrección pública no es un atenuante; refuerza la idea de que no se adoptaron las medidas técnicas razonables que exige la normativa.
¿Dónde consulto las fechas oficiales de fin de soporte de mi versión? En el calendario de releases de Moodle, en moodledev.io/general/releases, donde figuran la fecha de fin de soporte general y la de fin de soporte de seguridad de cada versión. Cuando tu versión pasa la segunda, deja de recibir parches de cualquier tipo.
¿Actualizar a la última versión me deja tranquilo para siempre? No para siempre, pero sí te devuelve a la ventana de parches: mientras estés en una versión soportada (idealmente una LTS, con ventana más amplia), recibes correcciones de seguridad. El objetivo no es “no tocarlo nunca más”, sino no volver a caer fuera de soporte sin planificarlo.
Conclusión
Una versión de Moodle sin soporte no es un riesgo estático que se puede posponer indefinidamente sin coste, es una superficie de ataque que crece cada mes que pasa, mientras el esfuerzo de la migración futura también aumenta en paralelo. Cuanto antes se planifique el salto a una versión con soporte activo, menor es tanto el riesgo acumulado como el esfuerzo real de dar ese paso.
Si prefieres que alguien evalúe el riesgo real de tu versión actual antes de decidir cuándo migrar, en Avantys lo incluimos en la auditoría de cada Moodle que revisamos. Puedes pedirla gratis en Moodle Gestionado.
Artículos relacionados
- Mantenimiento y hosting Moodle: guía completa
- Qué es Moodle LTS y cuándo debes actualizar
- Migración y actualización de Moodle
- Cómo proteger Moodle de ataques y vulnerabilidades
¿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.
