Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
El fin de la vida útil (EOL) de MySQL es uno de los acontecimientos más trascendentales y más pospuestos en la gestión del ciclo de vida de las bases de datos empresariales. MySQL es la base de plataformas de comercio electrónico, aplicaciones SaaS, sistemas de gestión de contenidos, herramientas internas y flujos de datos en prácticamente todos los sectores. Esa omnipresencia es precisamente lo que hace que la gestión de su ciclo de vida sea tan importante y tan fácil de posponer hasta que se convierte en algo urgente.
Pero las versiones de MySQL no envejecen bien por sí solas. Cada una tiene un periodo de soporte definido y, cuando este finaliza, Oracle deja de publicar parches de seguridad para ella. Todas las vulnerabilidades CVE reveladas a partir de ese momento se aplican a tu versión, pero ninguna de las correcciones lo hace. Si utilizas MySQL 5.7, el fin de vida útil (EOL) de MySQL llegó en octubre de 2023. Si utilizas MySQL 8.0, llegará en abril de 2026, y esa fecha está más cerca de lo que la mayoría de los equipos creen.
En esta entrada se explica cómo funciona realmente el ciclo de vida de las versiones de MySQL, qué implica el fin de vida útil (EOL) de MySQL en términos de seguridad y cumplimiento normativo, y cuáles son tus opciones cuando no es posible programar una actualización para el próximo sprint.
Principales conclusiones
- Las dependencias multiplican la superficie de riesgo de fin de vida útil (EOL) de MySQL: MySQL incluye bibliotecas C de terceros como OpenSSL, curl, LZ4, zlib y otras, cada una de las cuales conlleva su propia exposición a vulnerabilidades CVE que dejan de recibir parches una vez que la versión de MySQL llega al final de su vida útil.
- Las actualizaciones precipitadas son costosas: Las actualizaciones de versión principales de MySQL implican la verificación de la compatibilidad de esquemas, pruebas de consultas de aplicaciones, reconfiguración de la replicación y despliegues coordinados en todo el parque de servidores. El coste de ingeniería de una migración no planificada rara vez es insignificante.
- El fin de la vida útil (EOL) de MySQL no significa el fin de la seguridad. El servicio Endless Lifecycle Support (ELS) de TuxCare ofrece parches continuos para las versiones de MySQL que ya no reciben soporte, cubriendo todas las dependencias, para que su infraestructura de bases de datos permanezca protegida mientras realiza la actualización según su propio calendario.
¿En qué consiste el ciclo de vida del producto de MySQL?
El ciclo de vida de MySQL sigue la Política de soporte de por vida de Oracle, que define tres fases distintas para cada versión principal:
- Soporte Premier 5 años a partir de la fecha de lanzamiento de la versión comercial. Durante esta fase, Oracle ofrece nuevas funciones, correcciones de errores, alertas de seguridad y actualizaciones de parches críticos con periodicidad trimestral a través del programa Critical Patch Update (CPU) de Oracle.
- Soporte ampliado 3 años tras el soporte Premier, por un coste adicional. Se siguen proporcionando alertas de seguridad y actualizaciones de parches críticos, pero no se incluyen nuevas funciones ni correcciones generales de errores.
- Soporte de mantenimiento Disponible una vez finalizado el soporte ampliado, por un periodo de tiempo indefinido. Es importante destacar que esta fase no ofrece nuevas versiones, nuevas correcciones de errores ni nuevos parches de seguridad. Solo se mantiene el acceso a las correcciones ya existentes.
Cuando la comunidad de bases de datos se refiere a que una versión de MySQL llega al final de su ciclo de vida, significa que dicha versión ha salido por completo del «soporte ampliado» o, como en el caso de MySQL 5.7, que Oracle la ha trasladado al «soporte de mantenimiento», lo que, a efectos prácticos, implica que a partir de ese momento no se publicarán nuevos parches de seguridad.
MySQL introdujo un modelo de lanzamiento de doble vía en 2023 para ofrecer a las organizaciones una mayor previsibilidad del ciclo de vida en el futuro:
- Las versiones de soporte a largo plazo (LTS) están diseñadas para garantizar la estabilidad en producción. Cada versión LTS cuenta con 5 años de soporte Premier y 3 años de soporte ampliado. MySQL 8.4 es la versión LTS actual.
- Versiones de innovación Versiones trimestrales que incluyen las últimas funciones. Cada versión de Innovation solo recibe soporte hasta que se lanza la siguiente, por lo que no son adecuadas para entornos de producción que necesitan ventanas de aplicación de parches predecibles.
| Versión de MySQL | Estado | Notas |
| 5.7 | Fin de vida útil: octubre de 2023 | Solo soporte técnico; no se proporcionarán nuevos parches de seguridad |
| 8.0 | Fin de vida útil: abril de 2026 | Fin del soporte ampliado: no habrá más parches a partir de abril de 2026 |
| 8.4 LTS | Compatible | Soporte Premier para la versión LTS actual hasta aproximadamente 2029 |
| 9.x (Innovación) | Rodando | Cada publicación queda sustituida por la siguiente publicación trimestral |
En resumen: si tu entorno utiliza MySQL 5.7, llevas sin aplicar los parches de seguridad del desarrollador desde octubre de 2023. Si utiliza MySQL 8.0, el reloj ya está corriendo hacia la fecha de fin de vida útil (EOL) de MySQL, fijada para abril de 2026.
¿Qué significa el fin de la vida útil de MySQL?
Se acabaron los parches de seguridad
Cuando una versión de MySQL pasa a la fase de soporte de mantenimiento, Oracle deja de desarrollar parches de seguridad para ella. Esto significa que todas las vulnerabilidades que se detecten a partir de ese momento en los componentes principales de MySQL, en su optimizador de consultas, en su sistema de replicación o en sus bibliotecas integradas recibirán un parche para las versiones que siguen recibiendo soporte, pero no para la tuya.
Esta es la realidad fundamental en materia de seguridad cuando se utiliza software sin soporte técnico a gran escala: la comunidad de investigación de vulnerabilidades y el propio equipo de seguridad de Oracle siguen detectando y dando a conocer problemas de forma continua. El ciclo trimestral de actualizaciones críticas (CPU), que antes proporcionaba correcciones para tu versión, deja de aplicarse a ella. Tu exposición a riesgos aumenta con cada ciclo de CPU que pasa sin que tu versión esté incluida en el alcance.
Riesgos de seguridad y cumplimiento tras el fin de la vida útil de MySQL
El panorama en materia de cumplimiento normativo es igualmente claro. La norma PCI DSS (requisito 6.3.3) exige que las vulnerabilidades críticas y de alta gravedad con una puntuación CVSS de 7,0 o superior se corrijan en el plazo de un mes desde el lanzamiento del parche para los sistemas incluidos en el ámbito de aplicación. Las normas HIPAA, FedRAMP y SOC 2 contienen requisitos similares para los entornos que regulan. Utilizar una versión de MySQL sin soporte técnico en cualquier entorno regulado significa operar una base de datos que no se puede parchear dentro de los plazos que exigen esos marcos normativos, lo que crea una brecha de cumplimiento que los controles compensatorios solo pueden subsanar parcialmente.
La función de MySQL como almacén de datos para las cargas de trabajo de las aplicaciones que contienen registros de clientes, transacciones financieras, credenciales de autenticación y datos críticos para el negocio lo convierte en un objetivo prioritario para cualquier atacante que detecte una implementación sin parches en una versión que ya no recibe soporte técnico.
Historial de CVE de MySQL
El historial de CVE de MySQL ilustra cómo se manifiesta en la práctica la vulnerabilidad tras el fin de la vida útil del producto.
CVE-2023-21980 CVSS 7.1: Alto. Esta vulnerabilidad afectaba al componente de programas de cliente de MySQL Server en las versiones 5.7.41 y anteriores, y 8.0.32 y anteriores. Un atacante con privilegios bajos y acceso a la red podía aprovechar esta falla para tomar el control total del servidor MySQL, comprometiendo simultáneamente la confidencialidad, la integridad y la disponibilidad. Oracle publicó parches para las versiones compatibles como parte de la Actualización de parches críticos de abril de 2023. Cualquier implementación que ejecutara MySQL 5.7 después de la fecha de fin de vida útil (EOL) de octubre de 2023 no recibió ninguna solución de Oracle en adelante; la corrección existía, pero solo para las versiones con soporte. Este es el patrón característico de la exposición de MySQL tras el fin de vida útil: se publican parches para las versiones con soporte, mientras que las implementaciones fuera de soporte acumulan CVE sin resolver y sin ninguna corrección disponible en el código fuente.
Lo que hace que esta tendencia sea especialmente significativa es su magnitud. En cada ciclo de revisión trimestral de Oracle se detectan habitualmente decenas de vulnerabilidades de MySQL en distintos componentes, como InnoDB, el optimizador, la replicación, el DDL, los programas de cliente y otros. Cada ciclo de revisión que transcurre tras el fin de vida útil (EOL) de MySQL supone un conjunto de correcciones que su implementación nunca recibe. La exposición acumulada aumenta con cada trimestre.
El problema de la superficie de dependencias
MySQL no es un binario independiente, sino un servidor compilado que incluye un amplio conjunto de bibliotecas C de terceros, cada una de las cuales presenta sus propios riesgos de vulnerabilidad. Cuando se distribuye MySQL, se vinculan o se incluyen bibliotecas como OpenSSL para el cifrado TLS, curl para operaciones HTTP, LZ4 para la compresión, zlib para la compresión general de datos y libevent para la gestión de eventos de red, entre otras.
Cada una de estas bibliotecas incluidas tiene su propio historial de CVE y su propio ciclo de lanzamiento independiente. La Actualización de Parches Críticos trimestral de Oracle soluciona las vulnerabilidades de estos componentes incluidos, actualizando la versión de OpenSSL que viene con MySQL cuando se da a conocer una vulnerabilidad crítica de TLS, o aplicando parches al curl incluido cuando se detecta un fallo en el manejo de la red.
Una vez que MySQL haya llegado al final de su ciclo de vida (EOL), tampoco se aplicarán a tu versión ninguna de esas actualizaciones de las bibliotecas incluidas. Una vulnerabilidad crítica de OpenSSL, un fallo de corrupción de memoria en curl y un desbordamiento de búfer en LZ4: todos estos problemas se corregirán en las versiones de MySQL que sigan recibiendo soporte, pero ninguno de ellos en la tuya. La superficie de riesgo no se limita al código de procesamiento de consultas propio de MySQL, sino que se extiende a todas las bibliotecas que MySQL ha compilado en su interior.
Esto quedó patente durante el periodo de soporte de MySQL 5.7: los avisos de parches de Tenable para las versiones de MySQL 5.7 incluían sistemáticamente CVE en componentes integrados como curl (CVE-2021-22901, un «use-after-free» que permite un posible RCE), LZ4 (CVE-2019-17543, un desbordamiento de pila) y OpenSSL (CVE-2021-3711, un desbordamiento de búfer que podría dar lugar a la toma de control del servidor) como vulnerabilidades solucionadas por las versiones de parches de MySQL, lo que demuestra exactamente hasta qué punto la exposición de las bibliotecas incluidas está integrada en la superficie de ataque de MySQL. Una vez que MySQL llegue al final de su vida útil (EOL), todas esas vías de corrección se cerrarán.
Opciones para mantener la seguridad y el cumplimiento normativo tras el fin de vida útil de MySQL
Actualiza a una versión compatible de MySQL
La migración a MySQL 8.4 LTS es la estrategia a largo plazo recomendada para cualquier organización que aún utilice MySQL 5.7 o que esté planificando con antelación ante la fecha de fin de vida útil de MySQL 8.0, fijada para abril de 2026. MySQL 8.4 LTS es la versión actual de Oracle apta para entornos de producción y con soporte a largo plazo, respaldada por el servicio Premier Support hasta aproximadamente 2029.
La complejidad de esa migración depende en gran medida de tu entorno. Una flota de servidores MySQL no se actualiza de la misma manera que una única instancia de desarrollo: requiere implementaciones coordinadas con control de cambios, despliegues por fases entre los equipos de aplicaciones, validación de la compatibilidad de esquemas con las capas ORM y las consultas de las aplicaciones, reconfiguración de las topologías de replicación y pruebas en entornos de staging que reflejen el de producción. Para las organizaciones que ejecutan MySQL 5.7 y actualizan directamente a la versión 8.4, la diferencia abarca dos versiones principales, lo que supone una superficie de compatibilidad adicional que verificar.
Migrar a una base de datos alternativa
Algunas organizaciones aprovechan el fin de vida útil (EOL) de MySQL como motivo para evaluar alternativas, como PostgreSQL, MariaDB o servicios gestionados de bases de datos en la nube que se encargan de la gestión del ciclo de vida de las versiones. Se trata de opciones realmente viables a largo plazo para algunos entornos, pero son proyectos de ingeniería que abarcan varios trimestres, no respuestas a un plazo de aplicación de parches.
Para la mayoría de las organizaciones que se enfrentan a una fecha de fin de vida útil a corto plazo, la migración de la plataforma no es una solución viable para subsanar las deficiencias inmediatas en materia de seguridad y cumplimiento normativo.
También puedes descubrir qué implica el fin de la vida útil (EOL) de MariaDB 10.6 para los equipos que estén barajando esa opción en nuestra guía detallada.
La opción recomendada: soporte técnico de ciclo de vida ilimitado de TuxCare para MySQL
El servicio Endless Lifecycle Support (ELS) de TuxCare para MySQL aborda directamente el problema de seguridad y cumplimiento normativo que plantea el fin de vida útil (EOL) de MySQL, sin necesidad de realizar una migración inmediata a una versión principal. TuxCare proporciona parches de seguridad continuos para las versiones de MySQL que ya no reciben soporte, cubriendo tanto los componentes propios de MySQL como las dependencias de bibliotecas de terceros incluidas, sin coste adicional, lo que permite que su parque de bases de datos mantenga una postura de seguridad defendible mientras planifica la actualización que realmente desea realizar.
El funcionamiento es sencillo: TuxCare supervisa el NVD, los avisos de seguridad de Oracle y los canales de seguridad de las bibliotecas de origen en busca de vulnerabilidades que afecten a MySQL y a sus componentes integrados; a continuación, adapta y distribuye las correcciones para las versiones fuera de ciclo de vida mediante procesos respaldados por un acuerdo de nivel de servicio (SLA). Tu versión de MySQL sigue funcionando. Mantienes tu nivel de cumplimiento normativo. Y el calendario de actualizaciones se ajusta a tus condiciones.
Los riesgos de precipitarse al actualizar MySQL
Cuando llegan las fechas de fin de vida útil (EOL) de MySQL, la presión para reaccionar de inmediato es real, pero el coste de una mala reacción es mayor de lo que la mayoría de los equipos prevé.
En qué consiste realmente una actualización de MySQL
Una actualización de versión principal de MySQL, especialmente de la 5.7 a la 8.4 en un entorno de producción, no es un reinicio gradual. Implica adaptar el código para cualquier consulta de aplicación, procedimiento almacenado o SQL generado por ORM que dependa de sintaxis o comportamientos que hayan cambiado entre versiones. Implica verificar la compatibilidad de todas las bibliotecas de clientes de bases de datos, conectores y versiones de ORM que utiliza la pila de tu aplicación, ya que las matrices de compatibilidad de versiones de marcos como Django, Rails, Hibernate y otros deben confirmarse con respecto a la versión de MySQL de destino. Implica adaptar la cadena de herramientas de los procesos de copia de seguridad, los exportadores de supervisión y las herramientas de migración de bases de datos que se integran directamente con los componentes internos de MySQL. Y conlleva una sobrecarga de pruebas de los planes de consulta, los cambios entre versiones del optimizador, los cambios en el comportamiento de los índices y los casos extremos en las consultas de la aplicación que solo se manifiestan bajo carga en condiciones similares a las de producción.
En una flota empresarial compuesta por cientos o miles de servidores de bases de datos con dependencias de aplicaciones heterogéneas, ventanas de aplicación de parches reguladas por procesos de control de cambios y dependencias de servicios que requieren una validación coordinada, se trata de un programa de trabajo coordinado, no de una migración de fin de semana.
¿Qué ocurre cuando se precipita la actualización?
Cuando los equipos se ven obligados a actualizar MySQL por un plazo de cumplimiento normativo en lugar de por estar preparados, el patrón que se sigue es siempre el mismo. La carga de soporte técnico se dispara a medida que los equipos de aplicaciones descubren problemas de compatibilidad en las consultas que no se detectaron en el entorno de staging. La inestabilidad del sistema se manifiesta en forma de retrasos en la replicación, comportamientos inesperados de los índices o regresiones en los planes de consulta que afectan a la latencia en producción. La deuda técnica se acumula a medida que se implementan soluciones provisionales para cumplir el plazo, lo que genera trabajo adicional que debe abordarse en sprints posteriores. Y los costes imprevistos se disparan en tiempo de ingeniería, en posibles interrupciones del servicio y en los gastos operativos de gestionar una migración cuyo alcance no se definió adecuadamente antes de comenzar.
Las organizaciones que gestionan adecuadamente las transiciones por fin de vida útil (EOL) de MySQL las abordan como migraciones planificadas, con un alcance definido, un tiempo de pruebas adecuado y una postura de seguridad estable que se mantiene en todo momento, y no como respuestas de emergencia ante un plazo para el que no estaban preparadas.
La solución sencilla: TuxCare ELS para MySQL
TuxCare lleva más de una década perfeccionando la automatización, los conocimientos técnicos y los procesos que le permiten distribuir de forma fiable y a gran escala parches de seguridad para software que ha llegado al final de su ciclo de vida. Con más de 220 000 parches distribuidos en toda su cartera de productos compatibles, TuxCare ha creado un flujo de trabajo de aplicación de parches que es a la vez rápido y seguro para el entorno de producción.
En el caso concreto de MySQL, el servicio ELS de TuxCare cubre el vacío de seguridad que deja el fin de la vida útil (EOL) de MySQL:
- Parches de seguridad rápidos y respaldados por un acuerdo de nivel de servicio (SLA). TuxCare supervisa continuamente las divulgaciones de vulnerabilidades y proporciona parches para CVE de alto riesgo y críticas (CVSS 7.0+) según los SLA definidos, lo que garantiza que sus implementaciones de MySQL cumplan con los plazos de aplicación de parches exigidos por PCI DSS, HIPAA, FedRAMP y otros marcos de cumplimiento.
- Cobertura completa de la superficie de dependencias: TuxCare cubre tanto la superficie de vulnerabilidad propia de MySQL como las bibliotecas de terceros incluidas (OpenSSL, curl, LZ4 y otras) sin coste adicional. La exposición oculta al fin de vida útil (EOL) en las dependencias compiladas de MySQL ya no será un problema para usted.
- Integración perfecta con tus flujos de trabajo actuales. Tanto si actualmente gestiona las actualizaciones de MySQL a través de gestores de paquetes, herramientas de gestión de la configuración o sus pipelines de CI/CD existentes, puede cambiar su fuente de actualizaciones al repositorio seguro de TuxCare con cambios mínimos en su flujo de trabajo actual. No se producirá ninguna interrupción en su cadena de herramientas actual.
- Paquetes firmados y a prueba de manipulaciones. Cada parche que TuxCare entrega se somete a exhaustivas pruebas de integridad, funcionalidad y regresión antes de llegar a su repositorio, y los paquetes están firmados criptográficamente para que sepa exactamente lo que está implementando.
- Asistencia especializada las 24 horas del día, los 7 días de la semana El equipo de seguridad de TuxCare está disponible las 24 horas del día para la clasificación de vulnerabilidades, las solicitudes de parches y la resolución de problemas, por lo que nunca tendrás que gestionar un incidente de seguridad relacionado con el fin de vida útil (EOL) de MySQL sin el apoyo de especialistas.
Para ver qué vulnerabilidades CVE de MySQL ya se han solucionado, TuxCare mantiene un rastreador de CVE en tiempo real. Para obtener más detalles sobre el proceso de aplicación de parches y los estándares de validación de TuxCare, consulte el documento técnico.
No dejes que el fin de la vida útil de MySQL ponga en riesgo tu infraestructura de bases de datos
El fin de la vida útil (EOL) de MySQL no significa que tus bases de datos queden comprometidas de inmediato. Sin embargo, sí implica que la protección de seguridad en la que se ha basado tu infraestructura ha desaparecido, y que cada vulnerabilidad CVE publicada a partir de ese momento supone un riesgo al que te expones sin que exista una vía de corrección por parte del proveedor.
Los equipos que gestionan bien esta situación son aquellos que abordan el fin de la vida útil (EOL) de MySQL como un problema de seguridad que hay que gestionar de forma planificada, y no como una fecha límite a la que hay que reaccionar bajo presión. Puedes planificar una migración planificada a MySQL 8.4 LTS cuando realmente se adapte a la capacidad de tu parque de servidores, a la preparación de tus equipos de aplicaciones y a los procesos de gestión del cambio de tu organización. Puede definir el alcance de la migración adecuadamente antes de comprometerse con un calendario. O puede utilizar TuxCare ELS para mantener la seguridad y el cumplimiento normativo mientras toma esas decisiones según sus propios términos, y no bajo el calendario de una auditoría de cumplimiento.
ELS para MySQL no es una solución provisional. Es la opción que garantiza la seguridad de tu parque de bases de datos, mantiene intacto tu nivel de cumplimiento normativo y permite que tus equipos de ingeniería se centren en desarrollar, en lugar de gestionar migraciones de emergencia.
Si el fin de la vida útil (EOL) de MySQL es una de tus prioridades de seguridad en este momento, visita el soporte de ciclo de vida ilimitado de TuxCare para software de código abierto para ver cómo el soporte ampliado puede proteger su infraestructura de bases de datos durante todo el tiempo que necesite.
