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
- Las versiones antiguas de React pueden aumentar el riesgo: utilizar React 16, 17 u 18 hace que tu organización dependa de la política pública de retrocompatibilidad de React, sin los acuerdos de nivel de servicio (SLA) contractuales ni la cobertura de dependencias que suelen exigir los marcos de cumplimiento normativo.
- Las actualizaciones precipitadas pueden resultar caras: una migración no planificada a una versión principal de React puede implicar cambios en la API que rompan la compatibilidad, bibliotecas incompatibles y una implementación coordinada entre los equipos de front-end.
- No tienes por qué elegir entre seguridad y plazos: El servicio ELS para React de TuxCare ofrece una cobertura de seguridad respaldada por un SLA para las versiones de React que cumplan los requisitos y las dependencias compatibles, mientras realizas la actualización según tu propio calendario.
Muchas organizaciones siguen utilizando versiones antiguas de React en producción, no por negligencia, sino porque actualizar una pila de front-end compleja con docenas de bibliotecas dependientes requiere una planificación minuciosa y un trabajo de ingeniería considerable. React 19 es la versión principal actual, mientras que React 18, 17 y 16 son versiones cada vez más antiguas que, a menudo, siguen integradas en aplicaciones con numerosas dependencias de bibliotecas e integraciones.
React es una de las bibliotecas de front-end más utilizadas del mundo. Se encuentra en el núcleo de tiendas de comercio electrónico, paneles de control bancarios, plataformas de control de SaaS, portales empresariales y aplicaciones sanitarias. Esa omnipresencia hace que la gestión de versiones de React sea fundamental, ya que las aplicaciones que permanecen en versiones principales antiguas pueden acumular riesgos en las bibliotecas y herramientas asociadas que el equipo de React no mantiene ni actualiza.
En esta entrada se explica cómo funciona el modelo de lanzamiento de React, qué implicaciones puede tener para la seguridad y el cumplimiento normativo el uso de una versión antigua de React, y cómo ELS for React puede ofrecer una ruta de soporte definida mientras planificas la actualización según tu propio calendario.
¿En qué consiste el ciclo de vida de las versiones de React?
React sigue el sistema de versionado semántico (SemVer), con un modelo basado en versiones principales, secundarias y de correcciones. El modelo de soporte funciona de la siguiente manera:
Última versión principal. La última versión estable de React se somete a un desarrollo continuo; las nuevas funcionalidades y las correcciones no críticas suelen incorporarse a través de versiones menores, mientras que las correcciones críticas se incluyen en versiones de parche. React 19, lanzada en diciembre de 2024, es la versión principal actual.
Versiones principales anteriores. Las versiones principales más antiguas no son el centro de atención del desarrollo continuo de funcionalidades. Sin embargo, el equipo de React afirma que, cuando tiene conocimiento de una vulnerabilidad de seguridad en React, publica una corrección retrocompatible para cada versión principal afectada por dicha vulnerabilidad. Esa política se aplica a los propios paquetes de React, no al conjunto más amplio de dependencias de terceros de una aplicación React.
Versiones principales anteriores. React 16, lanzado en septiembre de 2017; React 17, lanzado en octubre de 2020; y React 18, lanzado en marzo de 2022, son todos anteriores a React 19. A medida que se lanza cada nueva versión principal, la anterior queda cada vez más alejada del desarrollo activo de nuevas funcionalidades.
| Versión de React | Publicado | Cargo | Notas |
| React 19 | Diciembre 2024 | Especialidad actual | React 19.2 es la última versión |
| React 18 | Marzo 2022 | Carrera de grado superior | Ya no forma parte de la línea de desarrollo actual; se rige por la política de retroportabilidad de seguridad establecida por React cuando se vea afectada. |
| React 17 | Octubre 2020 | Carrera de grado superior | Ya no forma parte de la línea de desarrollo actual; se rige por la política de retroportabilidad de seguridad establecida por React cuando se vea afectada. |
| React 16 | Septiembre 2017 | Carrera de grado superior | Ya no forma parte de la línea de desarrollo actual; se rige por la política de retroportabilidad de seguridad establecida por React cuando se vea afectada. |
| React 15 y versiones anteriores | Antes de septiembre de 2017 | Lanzamientos de Legacy | La documentación está archivada; comprueba individualmente la cobertura de cualquier corrección de seguridad futura. |
La diferencia fundamental: la política de retrocompatibilidad de seguridad de React se aplica a las vulnerabilidades del propio React, no a las bibliotecas independientes, los marcos de trabajo, las herramientas de compilación y otros paquetes que se utilizan junto con él. Mantener una aplicación de React en producción implica gestionar tanto los paquetes de React como el conjunto más amplio de dependencias.
Si tu flota utiliza React 16, 17 o 18, ELS for React puede ofrecerte un compromiso de soporte formal, respaldado por un acuerdo de nivel de servicio (SLA), para los paquetes de React que cumplan los requisitos y las dependencias compatibles. Esto proporciona a tu organización plazos de respuesta definidos y una relación de soporte que va más allá de la política pública de retroportabilidad del proyecto React.
¿Qué implicaciones tiene utilizar una versión antigua de React para tu pila de front-end?
Riesgos de seguridad y cumplimiento normativo en versiones antiguas de React
El panorama en materia de cumplimiento es claro. El requisito 6.3.3 de la norma PCI DSS exige que los parches y actualizaciones de seguridad críticos se instalen en el plazo de un mes desde su lanzamiento, mientras que los demás parches aplicables deben instalarse en los plazos determinados por la evaluación de riesgos de la organización.
La HIPAA, FedRAMP, SOC 2 y otros marcos normativos o de garantía también pueden exigir a las organizaciones que identifiquen, evalúen y corrijan las vulnerabilidades de acuerdo con procesos documentados de gestión de riesgos. En el caso de los componentes de React que se ejecutan en entornos que gestionan flujos de pago, autenticación de usuarios o datos sensibles, operar sin un compromiso formal de asistencia por parte del proveedor significa que los plazos de corrección dependen de una política pública en lugar de un acuerdo de nivel de servicio (SLA) contractual, y cualquier lapso entre la detección y la corrección puede aumentar tanto el riesgo de incumplimiento normativo como el de que se produzca un incidente de seguridad.
React también se sitúa directamente en la capa orientada al usuario de las pilas tecnológicas de la mayoría de las organizaciones, lo que hace que merezca la pena analizar más detenidamente su historial de vulnerabilidades.
Vulnerabilidades CVE en los propios paquetes de React
El conjunto de paquetes propios de React —React, React DOM y el programador— presenta un historial de CVE relativamente escaso en sus versiones anteriores. La entrada más destacada es la CVE-2018-6341, una vulnerabilidad XSS que afectaba a determinadas versiones de React 16 que utilizaban ReactDOMServer para la renderización del lado del servidor. Más recientemente, React 19 ha sido objeto de una rápida sucesión de revelaciones en sus paquetes de componentes de servidor: CVE-2025-55182, una vulnerabilidad de ejecución remota de código con un CVSS de 10,0; CVE-2025-55184 y CVE-2025-67779, vulnerabilidades de denegación de servicio con un CVSS de 7,5; y CVE-2026-23864, otro problema de denegación de servicio con un CVSS de 7,5. Posteriormente se descubrió que algunas de las correcciones iniciales eran incompletas, lo que requirió actualizaciones adicionales en cuestión de semanas.
Esas vulnerabilidades de React 19 no afectan directamente a React 16, 17 ni 18. Sin embargo, ponen de manifiesto una tendencia relevante para todas las versiones principales: React es un código fuente ampliamente implantado y objeto de investigación activa, y cuando se detectan vulnerabilidades, el plazo entre su divulgación y su explotación es breve. Los investigadores de seguridad y los proveedores de servicios en la nube informaron de intentos de explotación contra CVE-2025-55182 poco después de su divulgación pública. Cumplir los plazos de corrección ante ese tipo de plazos es difícil sin un proceso establecido para evaluar, retroportar, probar e implementar las correcciones en las versiones que realmente se utilizan.
La cuestión para las organizaciones que utilizan React 16, 17 u 18 no es si esas versiones cuentan actualmente con una larga lista de CVE, sino si la política pública de retroportabilidad de React ofrece los plazos de respuesta acordados, la cobertura de dependencias, el proceso de entrega y el soporte directo que su organización necesita.
Opciones para garantizar la seguridad y el cumplimiento normativo en una versión anterior de React
Actualizar a una versión reciente de React
La migración a React 19 es la mejor opción a largo plazo para la mayoría de las organizaciones. React 19 es la versión principal actual, y la guía de actualización documenta el proceso de migración desde React 18.
La complejidad de esa migración depende totalmente de tu aplicación y de su ecosistema. Una aplicación React en producción con docenas de dependencias no se actualiza de la misma forma que un proyecto de tutorial.
Esto puede implicar auditar todas las bibliotecas de tu árbol de dependencias para comprobar su compatibilidad con React 19, resolver los cambios en la API que puedan provocar incompatibilidades, actualizar las bibliotecas de componentes de terceros que aún no sean compatibles con React 19, validar los puntos de integración con las API de backend y las capas de gestión de estado, y coordinar las implementaciones entre los equipos de frontend.
Para las organizaciones que utilizan React 16 o 17 —dos o tres versiones principales por detrás de React 19—, la diferencia puede ser mayor y la migración más compleja.
Migrar a un marco de trabajo de interfaz de usuario alternativo
Algunas organizaciones aprovechan la transición a una nueva versión principal de React como motivo para evaluar alternativas como Vue, Angular o Svelte. Se trata de una decisión arquitectónica a largo plazo realmente viable para algunos equipos, pero es un proyecto de ingeniería que se prolonga durante varios trimestres y que implica reescribir la lógica de la aplicación, reconstruir las bibliotecas de componentes, volver a formar a los equipos y sustituir toda la cadena de herramientas.
Para la mayoría de las organizaciones que se enfrentan a una deficiencia inmediata en materia de seguridad y cumplimiento normativo, la migración del marco de trabajo no es una respuesta a un plazo de aplicación de parches.
La ruta recomendada: TuxCare ELS para React
ELS para React de TuxCare aborda directamente el problema de seguridad y cumplimiento normativo, sin obligar a realizar una actualización inmediata a una versión superior.
TuxCare ofrece cobertura de seguridad continua para las versiones antiguas de React que cumplan los requisitos, así como para las dependencias directas y transitivas compatibles, con niveles de servicio definidos. Esto permite a tu equipo de ingeniería mantener una postura de seguridad sólida mientras planifica y lleva a cabo una actualización limpia según su propio calendario.
TuxCare supervisa el NVD, los avisos de seguridad de npm y los canales de seguridad de GitHub en busca de vulnerabilidades que afecten a React y sus dependencias; a continuación, realiza retroportes y proporciona correcciones para versiones anteriores mediante procesos respaldados por un acuerdo de nivel de servicio (SLA). Cuando se da a conocer una vulnerabilidad cubierta en un paquete de React elegible o en una dependencia compatible, TuxCare evalúa su aplicabilidad y proporciona una corrección probada y firmada de acuerdo con el compromiso de nivel de servicio correspondiente, en lugar de basarse únicamente en el proceso público de retroportes de seguridad del proyecto React.
Los riesgos de precipitarse al actualizar React
Cuando la presión para actualizar aumenta debido a las auditorías de cumplimiento, los resultados de los escáneres de seguridad o las herramientas de gestión de dependencias, la tentación es reaccionar de inmediato. Sin embargo, el coste de reaccionar sin una preparación adecuada suele ser mayor de lo que los equipos prevén. Las organizaciones que implementan ELS para React pueden reducir esa presión inmediata derivada de la seguridad, ya que se mantiene la cobertura definida mientras se planifica adecuadamente la migración.
En qué consiste realmente una actualización de versión principal de React
Una actualización de versión principal de React —especialmente una que abarca varias versiones principales, como de la 16 a la 19— no consiste simplemente en aumentar el número de versión en el archivo package.json.
Dependiendo de la versión inicial y de la arquitectura de la aplicación, puede implicar adaptar código que utilice API eliminadas u obsoletas, contexto heredado, métodos de renderizado desactualizados o bibliotecas que dependan de componentes internos de React. Implica verificar la compatibilidad de todas las bibliotecas de tu árbol de dependencias, ya que los paquetes del ecosistema mantienen sus propios requisitos de dependencias de React y es posible que aún no sean compatibles con la versión de destino. Implica trabajar con la cadena de herramientas para las configuraciones de webpack, los preajustes de Babel, las configuraciones de Jest y cualquier infraestructura de compilación que interactúe con transformaciones específicas de React. También puede requerir pruebas adicionales del comportamiento de renderizado, la gestión de eventos, la hidratación y las funciones concurrentes; además, algunos problemas de compatibilidad y rendimiento pueden aparecer únicamente bajo cargas de trabajo realistas de la aplicación.
En un entorno empresarial en el que varios equipos de front-end comparten componentes del sistema de diseño, es posible que las bibliotecas de terceros aún no sean compatibles con React 19 y que los ciclos de lanzamiento se rijan por los plazos del producto y de cumplimiento normativo, una actualización importante de React puede convertirse en un programa de trabajo coordinado, en lugar de una simple incidencia.
¿Qué ocurre cuando se precipita la actualización?
Cuando los equipos de front-end se ven obligados a realizar una actualización importante de React debido a un plazo de cumplimiento normativo, en lugar de a la preparación de la organización, pueden surgir varios problemas que se podrían haber evitado.
Aumentan los picos de carga a medida que surgen en producción regresiones en la visualización de componentes que no se habían detectado en el entorno de pruebas. Las bibliotecas de terceros muestran un comportamiento inesperado con la nueva versión principal, lo que provoca fallos en la interfaz de usuario en casos extremos. La deuda técnica se acumula a medida que los equipos aplican soluciones provisionales y alternativas para cumplir con los plazos, lo que genera trabajo adicional que se acumula en los ciclos posteriores. Y los costes no previstos se disparan: en horas de ingeniería, en retrasos en el lanzamiento de funcionalidades y en los gastos operativos derivados de gestionar una migración cuyo alcance no se había definido adecuadamente.
Los equipos que gestionan bien estas transiciones las abordan como migraciones planificadas, con auditorías exhaustivas de dependencias, implementaciones por fases y el mantenimiento de un nivel de seguridad estable en todo momento. ELS para React es lo que hace posible ese enfoque planificado.
La solución sencilla: TuxCare ELS para React
TuxCare lleva más de una década perfeccionando la automatización, los conocimientos especializados y los procesos necesarios para distribuir de forma fiable y a gran escala parches de seguridad para software al final de su ciclo de vida. A lo largo de las más de 220 000 actualizaciones distribuidas en toda su cartera de productos compatibles, TuxCare ha desarrollado un flujo de trabajo de aplicación de parches diseñado para una distribución rápida y segura en entornos de producción.
ELS para React añade la cobertura contractual que la política pública de retrocompatibilidad de React no ofrece:
- Parches de seguridad rápidos y respaldados por un SLA: TuxCare supervisa continuamente las divulgaciones de vulnerabilidades y proporciona parches para las CVE de gravedad alta y crítica (CVSS 7.0+) dentro de los SLA definidos, lo que ayuda a su organización a cumplir los plazos de corrección de vulnerabilidades aplicables según la norma PCI DSS y sus requisitos documentados en otros marcos de cumplimiento.
- Cobertura de dependencias más allá de los propios paquetes de React: ELS para React cubre tanto los paquetes propios de React como las dependencias directas y transitivas de tu pila de React, sin coste adicional. Las vulnerabilidades detectadas en toda esa superficie de dependencias siguen el mismo proceso de aplicación de parches respaldado por un SLA.
- Se adapta a tus flujos de trabajo actuales: Tanto si obtienes las actualizaciones de React a través de npm como de tus procesos de CI/CD actuales, puedes cambiar tu fuente de actualizaciones al repositorio seguro de TuxCare con cambios mínimos en tu flujo de trabajo, sin que ello suponga ninguna interrupción en tu cadena de herramientas actual.
- Paquetes firmados criptográficamente: Cada parche se somete a pruebas de integridad, funcionalidad y regresiones antes de llegar a tu repositorio, y los paquetes resultantes se firman criptográficamente para que tu equipo pueda verificar su origen e integridad.
- 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 de React sin el apoyo de especialistas.
Para ver qué vulnerabilidades CVE de React ya se han solucionado, TuxCare mantiene un rastreador de CVE. Para obtener más detalles sobre el proceso de aplicación de parches y los estándares de validación de TuxCare, consulta el libro blanco técnico.
No dejes que una versión obsoleta de React ponga en riesgo tu pila de front-end
Una versión anterior de React no deja de funcionar. Sin embargo, es posible que no ofrezca los niveles de servicio oficiales, la amplia cobertura de dependencias ni la relación de asistencia directa que requiere una organización empresarial.
React es un código fuente ampliamente implantado y objeto de investigación activa; y cuando se revele la próxima vulnerabilidad en una versión que utilice tu organización, es posible que la política pública de retroportabilidad de React no ofrezca los tiempos de respuesta contractuales, la cobertura de dependencias o la documentación del SLA que te exigirán tus auditores.
Los equipos que gestionan bien esta situación consideran que una versión obsoleta de React es un problema de seguridad que hay que gestionar de forma planificada, y no un plazo al que hay que reaccionar bajo presión. Puedes planificar una migración planificada a React 19 cuando se adapte a la capacidad de tus equipos de front-end y al calendario de lanzamientos de tu organización. Puedes definir adecuadamente el alcance de la migración antes de comprometerte con un plazo. O bien, puedes utilizar el servicio ELS para React de TuxCare para mantener la seguridad y el cumplimiento normativo mientras tomas esas decisiones según tus propios términos.
ELS para React garantiza la compatibilidad de tus paquetes de React, mantiene intacto tu nivel de cumplimiento normativo y permite que tus equipos de ingeniería se centren en desarrollar, en lugar de en gestionar actualizaciones de emergencia del marco de trabajo.
Si en estos momentos tienes en tu radar de seguridad una versión antigua de React, visita el servicio de soporte de ciclo de vida ilimitado para React de TuxCare para descubrir cómo el soporte ampliado puede proteger tus aplicaciones front-end durante todo el tiempo que necesites.
