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
- Express 4 se encuentra en fase de mantenimiento desde abril de 2025, y está previsto que finalice su vida útil a partir de octubre de 2026.
- Solo se corrigen los errores de la versión más reciente de una línea principal, por lo que las versiones secundarias 4.x fijadas no están incluidas.
- Express 3 dejó de recibir soporte técnico en julio de 2015 y, desde agosto de ese mismo año, no se ha corregido ningún error en él.
- Express 5 requiere Node.js 18 o una versión posterior, por lo que la actualización del marco de trabajo suele suponer una migración del entorno de ejecución.
Express se ganó su reputación haciendo muy poco. Un sistema de enrutamiento minimalista, un flujo de middleware y las convenciones justas para evitar que los equipos discutieran sobre la estructura de carpetas. Esa moderación es precisamente la razón por la que tantos servicios acabaron en Express sin que nadie tomara una decisión deliberada al respecto, y por la que nadie vuelve a revisarlo una vez que todo funciona.
Así es como una API de pagos acaba ejecutando Express 4.17.1 sin modificaciones durante siete años, hasta que un escáner de dependencias lo detecta. No ha cambiado nada en el código. Lo que ha cambiado es todo lo que lo rodea.
La contradicción radica en dos afirmaciones. La página web de Express indica que la línea 4.x sigue contando con soporte técnico. Tu escáner de dependencias, por su parte, señala que el servicio es vulnerable. Ambas afirmaciones son correctas al mismo tiempo, ya que el soporte técnico para la línea 4.x no es lo mismo que el soporte técnico para cada una de las versiones históricas de la línea 4.x.
Eso no es negligencia. Es longevidad. El informe DBIR de Verizon de 2026 reveló que la explotación de vulnerabilidades es ahora la forma más habitual en que comienzan las brechas de seguridad, representando el 31 % de los accesos iniciales, frente al 20 % del año anterior y por delante del uso indebido de credenciales por primera vez en los 19 años de historia del informe. El tiempo medio necesario para la corrección total pasó de 32 a 43 días durante el mismo periodo. Los sistemas vulnerables suelen ser aquellos que funcionan lo suficientemente bien como para que nadie sienta ninguna urgencia al respecto.
¿Se ha dejado de dar soporte a Express 4?
Respuesta breve: no. Express 4 no ha llegado al final de su ciclo de vida (EOL) a fecha de agosto de 2026, y la línea 4.x sigue lanzando nuevas versiones. La respuesta más detallada es que el tiempo ya ha empezado a correr, y que la versión principal no indica en absoluto si la versión fijada en tu archivo de bloqueo va a recibir correcciones.
Durante la mayor parte de su vida, Express no contaba con ningún calendario de LTS. Esto cambió en marzo de 2025, cuando el proyecto publicó una estrategia de LTS y, al mismo tiempo, estableció la versión 5.1.0 como la predeterminada en npm. Las versiones principales pasan ahora por las fases «ACTUAL», «ACTIVA» y «MANTENIMIENTO». Express 4 entró en la fase de «MANTENIMIENTO» el 1 de abril de 2025, lo que significa que solo se proporcionarán parches de seguridad y correcciones de errores de alta prioridad, y que el fin de vida útil (EOL) está previsto no antes del 1 de octubre de 2026. El proyecto se refiere a estos objetivos como «metas» en lugar de «compromisos» y señala que la v4 es un caso especial que podría prorrogarse, pero la dirección a seguir no ofrece lugar a dudas.
Mientras tanto, la página oficial de soporte técnico sigue indicando que las versiones 4.x y 5.x están «en curso» sin fecha de finalización, junto con la versión mínima de Node.js y la fecha de inicio del soporte técnico para cada versión principal. Los dos documentos no coinciden, lo cual supone una respuesta incómoda para un auditor que pregunte cuándo dejará de recibir soporte técnico tu marco de trabajo.
La norma que realmente importa es la que aparece en una línea en la parte superior de esa página de soporte técnico. Solo se ofrece soporte técnico para la última versión de cada línea de lanzamiento principal. A continuación, la página de actualizaciones de seguridad detalla qué vulnerabilidades se han solucionado en cada lanzamiento, versión por versión. Si se leen en conjunto, estas informaciones revelan algo que el número de versión por sí solo no indica: estar en una línea de lanzamiento principal con soporte técnico no es lo mismo que estar en una versión con soporte técnico.
| Versión Express | Estado de la asistencia técnica | Última versión | Fechas importantes |
|---|---|---|---|
| Express 3.x | Fin de la vida | 3.21.2 | El servicio de asistencia finalizó en julio de 2015 y no se ha resuelto nada desde el 1 de agosto de 2015. |
| Express 4.x | Mantenimiento desde el 1 de abril de 2025 | 4.22.2 | Lanzado el 11 de mayo de 2026; fin de vida útil previsto no antes del 1 de octubre de 2026 |
| Express 5.x | En vigor desde el 31 de marzo de 2025 | 5.2.1 | Versión 5.0.0 lanzada el 9 de septiembre de 2024; la serie 5.x pasó a ser la predeterminada en npm a partir de la versión 5.1.0 |
Esa distinción es la que determina si una incidencia de auditoría se cierra o se deja abierta. El hecho de que la versión 4.x siga activa no te dice nada sobre la 4.17.1, ya que las correcciones se aplican a la versión 4.x más reciente y no a cualquier versión menor que se fijara en 2019. Si no puedes indicar la versión exacta en tu archivo de bloqueo, aún no sabes si tu versión es compatible. Averígualo antes de discutir con el escáner.
La cápsula del tiempo del middleware
Express en sí mismo es pequeño. Lo que hace que un servicio antiguo basado en Express sea frágil es todo lo que se le ha añadido: analizadores de cuerpo, almacenes de sesiones, estrategias de autenticación, motores de plantillas y middleware personalizado escrito hace años por personas que ya no están en la empresa y que no han documentado nada de ello.
El mero hecho de actualizar Express da la falsa impresión de que el problema está resuelto. Aunque se actualice el marco de trabajo y desaparezca la alerta de nivel superior, puede que siga habiendo un paquete transitivo vulnerable un nivel más abajo, sin que se haya hecho nada al respecto.
Express 4 declara unas 30 dependencias directas, entre las que se incluyen qs, body-parser, send, serve-static, path-to-regexp, proxy-addr, y forwarded, con un árbol resuelto más amplio por debajo de ellas. Nadie eligió esas bibliotecas. Vienen incluidas con Express, y una vulnerabilidad en una de ellas se convierte en una vulnerabilidad en tu aplicación siempre que se pueda acceder a la ruta de código afectada. Cuatro CVE de 2024 muestran cómo ocurre esto.
| CVE | Tema | Se puede contactar con Express a través de | Corregido en |
|---|---|---|---|
| 29041 | Redirección abierta a través de res.location() y res.redirect() |
Núcleo Express | 4.19.2 |
| 43796 | XSS a través de res.redirect() |
Núcleo Express | 4.20.0 |
| 45296 | ReDoS en «path-to-regexp» | dependencia de «path-to-regexp» | 4.20.0 |
| 52798 | Segundo ReDoS en «path-to-regexp» | dependencia de «path-to-regexp» | 4.21.2 |
Lo complicado es que la versión 4.19.2 es la que corrigió el redireccionamiento abierto, y aún así es anterior a todas las versiones posteriores. Una aplicación que siga en la versión 4.19.2 ha solucionado el CVE-2024-29041, pero sigue siendo vulnerable al XSS y a los dos problemas de ReDoS relacionados con «path-to-regexp», ya que esas correcciones se implementaron más adelante en la línea 4.x. Cabe destacar también que la redirección abierta requirió tres intentos: una corrección inicial en la versión 4.19.0, una regresión corregida en la 4.19.1 y la solución definitiva del bypass en la 4.19.2, por lo que cualquier versión anterior a la 4.19.2 no está totalmente protegida frente a ese problema.
Advertencia: Antes de realizar la clasificación de pacientes, ejecuta npm ls path-to-regexp qs send compáralo con el árbol de dependencias que incluye realmente tu aplicación y compara las versiones resueltas con tu archivo de bloqueo. Una copia fijada de forma transitiva que se haya incorporado a través de alguna otra dependencia puede dejarte expuesto, incluso cuando el propio Express esté actualizado.
Hay que tener en cuenta una salvedad. «Afectado» no significa «vulnerable». Que un hallazgo se considere un incidente o una partida concreta depende de si tu aplicación expone realmente la ruta de código vulnerable a entradas controladas por un atacante.
Esa brecha es precisamente la que pretenden subsanar los parches de los proveedores para el software libre. La cobertura de TuxCare para Express abarca los componentes compatibles que se incluyen junto con una versión cubierta, en lugar de los de nivel superior express el paquete en sí mismo, que es la diferencia entre subsanar un hallazgo y aplazarlo. Según un estudio de Endor Labs se estima que aproximadamente el 95 % de las vulnerabilidades del código abierto se encuentran en dependencias transitivas, en lugar de en aquellas que los desarrolladores eligen directamente, y una implementación heredada rara vez tiene la opción de pasar simplemente a la rama en la que se haya implementado la corrección. TuxCare’s Registro de vulnerabilidades CVE muestra el estado de los parches por versión, para que puedas ver en qué lado de esa línea te encuentras.
Express 5 incluye Node.js
Lo que se suele pasar por alto cuando se incluye la «actualización a Express 5» en un presupuesto es que Express 5 requiere Node.js 18 o una versión posterior. Una actualización del marco de trabajo se convierte en una migración del entorno de ejecución a la que se suma la actualización del marco de trabajo.
Express 5 también ha modificado comportamientos en los que las aplicaciones más antiguas se basaban de forma implícita. Las promesas rechazadas y los errores generados por los controladores asíncronos ahora se reenvían automáticamente al middleware de gestión de errores. Se ha eliminado un conjunto de firmas obsoletas, entre las que se incluyen res.send(body, status) y la cadena mágica «back» en res.redirect. La coincidencia de rutas se ha trasladado a «path-to-regexp 8», que ha eliminado las expresiones regulares de subexpresiones en las cadenas de ruta como medida de mitigación contra los ataques ReDoS, por lo que es necesario reescribir las rutas que se basan en esos patrones.
Imagina un servicio interno de reclamaciones que sigue basándose en una imagen de contenedor de la época de Node 14. Pasar de Express 4 a 5 es lo fácil. Lo difícil es migrar esa imagen a una versión de Node.js que cuente actualmente con soporte, que cumpla de todos modos con los requisitos mínimos de Express 5, sin que se produzcan errores en los módulos nativos compilados con la ABI anterior.
La propia guía de migración de Express deja claro que es posible que una aplicación de la versión 4 no funcione tal cual en la versión 5, y esa perspectiva resulta útil. De este modo, se trata de un problema de tiempo de ejecución y de pruebas antes que de un problema del marco de trabajo.
Consejos de expertos: Antes de actualizar Express, ejecuta tu conjunto de pruebas actual con la versión de Node.js que realmente tengas previsto implementar. Algo tan sencillo como nvm use <target> && npm test detectará errores en los módulos nativos y en la ABI que no tengan nada que ver con Express.
Tres opciones viables y cuánto cuesta cada una
No hay una respuesta universal para esto, solo aquella que se adapte a tu gráfico de dependencias, a tu cobertura de pruebas y a tu tiempo de ejecución. Hay tres opciones que cubren la mayoría de las situaciones.
Pasar a Express 5
Esta es la opción cuando el árbol de dependencias está limpio y las pruebas de integración son fiables. Actualiza el entorno de ejecución, actualiza Express, repasa el manejo de errores asíncronos y los patrones de rutas, y observa cómo la integración continua pasa a verde. El cambio de marco de trabajo puede ser fácilmente la parte más sencilla del trabajo.
Quédate con la versión 4.x y mantente al tanto de la última versión
Es una opción viable para aplicaciones que se ciñen al enrutamiento convencional y al middleware más habitual, aunque el margen de maniobra se está reduciendo. Sigue la última versión 4.x, actualmente la 4.22.2, y considérala una práctica habitual en lugar de algo puntual. Tampoco es gratuita. El 1 de diciembre de 2025, Express lanzó un cambio en el analizador de consultas en ambas líneas activas para lo que se había registrado como CVE-2024-51999. El CVE fue rechazado posteriormente por no tratarse de una vulnerabilidad, y las versiones 4.22.1 y 5.2.1 revirtieron el cambio esa misma noche, aproximadamente cuatro horas después de que se publicaran las versiones originales. Ni siquiera eso lo cerró, ya que la versión 4.22.2, en mayo de 2026, tuvo que restablecer el comportamiento de análisis de matrices para claves de consulta repetidas. Mantenerse al día implica asimilar todo eso. Mantenerse en una versión principal con soporte solo ayuda mientras se sigue avanzando con la línea de versiones, y en el momento en que se queda estancado en una versión 4.x más antigua, vuelve a encontrarse en la misma situación que cualquiera que se haya quedado en la 4.17.1.
Asistencia ampliada mientras se programa la migración
Esto deja los casos que los dos primeros no cubren: un entorno de ejecución de Node.js bloqueado, un middleware de autenticación personalizado o una migración que realmente se prolongue durante varios trimestres. Una API regulada con una capa de autenticación a medida y un entorno de ejecución fijado puede requerir fácilmente más de uno o dos sprints, y precipitarse porque un escáner se ha puesto en rojo es la forma en que se producen las interrupciones del servicio. TuxCare ELS cubre versiones específicas de Express, entre las que se incluyen la 3.4.8, la 3.21.2, la 4.17.1, la 4.18.1, la 4.18.2, la 4.18.3 y la 4.19.2, distribuidas como de ámbito limitado @els-js paquetes a través de un registro de TuxCare autenticado.
| Ruta | El más adecuado | Esfuerzo habitual |
|---|---|---|
| Pasar a Express 5 | Dependencias limpias, pruebas en las que confías | Sobre todo, el salto a Node.js y las pruebas que hay detrás |
| Sigue las últimas novedades de la versión 4.x | Enrutamiento y middleware estándar | La situación sigue igual, y el margen de maniobra se está reduciendo |
| Soporte ampliado (ELS) | Tiempo de ejecución congelado, middleware a medida | Un puente mientras la migración se prolonga |
La versión resumida. Un diagrama claro y unas pruebas en las que confías apuntan a Express 5. El enrutamiento convencional y el middleware estándar apuntan a seguir con la última versión 4.x y quedarse ahí. Un entorno de ejecución «congelado» o una migración que abarque varios trimestres apuntan a un soporte prolongado que está planificado, en lugar de indefinido, lo cual cobra mayor importancia ahora que la versión 4.x tiene fijada una fecha prevista de fin de vida útil (EOL).
Cómo TuxCare ofrece soporte para Express fuera de periodo de soporte
El soporte ampliado de una biblioteca no es un trabajo glamuroso, y precisamente ahí radica la clave. Comienza con la supervisión de vulnerabilidades en toda la versión de Express cubierta y en los componentes compatibles que se incluyen con ella. La primera pregunta que surge ante cualquier nueva revelación es si afecta realmente a esa versión o si solo afecta a rutas de código introducidas posteriormente.
Cuando se necesita un parche, el enfoque es una adaptación retrospectiva rigurosa. Se toma el cambio relevante para la seguridad de la corrección del desarrollador original, se descarta la refactorización no relacionada que venía con él y se evita introducir una actualización del marco de trabajo que nadie había previsto. El resultado se somete a pruebas de regresión comparadas con el comportamiento anterior antes de publicarse como paquete mantenido, junto con los datos SBOM y VEX. Esa evidencia legible por máquina es lo que permite al equipo de seguridad documentar adecuadamente un hallazgo en lugar de posponerlo hasta el siguiente trimestre. Se trata de una especialización, más que de un sustituto del código original, lo que implica el mantenimiento a largo plazo de ramas que el proyecto ya ha dejado atrás, con pruebas de compatibilidad antes de que se publique nada.
Los equipos de cumplimiento normativo siempre preguntan por los plazos, así que aquí están los objetivos publicados. Las vulnerabilidades altas y críticas, es decir, aquellas con una puntuación CVSS 7.0 o superior, tienen un tiempo de respuesta objetivo de 14 días desde su divulgación pública; las vulnerabilidades medias, de 60 días; y las bajas, de 90. Las versiones cubiertas y los pasos de instalación se encuentran en la documentación de TuxCare ELS para Express, mientras que la visión general se puede consultar en la sección de soporte para el fin de vida útil (EOL) de la biblioteca.
El papel de la sostenibilidad en OpenJS
Express es un proyecto de impacto de la Fundación OpenJS, y eso es importante porque la Fundación ofrece un marco oficial para el soporte comercial de versiones archivadas, fuera de ciclo de vida y antiguas de los proyectos. El Programa de Sostenibilidad del Ecosistema OpenJS se puso en marcha en mayo de 2024 con el fin de poner en contacto a los proveedores comerciales con esas versiones, de modo que los socios reviertan una parte de los ingresos empresariales a los proyectos participantes.
TuxCare figura como socio del programa ESP junto a HeroDevs y NodeSource, y el programa exige que los socios sean miembros Gold o Platinum de la Fundación. La página de fin de vida útil de Node.js menciona a estos mismos tres proveedores, lo que es un claro indicio de que se trata de un modelo consolidado y no de una improvisación.
Conviene dejar claras dos limitaciones. El programa no es exclusivo y está abierto a cualquier proveedor que cumpla los requisitos; además, no impide que los responsables del mantenimiento publiquen correcciones públicas para cualquier versión, incluidas aquellas que cubra un socio del programa ESP. También conviene saber que la propia página de asistencia del proyecto Express indica actualmente a HeroDevs como su opción comercial, por lo que la cobertura de tu versión concreta es algo que debes confirmar directamente con el proveedor que estés evaluando.
Análisis de la realidad: una actualización retroactiva del proveedor puede solucionar las vulnerabilidades cubiertas en la versión 4.17.1, pero eso no convierte a la versión 4.17.1 en una versión compatible con el proyecto original. Si un requisito de cumplimiento especifica expresamente la compatibilidad con el proyecto original, el parche del proveedor responde a una cuestión diferente, y conviene saber cuál es la pregunta que se te está planteando.
Cómo evaluar una aplicación antigua de Express
Antes de elegir una opción, averigua cuál es tu situación real. Empieza por la versión exacta de Express que figura en tu archivo de configuración, en lugar del rango indicado en package.json. Recorre las dependencias directas y transitivas con npm ls y compáralas con los avisos de seguridad conocidos. Haz un inventario del middleware personalizado y de cualquier comportamiento no documentado del que dependa la aplicación. Determina qué versión de Node.js utiliza la aplicación y si ese entorno de ejecución sigue siendo compatible, ya que eso determina si Express 5 es siquiera una opción viable. A continuación, pondera todo ello en función de la exposición y la importancia para el negocio, de modo que la API de pagos reciba prioridad frente a un panel de control interno con poco tráfico.
Hay un aspecto que se suele pasar por alto fácilmente. Express también puede llegar de forma transitiva a través de SDK, paquetes de middleware y otras dependencias, por lo que en el gráfico siguen apareciendo versiones que nadie ha elegido instalar. Una evaluación que omita el estado del ciclo de vida y las dependencias indirectas da como resultado una lista en lugar de una visión general.
Actualiza siguiendo un calendario arquitectónico, no porque un hallazgo haya obligado a modificar los plazos. El soporte de ciclo de vida ilimitado existe precisamente para darte ese margen, manteniendo la versión en funcionamiento actualizada con los parches necesarios mientras la migración se lleva a cabo según un calendario que puedas probar y controlar.
