MariaDB 10.6 llegará al final de su ciclo de vida el 6 de julio de 2026: qué significa esto y cómo mantener la seguridad

Principales conclusiones

• MariaDB Community Server 10.6 llegará al final de su ciclo de vida el 6 de julio de 2026. A partir de esa fecha, el proyecto MariaDB dejará de publicar parches de seguridad y correcciones de errores para la versión 10.6.
• Utilizar una base de datos sin parches en el entorno de producción supone un problema de seguridad y cumplimiento normativo. Las normas PCI DSS, HIPAA, SOC 2 y FedRAMP exigen la aplicación oportuna de parches para las vulnerabilidades conocidas.
• Actualizar a la versión 11.4 o 11.8 LTS es la mejor opción a largo plazo cuando se puede hacer de forma limpia. Cuando el plazo es ajustado, el soporte de ciclo de vida ilimitado de TuxCare para MariaDB mantiene la versión 10.6 actualizada con los parches necesarios para que puedas actualizar según tu propio calendario.

Si utilizas MariaDB Community Server 10.6 en un entorno de producción, hay una fecha que debes anotar en el calendario: el 6 de julio de 2026. Es entonces cuando la rama 10.6 llega al final de su vida útil y el proyecto MariaDB la cierra. A partir de ese momento, el proyecto dejará de publicar versiones, correcciones de errores y parches de seguridad para esa rama.

A partir del 6 de julio, tu base de datos seguirá respondiendo a las consultas exactamente igual que lo hacía el día anterior. El problema es lo que ocurre en segundo plano durante los meses siguientes: a medida que se detectan nuevas vulnerabilidades que nunca se corrigen, los auditores empiezan a hacer preguntas y el ecosistema en torno a la versión 10.6 sigue avanzando silenciosamente.

En esta entrada se aborda el calendario de la versión 10.6, qué cambios supone realmente el fin de la vida útil para tu entorno y las opciones realistas que tienes a tu alcance. Si buscas una respuesta rápida del tipo «solo tienes que actualizar, no pasa nada», aquí no la encontrarás. Actualizar una base de datos en producción rara vez es tan sencillo como parece a simple vista, y el objetivo aquí es ayudarte a elegir la opción que mejor se adapte a tu situación.

Figura 1. Versiones LTS de MariaDB y sus fechas de fin de vida útil según la comunidad. La versión 10.6 es la próxima en caducar.

Versiones y ciclos de vida de MariaDB, en pocas palabras

MariaDB ofrece dos tipos de versiones. Las versiones continuas se publican aproximadamente cada tres meses y solo reciben soporte hasta la siguiente versión. Las versiones de soporte a largo plazo (LTS) se publican aproximadamente una vez al año y cuentan con un periodo de mantenimiento más prolongado, con correcciones de errores y de seguridad. Los sistemas de producción deben utilizar una versión LTS.

MariaDB 10.6 es una versión LTS. Se lanzó por primera vez el 6 de julio de 2021, con un periodo de mantenimiento de cinco años, lo que sitúa el fin de su ciclo de vida el 6 de julio de 2026. Desde entonces, MariaDB ha cambiado el servidor Community a un modelo LTS anual con un periodo de mantenimiento de tres años, a partir de la versión 11.8 (la versión 11.4 sigue siendo una LTS de cinco años). A continuación se muestra la situación de las versiones LTS recientes a fecha de junio de 2026:

Hay dos aspectos que destacan. En primer lugar, las versiones 10.4 y 10.5 ya han superado su fecha de fin de vida útil, y la 10.6 es la siguiente, por lo que la mayor parte de la línea 10.x ha llegado al final de su ciclo de vida; la 10.11 LTS, con soporte hasta febrero de 2028, es la única excepción.  En segundo lugar, las versiones LTS con soporte son la 10.11 (hasta febrero de 2028), la 11.4 (hasta mayo de 2029), la 11.8 (hasta junio de 2028) y la 12.3 (la LTS más reciente, hasta 2029). Para los equipos que abandonan la versión 10.6, la 10.11 es el paso de compatibilidad más pequeño, pero con el plazo más corto, mientras que la 11.4 y la 12.3 ofrecen el soporte más prolongado y son las opciones en las que se centran la mayoría de las conversaciones sobre actualizaciones.

¿Qué ocurre cuando MariaDB 10.6 llega al final de su ciclo de vida?

El fin del ciclo de vida implica que se interrumpen todas las tareas de mantenimiento. En el caso de MariaDB 10.6, esto plantea tres problemas que se agravan con el tiempo:

1. Se suspende el envío de parches de seguridad

Esto es lo que realmente supone un riesgo. A partir del 6 de julio de 2026, las vulnerabilidades que afecten a MariaDB Community Server solo se corregirán en las ramas de la comunidad para las que se ofrece soporte, mientras que la versión 10.6 de Community Server ya no recibirá esas correcciones. El motor de la base de datos es un objetivo muy valioso —almacena los datos y, a menudo, es accesible desde los servidores de aplicaciones— y un solo fallo puede dejar al descubierto todo lo que hay detrás.

El patrón de explotación en las versiones al final de su ciclo de vida es bien conocido. Cuando un proyecto publica un parche para una versión compatible, la corrección es pública, por lo que los atacantes pueden ver exactamente qué código ha cambiado y deducir a partir de ahí el fallo subyacente. A continuación, buscan ese mismo fallo en las versiones al final de su ciclo de vida que nunca recibirán un parche. La automatización y el análisis asistido por IA pueden acelerar esa ingeniería inversa, por lo que la brecha entre un parche público y un exploit funcional puede reducirse rápidamente. Una base de datos de versiones EOL es exactamente el tipo de objetivo que este patrón favorece. 

2. Aumentan los riesgos relacionados con el cumplimiento normativo y las auditorías

La mayoría de los marcos de seguridad exigen la aplicación oportuna de parches para los problemas conocidos. El requisito 6 de la norma PCI DSS exige a las organizaciones identificar, clasificar por riesgo y corregir las vulnerabilidades, instalando los parches críticos y de alta gravedad en el plazo de un mes desde su publicación (6.3.3 en la versión 4.0.1). Los auditores de SOC 2 pueden señalar los componentes sin soporte cuando estos supongan un riesgo no resuelto para la gestión de vulnerabilidades o la gestión de cambios. En entornos regulados por la HIPAA, el software sin soporte puede plantear dudas sobre si las medidas de seguridad técnicas y las prácticas de gestión de riesgos siguen siendo razonables. FedRAMP y regímenes similares exigen la aplicación continua de parches, acompañada de la documentación correspondiente.

Lo frustrante es que la base de datos puede ser el único componente obsoleto en una infraestructura que, por lo demás, está en perfecto estado, y aun así dar lugar a una observación en una auditoría. Las revisiones de los seguros cibernéticos también pueden examinar minuciosamente el software sin soporte, especialmente cuando un incidente o un proceso de renovación pone de manifiesto deficiencias en la aplicación de parches y la gestión de vulnerabilidades.

3. El ecosistema se aleja

Una vez que una versión llega al final de su ciclo de vida (EOL), el software que la rodea deja de ser compatible con ella de forma gradual. Con el tiempo, las distribuciones de Linux, las imágenes de contenedores y los repositorios de terceros tienden a cambiar sus paquetes predeterminados de MariaDB por versiones más recientes y compatibles. Y, al cabo de seis meses, todo ello se traduce en una acumulación creciente de versiones fijadas y soluciones provisionales, y la actualización que venías posponiendo se ha vuelto, sin que te dieras cuenta, más difícil, en lugar de más fácil.

Figura 2. Las tres áreas de riesgo que se acumulan una vez que una base de datos llega al final de su vida útil.

¿Qué opciones tienes tras el fin de la vida útil de MariaDB 10.6?

La mejor opción para ti dependerá de la importancia de la base de datos, de la carga operativa que estés dispuesto a asumir y de tu calendario de actualización realista. Hay cuatro opciones que vale la pena tener en cuenta.

Figura 3. Cuatro opciones tras el fin del ciclo de vida de MariaDB 10.6, con las principales ventajas e inconvenientes de cada una.

Opción 1: Actualizar a una versión LTS compatible (10.11, 11.4, 11.8 o 12.3)

Esta es la respuesta más recomendable y la decisión más acertada cuando se puede llevar a cabo sin problemas. La migración a una versión LTS con soporte técnico restablece los parches de seguridad oficiales y, dependiendo de la versión de destino, puede aportar mejoras en áreas como el optimizador, el manejo de JSON, la replicación y las herramientas operativas. Por lo general, MariaDB mantiene la compatibilidad con los protocolos cliente-servidor, pero es necesario comprobar el comportamiento de las aplicaciones, la semántica SQL, la replicación y el formato del binlog, así como las versiones de los conectores y los ajustes de configuración, antes de realizar una actualización importante.

El problema es que un cambio de versión importante en una base de datos de producción requiere revisar el esquema y la configuración, validar las topologías de replicación, probar el comportamiento de las aplicaciones con la nueva versión y planificar un periodo de inactividad o una ventana de transición. MariaDB 11.0 introdujo un nuevo modelo de costes del optimizador —y algunas consultas pueden ralentizarse—, por lo que conviene ejecutar la carga de trabajo real en una copia de prueba para detectar cualquier cambio en el plan de ejecución antes de que llegue a producción. Un enfoque habitual de menor riesgo consiste en validar la versión de destino con una réplica o una copia de prueba restaurada bajo tráfico real y, a continuación, planificar la ruta de transición y de reversión antes de promocionarla. La estrategia exacta de replicación y promoción depende de su topología y del número de versiones principales que abarque el salto, por lo que debe confirmar primero la ruta de actualización compatible. 

Opción 2: Cambiar a MariaDB Enterprise Server

MariaDB plc comercializa una versión comercial Enterprise Server de la versión 10.6, para la que ofrece soporte técnico hasta el 23 de agosto de 2029, aproximadamente tres años más allá de la fecha límite de la comunidad. Dado que se mantiene en la serie 10.6, el cambio se asemeja más a un cambio de distribución que a una actualización de versión principal, y añade características empresariales y soporte del proveedor.

Las desventajas son una costosa suscripción de pago, un cierto grado de dependencia del proveedor y el paso de la distribución de la comunidad a una distribución binaria diferente. Para los equipos que necesitan específicamente MariaDB Enterprise Server 10.6, respaldado por el proveedor y con soporte para el cumplimiento de STIG, puede ser una opción razonable. Para los equipos cuyo objetivo principal es mantener actualizada su implementación de código abierto existente, puede suponer un cambio mayor del que el problema requiere.

Opción 3: Mantenerlo uno mismo o crear una bifurcación

En principio, puedes utilizar el código fuente de 10.6, de código abierto, realizar un seguimiento de los CVE por tu cuenta e incorporar las correcciones a tu propia compilación. En la práctica, esto es difícil de mantener. La incorporación de correcciones de seguridad en bases de datos requiere ingenieros capaces de leer y aplicar parches correctamente en un código fuente extenso escrito en C y C++, validar las correcciones y hacerlo según el calendario marcado por la aparición de nuevas vulnerabilidades, en lugar del que tú preferirías. La mayoría de los equipos no pueden contar con personal tan fiable, y un esfuerzo a medias es peor que no tener ningún plan, ya que crea una falsa sensación de cobertura.

Opción 4: Seguridad ampliada con asistencia técnica de por vida

Este es el término medio pragmático que los equipos suelen subestimar. El soporte de ciclo de vida ilimitado de TuxCare para MariaDB mantiene su implementación actual de la versión 10.6 actualizada contra nuevas vulnerabilidades tras la fecha de fin de vida útil de la comunidad. TuxCare realiza un seguimiento de los CVE en MariaDB, adapta las correcciones a su versión de código abierto y las entrega como sustituciones de paquetes listas para usar a través del gestor de paquetes que ya utiliza. No es necesario reescribir la aplicación, y el objetivo es preservar los flujos de trabajo de replicación y copia de seguridad existentes con una interrupción operativa mínima.

El objetivo de esta opción es desvincular la urgencia en materia de seguridad de la capacidad técnica. Los parches siguen llegando, la aplicación sigue funcionando y tu equipo realiza las actualizaciones según un calendario determinado por las circunstancias técnicas, en lugar de por una fecha fija. Es la opción adecuada cuando, siendo realistas, la actualización no va a estar terminada antes del 6 de julio de 2026, cuando tienes obligaciones de cumplimiento normativo que exigen la aplicación continua y documentada de parches, o cuando la implementación es estable y, sencillamente, no justifica una actualización importante y apresurada en este momento.

Por qué actualizar no siempre es la solución inmediata

La actualización es la solución ideal sobre el papel. En la práctica, la cosa es más complicada, por varias razones que es fácil pasar por alto.

Las dependencias y las integraciones suelen ser los verdaderos obstáculos. El motor MariaDB en sí mismo rara vez ralentiza las actualizaciones. Lo que las ralentiza es el código de la aplicación, los procedimientos almacenados, la configuración de la replicación y las herramientas asociadas, todos los cuales se basan en el comportamiento de tu versión actual. Resolver estos aspectos lleva tiempo, algo que una fecha de fin de vida útil (EOL) fija no tiene en cuenta.

Las actualizaciones precipitadas salen muy caras. Conllevan errores, pasan por alto casos extremos y se saltan pasos en las pruebas. El coste se refleja al trimestre siguiente en forma de incidencias y carga de guardias, y a menudo supera el coste de una actualización más lenta y planificada, incluso teniendo en cuenta el soporte técnico ampliado.

Algunos sistemas no justifican el esfuerzo en este momento. Una base de datos que sustenta una aplicación cuya sustitución está prevista, o una que ejecuta una carga de trabajo fija sin planes de nuevas funcionalidades, puede que no justifique una actualización importante este año. Para esos sistemas, aplicar parches a la versión actual hasta el cambio previsto es una decisión de ingeniería defendible, más que un atajo.

Protege MariaDB 10.6 sin necesidad de actualizar, con TuxCare

MariaDB 10.6 tiene una fecha límite: el 6 de julio de 2026. A partir de entonces, el proyecto dejará de publicar parches, y cada nueva vulnerabilidad comenzará a acumularse en todos los servidores que sigan ejecutando la versión 10.6. Actualizar a una versión LTS compatible —10.11, 11.4, 11.8 o 12.3— es la solución adecuada cuando se puede hacer de forma limpia y en un plazo razonable. Cuando no sea posible, ya sea porque las dependencias no están listas, el plazo es demasiado ajustado o la implementación no justifica la interrupción, el soporte ampliado te mantiene seguro sin obligarte a realizar una migración inadecuada.

El soporte de ciclo de vida ilimitado de TuxCare para MariaDB cubre esa carencia con parches de seguridad continuos y respaldados por un SLA para las versiones de MariaDB al final de su ciclo de vida, que se distribuyen a través de su gestor de paquetes actual sin necesidad de modificar el código. Si desea saber cómo se adapta a su entorno, hable con un experto de TuxCare. El objetivo es darle el control sobre el calendario de actualizaciones, no sustituirlo.

Resumen

Nombre del artículo

Fin de la vida útil de MariaDB 10.6

Descripción

MariaDB 10.6 dejará de recibir soporte técnico el 6 de julio de 2026. Conoce los riesgos de seguir utilizándola sin parches y cuatro formas de mantenerla segura: TuxCare ELS.

Autor

Artem Karasev

Nombre del editor

TuxCare

Logotipo de la editorial