La serie community MariaDB 10.6 alcanzó el estado de end of life (EOL) y desde entonces no recibirá correcciones de seguridad ni actualizaciones. Esto deja a servidores que todavía ejecutan 10.6 expuestos a vulnerabilidades que seguirán corrigiéndose únicamente en las ramas mantenidas (10.11, 11.4, 11.8 y 12.3).
Qué significa el fin de vida de MariaDB 10.6
Cuando una versión entra en EOL, el proyecto deja de publicar correcciones de errores y de seguridad para esa serie. En el caso de MariaDB 10.6, su última entrega fue 10.6.28 y no habrá una 10.6.29. A partir de ahora, las correcciones se aplicarán a las series actualmente mantenidas y a las futuras ramas LTS que el proyecto publique.
Por qué es un riesgo para plataformas de hosting
En pilas tipo LAMP la base de datos está justo detrás del servidor web y contiene los datos que los atacantes buscan. MariaDB señala que muchas vulnerabilidades que se corrigen requieren únicamente un acceso con pocos privilegios a la base de datos; en hosting compartido, cada cliente y muchos plugins (por ejemplo de WordPress) tienen credenciales de ese nivel. Además, hay casos recientes en los que detalles de explotación se han hecho públicos y se han convertido en ataques masivos en pocas horas, lo que multiplica la urgencia de tener versiones mantenidas.
Opciones de migración: 11.8 o 12.3
MariaDB recomienda a administradores y equipos de plataforma migrar a 11.8 o a 12.3. Ambas series son LTS: 11.8 lleva tiempo estable y está presente en repositorios de Debian y Ubuntu LTS; 12.3 es la LTS más reciente y ofrece el mayor periodo de mantenimiento futuro. La migración desde 10.6 puede realizarse en un solo paso directo a 11.8 o 12.3 sin pasar por versiones intermedias, y no requiere volcar y recargar datos: los ficheros de datos se actualizan in situ.
Impacto operacional y compatibilidad
Según el anuncio, el protocolo de red, los conectores y el SQL utilizado por las aplicaciones siguen siendo compatibles desde 10.6 a 11.8, por lo que la mayoría de aplicaciones continuarán funcionando tras el upgrade. En un nodo de hosting típico, el tiempo de parada suele reducirse al tiempo necesario para detener el servidor, reemplazar paquetes y arrancarlo de nuevo, esto es, minutos en lugar de horas.
Notas para usuarios de Galera
Los clústeres Galera siguen la misma secuencia de actualización nodo a nodo. Un cambio relevante es que en 12.3 Galera se proporciona en un paquete separado (mariadb-server-galera), por lo que hay que tenerlo en cuenta al planificar la actualización del clúster.
Recomendaciones prácticas para administradores
- Auditar la flota para identificar nodos con MariaDB 10.6 y, dentro de estos, distinguir los que ya están en la última 10.6.28 y los que no; los que no estén en 10.6.28 están expuestos inmediatamente a todos los parches publicados tras su fecha de fin de vida.
- Planificar la migración a 11.8 o 12.3; decidir 11.8 si necesita compatibilidad amplia y presencia en repositorios LTS, o 12.3 si prefiere la versión con mayor horizonte de soporte.
- Probar la actualización en entornos staging antes de aplicarla en producción y validar conectores, backups y procedimientos de recuperación.
- En entornos con clientes que requieran más tiempo para adaptarse, valorar soluciones comerciales que ofrezcan soporte extendido para 10.6 mientras se completa la transición.
Para plataformas de hosting, la conclusión es clara: mantener bases de datos en una rama EOL convierte la capa persistente en un vector de riesgo. Actualizar a una rama LTS mantenida (11.8 o 12.3) elimina esa responsabilidad y permite recibir correcciones futuras que mitiguen nuevas vulnerabilidades.
Lee también:
- Comienza el desarrollo de Ubuntu 27.04 «Tenacious T‑Rex»: qué cambia y qué deben hacer los administradores
- Intel eleva ingresos por centros de datos mientras los PCs sufren por la subida de precios de memoria
Fuente: MariaDB.org
