Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- Angular 17 ya ha llegado al final de su ciclo de vida (EOL) y el equipo de Angular ya no le proporciona parches de seguridad, correcciones de errores ni actualizaciones de mantenimiento.
- Los riesgos relacionados con el fin de vida útil (EOL) se acumulan con el tiempo, entre ellos las vulnerabilidades sin parchear, los problemas de cumplimiento normativo y la creciente incompatibilidad con las dependencias y herramientas modernas.
- El servicio «Endless Lifecycle Support» (ELS) de TuxCare garantiza la seguridad de tus aplicaciones de Angular 17 y su cumplimiento normativo mediante la aplicación continua de parches de seguridad.
Para los equipos de ingeniería que aún utilizan Angular 17 en producción, la red de seguridad ya ha desaparecido. Google puso fin al soporte el 15 de mayo de 2025, dejando de ofrecer parches de seguridad, correcciones de errores y mantenimiento para la línea 17.x; por lo tanto, todas las vulnerabilidades CVE reveladas desde entonces quedan sin solución oficial.
Lo importante es que no hacer nada —absolutamente nada— no es una situación estable. Cuanto más tiempo permanezca en producción una versión sin soporte y sin un plan, más difícil resultará gestionar los riesgos que conlleva.
En este artículo se explica cómo funciona el ciclo de vida de las versiones de Angular, los riesgos que conlleva permanecer en la versión 17.x más tiempo del previsto y cuáles son las opciones realistas, incluyendo cómo garantizar la seguridad mientras se define el alcance y se asignan los recursos necesarios para una migración adecuada.
¿Qué significa el fin de vida útil (EOL) de Angular 17?
El fin de vida útil (EOL) de Angular 17 supone el cese de todos los parches de seguridad, correcciones de errores y actualizaciones de mantenimiento por parte del equipo de Angular para la línea de versiones 17.x. Alcanzó oficialmente su fin de vida útil el 15 de mayo de 2025. Si tus aplicaciones siguen funcionando con esta versión, ya no recibirán cobertura de seguridad por parte del desarrollador original.
Eso no significa que las vulnerabilidades se estén explotando activamente en este momento, pero sí implica que Google no se ocupará de ninguna CVE recién descubierta que afecte a Angular 17 o a sus dependencias gestionadas. El riesgo es indefinido y aumenta con el tiempo.
La respuesta breve para los equipos que aún utilizan la versión 17.x: necesitáis un plan de migración o una forma de mantener la aplicación actualizada mientras tanto.
Ciclo de lanzamiento de Angular y fechas de fin de vida útil
Google lanza una nueva versión principal del marco Angular cada seis meses aproximadamente. Por lo general, se publican dos nuevas versiones al año: una en mayo y otra en noviembre. Cada versión principal cuenta con un total de 18 meses de soporte. Este periodo de soporte se divide en dos fases: seis meses de soporte activo, durante los cuales el marco recibe actualizaciones periódicas, correcciones de errores y nuevas funcionalidades, seguidos de doce meses de soporte a largo plazo (LTS), en los que solo se corrigen los errores críticos y las vulnerabilidades de seguridad. Una vez finalizado el LTS, ya no habrá ningún tipo de soporte oficial.
Vale la pena entender en qué momento de esa cronología se sitúa el fin de vida útil (EOL) de Angular 17. Lanzada en noviembre de 2023, dejó de recibir soporte activo en mayo de 2024 y llegó al final de su fase LTS el 15 de mayo de 2025.
La tabla siguiente muestra el estado actual de compatibilidad con las últimas versiones de Angular.
Nota: El ciclo de lanzamientos de Angular avanza rápidamente. Una versión solo recibe soporte durante 18 meses y, a partir de junio de 2026, tanto Angular 18 como Angular 19 ya habrán llegado al final de su ciclo de vida; solo seguirán recibiendo soporte las versiones v20, v21 y v22. Si aún no has actualizado tu aplicación más allá de la versión v19, esta ya se encuentra en el lado sin soporte.
Riesgos que supone para tu empresa el fin de la vida útil de Angular 17
Seguir utilizando un marco de trabajo sin soporte técnico no es un riesgo estático: se agrava con el tiempo y suele manifestarse donde menos te lo esperas. Cuanto más tiempo permanezca Angular 17 en producción sin una estrategia de parches, mayor será la brecha entre los riesgos a los que está expuesta tu aplicación y lo que realmente puedes hacer al respecto a través de los canales oficiales.
Exposición a vulnerabilidades sin parchear
Esta es la preocupación más inmediata. Angular 17 ya está «congelado» desde el punto de vista del equipo de Angular: la línea 17.x ya no recibirá más correcciones del código fuente. Mientras tanto, la pila de tecnologías de la que depende —incluidas dependencias directas como RxJS y zone.js, además de sus propios paquetes transitivos— sigue evolucionando, lo que amplía la brecha de compatibilidad y seguridad. Cualquier CVE que se publique sobre esos paquetes a partir de mayo de 2025 no tendrá ninguna corrección disponible en el código fuente para la versión 17.x.
Esto es importante porque los atacantes no pasan por alto el software al final de su ciclo de vida. Es más, las vulnerabilidades reveladas públicamente en versiones sin soporte técnico son objetivos aún más atractivos precisamente porque nunca se publicará una corrección por parte del proveedor. Los equipos que no cuentan con una solución de parches de terceros se ven obligados a elegir entre aceptar la vulnerabilidad, intentar aplicar correcciones internas o realizar una actualización apresurada en las peores condiciones posibles.
A principios de 2026 se han descubierto importantes vulnerabilidades XSS, como CVE-2026-32635, CVE-2026-27970 y CVE-2026-22610. Aunque se han publicado parches para las versiones más recientes, Angular 17 sigue sin contar oficialmente con ningún parche, lo que deja la puerta abierta a los atacantes.
También puedes consultar nuestra guía completa sobre las mejores prácticas de seguridad en Angular para aprender a mitigar las vulnerabilidades más comunes del framework.
Cumplimiento y fallos de auditoría
Para los equipos que operan bajo cualquier tipo de marco normativo —PCI DSS, SOC 2, ISO 27001, HIPAA—, el uso de software al final de su ciclo de vida (EOL) plantea un problema de cumplimiento normativo, independientemente de que se haya aprovechado o no una vulnerabilidad. A partir de 2026, los requisitos de la norma PCI DSS 4.0 serán totalmente obligatorios; el requisito 6.3.3 establece de forma estricta que todos los componentes del sistema deben estar protegidos frente a las vulnerabilidades conocidas.
La consecuencia práctica es que una auditoría de cumplimiento puede señalar Angular 17 como una infracción automática, ya que carece de parches para las vulnerabilidades CVE de 2025 y 2026. Este hallazgo requiere una respuesta de corrección de las vulnerabilidades CVE, y la afirmación de que «tenemos previsto actualizarlo en algún momento» rara vez se ajusta a los plazos del auditor.
Dependencias y deriva del ecosistema
El ecosistema de npm no espera a que los equipos se pongan al día. Los responsables de las bibliotecas siguen adelante y la compatibilidad con Angular 17 se deja de ofrecer sin previo aviso. A esto se suma el hecho de que Node.js 18 —el entorno de ejecución en el que se basan la mayoría de las aplicaciones de producción de la versión 17— alcanzó su propio fin de vida útil (EOL) en abril de 2025. A estas alturas, las herramientas de compilación, las bibliotecas de autenticación e incluso los ejecutores nativos de la nube han migrado en gran medida a las versiones 20 o 22 de Node, lo que deja a Angular 17 en una trampa de «doble fin de vida útil».
Esto genera un problema secundario que se suma al riesgo de seguridad. Aunque tu aplicación principal sea estable, el ecosistema que la rodea empieza a tirar en una dirección diferente. Lo que comienza como una solución de compatibilidad menor se convierte en una carga de mantenimiento que hace que la migración final resulte más complicada de lo necesario.
Aumento de los costes de mantenimiento interno
Sin parches de origen, el trabajo no desaparece, sino que simplemente recae sobre tu equipo. Los ingenieros de seguridad acaban supervisando manualmente los feeds de CVE, clasificando las vulnerabilidades en función del código base de Angular 17 y, en algunos casos, intentando realizar sus propias adaptaciones. Eso supone tiempo y conocimientos especializados que se restan al trabajo real en el producto.
El coste también suele ser impredecible. Una vulnerabilidad crítica de «día cero» en una dependencia muy utilizada puede obligar a una respuesta de emergencia que requiera semanas de trabajo de ingeniería, sin garantía alguna de que el resultado sea satisfactorio. Las migraciones planificadas casi siempre suponen un menor coste —en tiempo, dinero e interrupciones— que las reactivas.
¿Qué opciones tienes tras el fin de vida útil (EOL) de Angular 17?
Una vez que una versión de Angular llega al final de su ciclo de vida (EOL), los problemas empiezan cuando se sigue utilizando sin un plan definido. La mejor estrategia depende de la complejidad de tu aplicación, de la capacidad actual de tu equipo y del margen de tiempo realista con el que dispones antes de que la situación en materia de seguridad o cumplimiento normativo te obligue a tomar una decisión.
Dicho esto, estas son las tres opciones viables.
Ampliar el soporte de seguridad
Para los equipos que no pueden actualizar de inmediato, TuxCare ofrece una forma práctica y rentable de subsanar las brechas de seguridad en las versiones de Angular que han llegado al final de su ciclo de vida. La aplicación sigue funcionando tal y como está, pero se siguen proporcionando parches para las vulnerabilidades incluso después de que el proveedor haya dejado de publicarlos.
El servicio «Endless Lifecycle Support» (ELS) de TuxCare para Angular abarca desde la versión v4 hasta la v19 y ofrece parches CVE de forma continua durante todo el tiempo que tu equipo los necesite, sin plazos de migración obligatorios ni necesidad de realizar cambios en el código.
ELS no te impide actualizar más adelante: ofrece a tu equipo el margen necesario para planificar y llevar a cabo una migración de forma adecuada, al tiempo que garantiza la seguridad y el cumplimiento normativo de tus aplicaciones en todo momento. Te da el tiempo necesario para planificar y llevar a cabo una migración de forma adecuada, al tiempo que garantiza la seguridad y el cumplimiento normativo de tus aplicaciones durante todo el proceso.
Visita nuestro rastreador de CVE para ver las vulnerabilidades recientes que afectan a Angular 17 y otras versiones fuera de soporte, y si TuxCare ofrece parches para ellas.
Actualizar a una versión de Angular compatible
Es la solución adecuada a largo plazo para la mayoría de los equipos, pero merece un análisis honesto antes de incluirla en un sprint. Actualizar de Angular 17 a la versión actual (v22) no es un simple cambio de versión, sino un salto de cinco versiones principales, cada una con sus propios cambios que rompen la compatibilidad, API obsoletas y requisitos de dependencias. Los equipos que lo tratan como una simple actualización suelen descubrir el verdadero alcance a mitad del proceso, lo cual supone una situación complicada.
Un proceso de actualización realista implica auditar el árbol de dependencias actual para comprobar su compatibilidad, identificar los componentes que dependen de API obsoletas, dedicar ciclos específicos de control de calidad a las pruebas de regresión y aceptar que puede que sea necesario sustituir por completo algunas bibliotecas de terceros. Nada de esto es insuperable, pero requiere tiempo y un esfuerzo específico por parte de los ingenieros para llevarlo a cabo de forma adecuada.
Continuar sin asistencia
Algunos equipos leerán esto y, aun así, decidirán posponerlo; esa es, sencillamente, la realidad que no debemos dudar en reconocer. Pero conviene dejar claro qué implica realmente esa decisión en la práctica. Cada mes que se pasa utilizando Angular 17 sin soporte y sin una estrategia de parches supone un mes más de exposición acumulada a vulnerabilidades CVE sin una vía de corrección. El ecosistema sigue a la deriva.
Las deficiencias detectadas en materia de cumplimiento no se vuelven más fáciles de explicar con el paso del tiempo. Y si, entretanto, surge una vulnerabilidad crítica, la actualización que, según el calendario previsto, podría haber tardado tres meses en realizarse, de repente debe llevarse a cabo en cuestión de días —con todas las medidas que se omiten bajo ese tipo de presión—.
El retraso es una decisión que toman los equipos, pero rara vez resulta barata.
Actualización o soporte ampliado: ¿cuál es la mejor opción para ti?
La decisión suele depender de dos factores: la capacidad de ingeniería de la que se dispone en este momento y la presión a la que ya se está sometido en materia de cumplimiento normativo o seguridad. Ninguna de las dos opciones es mejor en todos los casos: resuelven problemas distintos en plazos distintos y, para muchos equipos, la respuesta acaba siendo ambas, aplicadas en paralelo.
En la tabla siguiente se detallan las diferencias principales:
|
Factor |
Actualizar ahora |
Asistencia durante todo el ciclo de vida |
|
Seguridad |
Correcciones en curso por parte de los proveedores |
Parches de seguridad retroaplicados |
|
Esfuerzo |
Alto (modificaciones en el código, pruebas) |
Bajo (no se requieren cambios en el código) |
|
Es hora de ponerlo en práctica |
De semanas a meses |
Más rápido que una actualización a una versión principal |
|
Apoyo al cumplimiento |
Sí |
Sí |
|
Riesgos durante la transición |
Más alto |
Inferior |
|
Perfil de costes |
Alcance elevado e impredecible |
Modelo de suscripción predecible |
Ambas opciones reducen tu exposición, pero funcionan de manera diferente. Una actualización te permite pasar a una versión upstream compatible; ELS mantiene la versión que ya utilizas actualizada y conforme a los requisitos mientras planificas ese cambio según tu propio calendario. En 2026, una actualización de la v17 a la v22 ya no es una simple «tarea de mantenimiento». Se trata de un proyecto de modernización de varios meses de duración que impulsa a tu equipo hacia los patrones y las API más recientes de Angular, incluyendo los valores predeterminados «zoneless» y «OnPush», así como el modelo de reactividad basado en Signals.
Para los equipos sometidos a una presión de auditoría activa, la columna de plazos suele ser el factor decisivo. Si se avecina una revisión de cumplimiento dentro de seis semanas, una migración que lleve tres meses no resuelve el problema inmediato; lo que sí lo resuelve es la ampliación del soporte técnico. La migración puede llevarse a cabo posteriormente, siguiendo un calendario que permita una planificación y unas pruebas adecuadas, en lugar de una transición apresurada que ponga en riesgo la estabilidad de la producción.
Protege Angular 17 tras el fin de su ciclo de vida con TuxCare
Lo frustrante de las situaciones de fin de vida útil (EOL) es que nada falla de inmediato: la aplicación sigue funcionando, y eso hace que sea fácil dejar el problema para más adelante. Pero es precisamente entonces cuando empieza a aumentar el riesgo. Las nuevas vulnerabilidades (CVE) quedan sin parchear, las auditorías de cumplimiento empiezan a señalar dependencias sin soporte y, para cuando algo te obliga a actuar, tienes que lidiar con el problema bajo presión, en lugar de hacerlo según el calendario que tú mismo habías elegido.
Seguir utilizando Angular 17 una vez finalizado su ciclo de vida no tiene por qué significar utilizarlo sin protección. El servicio Endless Lifecycle Support (ELS) de TuxCare ofrece parches continuos contra vulnerabilidades para las versiones de Angular desde la v4 hasta la v19. De este modo, mantienes la estabilidad de tu aplicación actual —sin cambios en el código ni plazos de migración obligatorios— al tiempo que sigues estando protegido al mismo nivel que con una versión en soporte técnico.
Si estás listo para dejar de asumir ese riesgo, proteger tu aplicación es cuestión de minutos, no requiere una migración. Descubre ELS para Angular de TuxCare y asegúrate hoy mismo de recibir parches de forma continua, sin necesidad de reescribir el código ni de cumplir con plazos impuestos.
