Fin de la vida útil de Ubuntu 22.04: fechas clave, riesgos y próximos pasos

Principales conclusiones

• Ubuntu 22.04 LTS (Jammy Jellyfish) llegará al final del periodo de mantenimiento de seguridad estándar de Canonical en mayo de 2027.
• Los sistemas que se quedan en la versión 22.04 siguen funcionando, pero dejan de recibir parches de seguridad gratuitos.
• Actualizar a Ubuntu 24.04 y, posteriormente, a 26.04 LTS es la solución definitiva a largo plazo.
• Si esa jugada no llega a tiempo, el soporte de ciclo de vida ilimitado de TuxCare sigue proporcionando parches.

Tus servidores 22.04 siguen arrancando. Siguen gestionando el tráfico. Siguen superando todas las comprobaciones de estado. Y ahí radica precisamente el problema. El fin de la vida útil de Ubuntu 22.04 no se percibe como una interrupción del servicio. El mantenimiento de seguridad estándar finaliza en mayo de 2027, y los servidores siguen funcionando sin problemas mientras los parches gratuitos dejan de llegar discretamente.

Este artículo aborda las fechas exactas del ciclo de vida, qué es lo que realmente deja de funcionar cuando finaliza el soporte (y qué no), por qué la migración suele llevar más tiempo del previsto y las opciones concretas para seguir recibiendo parches una vez pasada la fecha límite.

Fechas importantes del ciclo de vida de soporte técnico de Ubuntu 22.04

Ubuntu 22.04 LTS (Jammy Jellyfish) se lanzó el 21 de abril de 2022. Al igual que todas las versiones LTS, cuenta con cinco años de mantenimiento de seguridad estándar para los paquetes del repositorio «main», con extensiones opcionales de pago adicionales. Aquí tienes un resumen completo de la cronología.

Fase	Fecha	Qué significa
Disponibilidad general	Abril 21, 2022	Primera versión LTS
Fin del mantenimiento de seguridad estándar	May 2027	Parches CVE gratuitos para la parada principal
Fin de la cobertura de Ubuntu Pro ESM	May 2032	El servicio ESM de pago abarca el índice principal y el universo
Fin de la cobertura de la extensión «Legacy»	May 2037	Última prórroga pagada; 15 años en total

La fecha más importante es mayo de 2027. Hasta entonces, «apt upgrade» obtiene parches de seguridad gratuitos del repositorio de Ubuntu. A partir de entonces, los paquetes del repositorio «main» dejarán de recibir esas correcciones, a menos que te pases a una cobertura ampliada, como Ubuntu Pro. El sistema seguirá funcionando, pero dejará de recibir correcciones de forma gratuita.

¿Qué ocurre cuando Ubuntu 22.04 llegue al final de su ciclo de vida?

El fin de la vida útil no es una fecha límite flexible que se pueda pasar por alto discretamente. En el momento en que se produce, cambia el perfil de riesgo de todos los sistemas 22.04 que aún están en producción. El mismo hardware, la misma carga de trabajo, pero una superficie de ataque diferente. Estos riesgos se acumulan y se agravan cada mes que se mantiene la situación sin cambios.

1. Las vulnerabilidades CVE sin parchear pasan a ser permanentes

Las vulnerabilidades reveladas después de mayo de 2027 ya no recibirán correcciones a través del mantenimiento de seguridad estándar de la versión 22.04. Sin algún tipo de cobertura ampliada, permanecerán sin parchear indefinidamente, incluso después de que se haga público el código de explotación. Para hacerse una idea del volumen que esto supone, LinuxCVETracker había registrado más de 4.800 CVE del núcleo de Linux para 2026 a finales de agosto, de los cuales 359 estaban clasificados como «críticos» y 1.896 como «altos».

Una de ellas ya ha pasado de la teoría a la práctica. CVE-2026-31431, apodado «Copy Fail», se añadió al catálogo de Vulnerabilidades Conocidas y Explotadas (KEV) de la CISA el 1 de mayo de 2026. Se trata de una falla de escalada de privilegios locales introducida por un cambio en el núcleo en 2017 que permite a un usuario local sin privilegios acceder directamente a los privilegios de root, y tiene una puntuación CVSS de 7,8 (ALTA).

Eso es un año, y solo el núcleo. El Informe sobre el panorama del código abierto de TuxCare de 2026 reveló que, entre las organizaciones que notificaron un incidente de ciberseguridad, el 61,4 % afirmó que el incidente se produjo cuando ya había un parche disponible y simplemente no se había aplicado. Sin una cobertura ampliada, el parche no llega tarde. Es posible que ni siquiera haya ningún parche disponible a través del canal estándar.

2. Cada vez es más difícil superar las auditorías de cumplimiento

PCI DSS, HIPAA, SOC 2y RGPD exigen que se gestionen las vulnerabilidades conocidas y se mantengan los controles de seguridad adecuados, y un sistema operativo al final de su ciclo de vida hace que sea mucho más difícil defender esa postura. La norma PCI DSS es la más explícita al respecto. El software sin soporte técnico puede hacer que los requisitos de aplicación de parches sean inalcanzables y, aunque a veces se acepta un control compensatorio diseñado adecuadamente, hay que documentar la limitación y demostrar que el control aborda realmente el riesgo. Se trata de una carga de cumplimiento mucho más pesada que mantener el sistema actualizable.

El coste derivado tampoco es teórico. El Informe de IBM de 2026 sobre el coste de una filtración de datos sitúa el coste medio global de una filtración en la cifra récord de 4,99 millones de dólares, lo que supone un aumento del 12 % respecto al año anterior.

3. El ecosistema de software te deja atrás

Esto se va infiltrando poco a poco, y por eso la gente lo subestima. Los agentes de supervisión dejan de dar soporte a las versiones antiguas. Los entornos de ejecución de los lenguajes más recientes no se compilan con bibliotecas del sistema obsoletas. Al final, incluso los equipos de soporte de los proveedores dejan de atender las incidencias de los sistemas que han llegado al final de su vida útil, y para entonces ya estás actuando a ciegas.

Por qué la migración no siempre es sencilla

Sobre el papel, la actualización parece consistir en un solo comando. En la práctica, es todo un proyecto, y al definir su alcance siempre surge algo más que un simple cambio de versión. Pone de manifiesto todas las suposiciones que tu pila tecnológica ha hecho de forma implícita sobre el sistema operativo subyacente. Estos son los tres puntos conflictivos que suelen convertir una «actualización rápida» en un trimestre de planificación.

Las actualizaciones de LTS son secuenciales

No se puede pasar directamente de la versión 22.04 a la última versión LTS. La ruta de actualización de Ubuntu avanza una versión cada vez, por lo que pasar de la 22.04 a la 26.04 implica pasar primero por la 24.04. Las propias notas de la versión 26.04 de Canonical lo explican con detalle.

sudo do-release-upgrade

Cada paso constituye un ciclo independiente de pruebas y validación, y cada uno de ellos puede poner de manifiesto sus propios fallos. Si optas por la ruta de actualización in situ hasta la versión 26.04, debes prever dos operaciones de actualización en lugar de una. Para un parque de equipos más grande, el enfoque más limpio suele ser una instalación nueva de la versión LTS de destino en una infraestructura nueva y una reimplementación mediante la gestión de la configuración, lo que permite saltarse por completo la cadena de actualizaciones in situ.

Consejo profesional: Comprueba que Prompt=lts esté configurado en /etc/update-manager/release-upgrades si quieres que el sistema siga las versiones LTS, que es la configuración predeterminada en una instalación LTS. Ten en cuenta que la ruta de LTS a LTS solo se abre una vez que la versión de destino alcanza su primera versión intermedia. Ejecuta do-release-upgrade -c para comprobar si la próxima versión está realmente disponible sin iniciar la actualización.

Las aplicaciones dejan de funcionar en la nueva base

La actualización del sistema operativo en sí misma casi nunca supone ningún problema. El problema está en las aplicaciones que se ejecutan sobre él. Al pasar de la versión 22.04 a la 24.04, se producen Python, OpenSSLy docenas de bibliotecas del sistema varias versiones de una sola vez, y el código que dependía de un comportamiento anterior puede fallar de formas que no se detectan hasta el momento de la ejecución.

Los repositorios de terceros, como los PPA, suelen desactivarse durante la actualización de la versión. Las opciones de configuración obsoletas se ignoran sin aviso. Ese servicio interno heredado que nadie ha tocado en tres años es precisamente donde las cosas se tuercen. La medida correctiva es innegociable. Recompila en un entorno de pruebas que refleje el de producción, ejecuta tu conjunto completo de pruebas y soluciona los fallos allí. No a las 2 de la madrugada, durante la transición.

Coordinación de los periodos de inactividad en toda la flota

Un servidor es una ventana de mantenimiento. Trescientos servidores son un problema logístico. Las suspensiones de cambios, las aprobaciones de cumplimiento, el orden de las dependencias entre servicios y el hecho de que no todo se pueda reiniciar a la vez se combinan para alargar el plazo.

Equipos que superaron la fin de vida útil de Ubuntu 16.04 lo saben de primera mano. La solución pasa por una implementación por fases: primero los entornos que no son de producción, luego los de producción de bajo riesgo y, por último, los sistemas críticos, utilizando imágenes de referencia e infraestructura como código para que cada lote sea repetible. Si realmente no es posible cumplir el plazo antes de mayo de 2027, es ahí cuando la cobertura ampliada de parches demuestra su utilidad.

Cómo comprobar el estado de soporte técnico de Ubuntu en 2 minutos

No tienes que adivinar en qué estado se encuentra cada servidor. Hay dos comandos que te indican la versión y el estado del soporte técnico activo, y las fechas del ciclo de vida te indican cuánto tiempo queda. Ejecútalos en orden en cualquier servidor del que no estés seguro.

En primer lugar, comprueba cuál es tu versión exacta

Empieza por confirmar la fecha de lanzamiento y el nombre en clave.

lsb_release -a

Busca Versión: 22.04 y Nombre en clave: jammy. Si quieres el código fuente sin procesar, cat /etc/os-release te mostrará los mismos datos, además de la cadena completa de la versión. Cualquier cosa que indique «jammy» corresponde a la versión 22.04, y las versiones parciales, como la 22.04.5, no modifican esa fecha.

A continuación, comprueba el estado del servicio de asistencia en directo

Este es el paso que la mayoría de la gente se salta. El cliente de Ubuntu Pro muestra qué cobertura de seguridad se aplica actualmente a los paquetes del sistema.

pro estado de seguridad

El resultado te indica cuántos paquetes están cubiertos, si hay actualizaciones de seguridad estándar o ESM disponibles y qué paquetes quedan fuera de esos canales de actualizaciones de seguridad. Si aparecen paquetes que «ya no reciben actualizaciones de seguridad», significa que esos paquetes han salido de ese canal de actualizaciones, y la exposición potencial aumenta a medida que se revelan nuevas vulnerabilidades que les afectan. La resumen de TuxCare sobre el fin de vida útil de Ubuntu de TuxCare explica en detalle qué significa ese estado en la práctica.

Por último, relaciona lo que has descubierto con el ciclo de vida

Consulta la tabla de fechas anterior o endoflife.date, y luego calcula el margen de tiempo que te queda. El 22 de abril, sin la versión Pro, el mantenimiento de seguridad estándar finaliza en mayo de 2027. Con la versión Pro o el ESM activos, la cobertura se extiende hasta mayo de 2032, lo que te da un respiro, pero no elimina la migración de tu plan de trabajo.

Anota la fecha. «En algún momento de 2027» no es un plan de migración. «Realizaremos la transición en el primer trimestre de 2027, con ELS como plan de contingencia en caso de que nos retrasemos» sí lo es.

Qué hacer si tu versión de Ubuntu ha llegado al final de su ciclo de vida

Llegar al fin de la vida útil (EOL) de la versión 22.04 no es un callejón sin salida. Hay tres vías reales, y la más adecuada depende de si puedes migrar y cuándo. Elige en función de tus limitaciones reales, no de la opción que suene más clara en un documento.

Utilizar el soporte ampliado

Si realmente no es posible llevar a cabo la migración antes de mayo de 2027, ya sea por una congelación normativa, por hardware al final de su vida útil o por una pila de aplicaciones que no se pueda migrar sin problemas, el servicio «Endless Lifecycle Support» de TuxCare mantiene los sistemas actualizados sin obligar a realizar la actualización. Seguirás recibiendo parches CVE para los paquetes que realmente estés ejecutando mientras planificas la migración a un ritmo que te resulte adecuado.

La clave no es «no actualizar nunca», sino mantener abierto el plazo para la aplicación de parches, de modo que la migración se lleve a cabo correctamente y no a toda prisa. TuxCare ELS cubre Ubuntu 16.04, Ubuntu 18.04y Ubuntu 20.04 hoy, y se incluirá la versión 22.04 cuando finalice el soporte estándar.

El soporte ampliado es una red de seguridad, no un plan para seguir utilizando la versión 22.04 hasta la década de 2030. Úsalo para ganarte un margen de tiempo para realizar una migración limpia y, después, aprovecha realmente ese margen. El Informe sobre el panorama del código abierto de 2026 de TuxCare reveló que el 50,2 % de las organizaciones que gestionan componentes al final de su vida útil (EOL) en producción recurren al soporte de ciclo de vida ampliado o a los parches de los proveedores, por delante de la migración (43,9 %) y las actualizaciones (41,0 %). Eso no significa que hayan renunciado a migrar. El soporte ampliado les proporciona un margen de tiempo controlado para hacerlo correctamente.

Actualízate a una versión LTS compatible

La mejor opción a largo plazo es actualizar a una versión LTS actual. A partir de 2026, esa será Ubuntu 24.04 LTS, cuyo mantenimiento de seguridad estándar se prolongará hasta mayo de 2029, o la versión 26.04 LTS (Resolute Raccoon, lanzada el 23 de abril de 2026), que estará disponible hasta mayo de 2031.

Recuerda que, desde la versión 22.04, primero se pasa a la 24.04 y luego a la 26.04. Antes de definir el alcance del trabajo, ten en cuenta que la versión 26.04 hace que la sesión de escritorio de Ubuntu sea exclusiva de Wayland, ya que GNOME Shell ya no puede ejecutarse como sesión X.org, y actualiza el núcleo de la versión 6.8 a la 7.0. Las aplicaciones de X.org siguen ejecutándose a través de XWayland y otras sesiones de escritorio aún pueden utilizar X.org, pero cualquier elemento con dependencias del escritorio o de los controladores del núcleo merece un análisis más detallado. Esta ruta te ofrece un nuevo periodo de varios años de soporte estándar. También es la que requiere más trabajo inicial, así que haz un presupuesto para las pruebas y los escenarios de fallos mencionados anteriormente.

Habilitar Canonical Ubuntu Pro con ESM

Si deseas una cobertura ampliada directamente del proveedor, Ubuntu Pro activa el ESM para la versión 22.04 hasta mayo de 2032, con cobertura de seguridad para los paquetes de los repositorios «main» y «universe». Es gratuito para uso personal en hasta cinco equipos, y hay planes de pago disponibles para implementaciones en organizaciones.

Pro es la opción que ofrece menos complicaciones si ya utilizas exclusivamente las herramientas de Canonical. Sin embargo, en el caso de las flotas más grandes, el coste por equipo se acumula rápidamente, por lo que merece la pena comparar opciones de terceros, como TuxCare ELS, antes de tomar una decisión definitiva.

Mantén la seguridad tras el fin de vida útil de Ubuntu 22.04 con TuxCare

Mayo de 2027 está más cerca de lo que parece, y los servidores no te avisarán cuando llegue ese momento. Simplemente dejarán de recibir parches. Tanto si migras a la versión 24.04, como si vuelves a implementar la 26.04 o necesitas mantener la 22.04 más tiempo del previsto, lo que no puedes posponer es la decisión sobre la brecha de seguridad que existe entre ahora y tu fecha de transición.

Si esa transición no se puede llevar a cabo a tiempo, el servicio de soporte de ciclo de vida ilimitado de TuxCare mantiene sus sistemas 22.04 actualizados contra nuevas vulnerabilidades (CVE) sin necesidad de una migración apresurada ni de tiempos de inactividad imprevistos. El fin de la vida útil (EOL) se convierte en un hito de su plan de trabajo en lugar de una situación de emergencia.

Preguntas frecuentes