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 dependencias multiplican tu superficie de vulnerabilidad: Express.js incorpora unas 30 dependencias directas, cada una con sus propias cadenas transitivas, lo que significa que la exposición al fin de vida útil (EOL) de Express.js es mucho mayor que la del propio marco de trabajo
- Las migraciones realizadas de forma precipitada provocan interrupciones en las cadenas de middleware, problemas de enrutamiento, inestabilidad del sistema y sobrecostes que superan con creces el coste de la asistencia técnica prolongada
- Las opciones de soporte ampliado ofrecen cobertura de seguridad continuada para las versiones de Express.js que han llegado al final de su ciclo de vida, lo que te permite planificar las actualizaciones según tu propio calendario, y no según el calendario estándar.
Si estás utilizando Express.js en producción —y, estadísticamente hablando, es muy probable que así sea—, seguramente te haya pasado alguna vez. Quizá haya sido durante una auditoría de dependencias. Quizá sea un comentario escondido en el hilo de un ticket de GitHub. Quizá sea un compañero que te reenvía un artículo cuyo asunto empieza con «Atención...».
Express.js sustenta una parte enorme de la infraestructura de backend de Internet. Es el marco de trabajo que enseñó a toda una generación de desarrolladores a crear API REST, y sigue ejecutando discretamente servicios críticos en empresas de todos los tamaños. Cuando empiezan a aparecer advertencias sobre el fin de la vida útil de Express.js en tus informes de seguridad, es fácil sentir que el suelo se te mueve bajo los pies.
La cuestión es esta: no tiene por qué ser una crisis. Tienes más opciones de las que crees. Analicemos qué significa realmente que Express.js llegue al final de su ciclo de vida para tu entorno de producción y, lo que es más importante, qué medidas realistas puedes tomar al respecto sin trastocar tu plan de desarrollo.
Cómo funcionan realmente las versiones de Express.js
Antes de pasar a la parte de «vale, ¿qué hacemos realmente?», conviene entender cómo gestiona Express.js el ciclo de vida de sus versiones. Y es que, a diferencia de otros proyectos con calendarios rígidos y predecibles, Express siempre ha sido un poco… más flexible en este aspecto.
Express sigue lo que se conoce como un modelo de soporte por versiones principales. La premisa básica es sencilla: cuando se lanza una nueva versión principal, la versión principal anterior pasa a un estado de «soporte sin todas las funciones», en el que recibe actualizaciones de seguridad y correcciones de errores críticos hasta que, finalmente, queda obsoleta.
Así es como funciona en las distintas versiones de Express:
- Express v3.x llegó al final de su vida útil en julio de 2015 tras ser sustituida por la v4. No ha recibido actualizaciones desde entonces.
- Express v4.x se lanzó en abril de 2014 y, a día de hoy, sigue contando con soporte oficial, lo que la convierte en una de las versiones principales más longevas del ecosistema JavaScript.
- Express v5.x se lanzó oficialmente en octubre de 2024, dejando de dar soporte a las versiones de Node.js anteriores a la v18 e introduciendo cambios significativos en el enrutamiento, el manejo de promesas y las API obsoletas.
El problema aquí no es la política de ciclo de vida en sí misma, sino que Express ha avanzado con lentitud durante años. La versión 5 estuvo en desarrollo durante más de una década antes de su lanzamiento oficial. Ese largo periodo de gestación hizo que los equipos se basaran en gran medida en la versión 4, y ahora se enfrentan a una migración nada sencilla para mantenerse al día.
¿Y si utilizas una versión anterior? El fin del ciclo de vida de Express.js ya es un problema actual, no algo que vaya a suceder en el futuro.
Qué significa realmente el fin de la vida útil de Express.js para tu API de producción
Vale, una versión llega al final de su vida útil. Tu API sigue funcionando. Los puntos de conexión responden. Todo parece estar bien. Entonces, ¿cuál es realmente el problema?
Esta es la cruda realidad sobre el fin del ciclo de vida de Express.js: no se dejan de descubrir vulnerabilidades solo porque se interrumpa el soporte técnico. Los atacantes no consultan el calendario de fin de vida útil antes de buscar exploits. Y la comunidad investigadora sigue encontrando sin duda alguna problemas en el software fuera de servicio que se utiliza ampliamente, porque ahí es donde se encuentran los objetivos más jugosos.
Express tiene un historial de vulnerabilidades CVE bien documentado que ilustra perfectamente por qué esto es importante. A continuación se presentan algunos ejemplos recientes que han suscitado gran interés:
- CVE-2024-29041 (CVSS 6.1): Una vulnerabilidad de redireccionamiento abierto que afecta a Express 4.x anterior a la versión 4.19.0. Los atacantes podrían crear URL maliciosas que eludieran las listas de redireccionamiento permitidas correctamente implementadas utilizando la función res.location() y res.redirect() , redirigiendo a los usuarios a sitios externos arbitrarios. Esta vulnerabilidad dio lugar a boletines de seguridad de IBM para múltiples productos empresariales, incluidos IBM Watson Assistant e IBM MQ Appliance.
- CVE-2024-45296 (CVSS 7,5, Alta): Una vulnerabilidad de denegación de servicio por expresiones regulares (ReDoS) en path-to-regexp, una dependencia de enrutamiento fundamental utilizada por Express. Un atacante malintencionado puede aprovechar el backtracking en expresiones regulares de coincidencia de rutas para bloquear por completo el bucle de eventos de Node.js, lo que provoca la caída del servidor. El ataque no requiere autenticación ni interacción del usuario; basta con una sola solicitud HTTP maliciosa. Esta vulnerabilidad afectó a todas las instalaciones de Express 4.x que utilizaban versiones vulnerables de path-to-regexp y provocó la publicación de boletines de seguridad por parte de IBM para múltiples productos empresariales, incluido IBM Safer Payments.
Pero aquí está lo importante: en una versión de Express.js que ha llegado al final de su ciclo de vida, estas vulnerabilidades no se corrigen. El equipo de Express no publicará ninguna solución para los problemas de la versión 3.x. Y punto. Para los equipos que aún utilizan la versión 3 —y son más de unos pocos—, cada vulnerabilidad que se descubre supone una exposición permanente hasta que migren.
Para los equipos que utilizan la versión 4, la situación es diferente hoy en día (la versión 4 sigue recibiendo actualizaciones), pero la tendencia es clara. La versión 5 de Express ya está disponible, y la versión 4 acabará siguiendo los pasos de la versión 3 y llegando al final de su ciclo de vida. Acostumbrarse a pensar «si funciona, no lo toques» es precisamente la mentalidad que acaba provocando migraciones de emergencia más adelante.
Más allá del riesgo inmediato para la seguridad, los marcos normativos son cada vez más claros en lo que respecta al software al final de su ciclo de vida. La norma PCI DSS exige corregir las vulnerabilidades críticas en un plazo de 30 días. Los auditores de SOC 2 formulan preguntas directas sobre el software sin soporte técnico que se utiliza en producción. Utilizar versiones de Express.js al final de su ciclo de vida ya no es solo un riesgo técnico, sino también un problema de documentación.
El riesgo oculto: toda tu cadena de dependencias
Cuando la mayoría de los equipos piensan en la seguridad de Express.js, piensan en Express en sí mismo: las rutas, el middleware, el manejo de req/res. Esa es la capa más evidente.
Pero Express no funciona por sí solo. Incorpora un conjunto de dependencias directas, paquetes como body-parser, cookie-parser, serve-static, send, path-to-regexp, qs y otros que gestionan las funciones básicas en segundo plano. Cada uno de estos paquetes tiene su propio árbol de dependencias, y cada dependencia constituye en sí misma una superficie de vulnerabilidad potencial.
Una instalación típica de Express 4.x incluye unas 30 dependencias directas y, cuando se ejecuta el comando «npm list» para obtener una visión completa, el número total de paquetes aumenta considerablemente. Cada uno de esos paquetes debe actualizarse cuando se revelan vulnerabilidades y, en el caso de una versión de Express.js que ha llegado al final de su ciclo de vida, muchos de ellos no lo serán.
El historial de CVE lo deja claro: CVE-2024-43799 afectaba al paquete send (una dependencia de Express), y CVE-2024-43800 afectaba a serve-static; ambas se dieron a conocer en la misma actualización de seguridad de septiembre de 2024. No se trataba solo de una vulnerabilidad en un paquete. Se trataba de un conjunto de vulnerabilidades relacionadas que afectaban simultáneamente a todo el árbol de dependencias.
Esto es lo que hace que el fin de la vida útil de Express.js resulte realmente complicado. Aunque tengas el código de tu aplicación bien protegido, tu cadena de dependencias puede ser vulnerable a ataques que npm audit no detectará en el caso de los paquetes que han llegado al final de su vida útil, ya que no hay parches que recomendar.
Tus opciones cuando Express.js llegue al final de su ciclo de vida
Vale, tu versión de Express.js ha llegado al final de su ciclo de vida, o está a punto de hacerlo. ¿Qué opciones realistas tienes para seguir adelante?
Dos de ellas implican una complejidad, un coste y un riesgo considerables. La tercera, el soporte ampliado, es la opción que realmente resuelve el problema sin causar interrupciones, y es la que la mayoría de los equipos desearían haber descubierto antes.
Opción 1: Actualizar a Express 5
Esta es la respuesta «oficial». Actualiza a Express v5, instala los últimos parches de seguridad, aprovecha las mejoras y todos quedarán contentos.
Y para que quede claro: Express 5 es realmente mejor. Los errores de async/await ahora se reenvían automáticamente al middleware de gestión de errores, por lo que ya no es necesario envolver manualmente cada ruta asíncrona en try/catch. La biblioteca path-to-regexp se ha actualizado a la versión 8.x, lo que ha eliminado una clase de vulnerabilidades ReDoS que afectaban al enrutamiento en versiones anteriores. La compatibilidad con la compresión Brotli viene integrada. La calidad general del código ha mejorado significativamente tras una década de trabajo incremental.
Pero esto es lo que realmente significa «actualizar a Express 5» para una aplicación en producción basada en la versión 4:
- Requisito mínimo: Node.js 18: Si utilizas versiones anteriores de Node.js, primero tendrás que actualizar el entorno de ejecución, lo que conlleva sus propias implicaciones en cuanto a compatibilidad.
- Cambios en la sintaxis de las rutas: Las rutas con comodines han cambiado de app.get(‘*’) a patrones con nombres explícitos. Si tienes docenas de rutas genéricas, todas deben actualizarse.
- Se han eliminado los métodos obsoletos: app.del() ha desaparecido (utiliza app.delete()). req.param() ha desaparecido. res.send(body, status) signature ya no existe. Ninguno de estos cambios es catastrófico por sí solo, pero hay que localizarlos y solucionarlos todos.
- Cambios en el comportamiento del analizador de cuerpo: El opción ahora tiene como valor predeterminado false en el análisis de datos codificados en URL. Las aplicaciones que se basan en el análisis de objetos anidados a través de req.body pueden comportarse de forma diferente.
- Comportamiento del middleware asíncrono: Los controladores de ruta que antes devolvían valores de forma silenciosa ahora participan en la gestión de errores de Express. Esto puede modificar el comportamiento del middleware existente de forma sutil.
El equipo de Express ha publicado módulos de código que automatizan algunos de estos cambios, lo cual resulta realmente útil. Para un proyecto pequeño con una buena cobertura de pruebas, esto podría ser cuestión de un sprint. ¿Pero para una API grande con cientos de rutas, cadenas de middleware complejas y años de patrones acumulados? Se requiere una planificación minuciosa, pruebas exhaustivas y hay un riesgo real de que surjan regresiones sutiles que solo se detectan bajo la carga de producción.
Opción 2: Migración a marcos alternativos
Hay equipos que, ante la situación del fin de vida útil de Express.js, piensan: «¿Sabes qué? Quizá este sea nuestro momento».
Fastify, Koa, Hapi, NestJS para aplicaciones de mayor envergadura, o incluso optar por no utilizar ningún marco y trabajar directamente con HTTP en Node.js: existen alternativas reales, cada una con argumentos de peso a su favor. Fastify, en particular, ha despertado un gran interés por su rendimiento y su validación de esquemas integrada. Vale la pena considerar NestJS si te estás decantando por un desarrollo centrado en TypeScript con una estructura bien definida.
Pero no nos engañemos sobre lo que realmente implica la migración de un marco de trabajo. No se trata simplemente de cambiar una dependencia. Implica reescribir cada ruta y cada middleware utilizando la API del nuevo marco, refactorizar el manejo de errores —que varía significativamente entre marcos—, volver a formar a tu equipo en las diferentes convenciones y documentación, actualizar tu pila de pruebas —que probablemente tenga ayudantes específicos de Express integrados— y verificar que cada middleware de terceros del que dependes tenga equivalentes o sea compatible con tu nuevo marco.
La flexibilidad y las ventajas a largo plazo pueden justificar plenamente este trabajo en las circunstancias adecuadas. Sin embargo, los plazos y los costes suelen superar con creces las estimaciones iniciales, y mantener el sistema actual mientras se desarrolla el nuevo supone una carga administrativa adicional.
Si estás pensando en migrar a Fastify, también puedes leer nuestra guía completa sobre el fin de vida útil (EOL) de Fastify para conocer las fechas del ciclo de vida y los riesgos que conlleva.
Opción 3: Asistencia técnica ampliada de terceros
Esta es la opción que muchos equipos desconocen: el soporte de seguridad ampliado que ofrecen empresas especializadas precisamente en este tipo de problemas.
TuxCare ofrece soporte técnico de por vida para las versiones de Express.js que han llegado al final de su ciclo de vida. En lugar de obligarte a realizar una migración para la que aún no estás preparado, o de dejar tus API desprotegidas mientras la planificas, puedes seguir utilizando tu versión actual de Express.js, pero con cobertura continua de parches de seguridad.
La idea es sencilla: te ganas tiempo y control. Tiempo para planificar una migración adecuada según tus propios términos. Control sobre tu calendario de actualizaciones, en lugar de verte obligado a actuar por el plazo de una auditoría de seguridad o por la publicación de un CVE que te deja sin otra opción.
El verdadero coste de precipitarse al actualizar Express.js al final de su ciclo de vida
Hablemos de lo que ocurre realmente cuando los equipos migran precipitadamente una API de producción porque las advertencias de fin de vida útil (EOL) de Express.js finalmente alcanzan un nivel crítico en el panel de seguridad.
Cuando esa actualización se ve obligada a ajustarse a un plazo poco realista porque los organismos de control te están presionando, es inevitable que surjan problemas:
- Aumento de la carga de trabajo del servicio de asistencia: Los pequeños errores que no salieron a la luz durante las pruebas empiezan a aparecer en producción. Los cambios en el comportamiento del middleware provocan fallos intermitentes. Tu equipo de soporte se ve desbordado por las incidencias, la mitad de las cuales se remontan a la migración.
- Inestabilidad del sistema: Quizás un cambio en el comportamiento de coincidencia de rutas rompa la integración con un servicio posterior. Quizás un cambio en la configuración predeterminada del analizador de cuerpo haga que un punto final específico rechace silenciosamente cargas útiles que antes eran válidas. Estos son los problemas que generan alertas a las 3 de la madrugada y SLA muy insatisfactorios.
- Acumulación de deuda técnica: En su prisa por cumplir con los requisitos, los equipos empiezan a tomar atajos. «Ya lo refactorizaremos como es debido más adelante» se convierte en una solución provisional permanente. Seis meses después de la migración, te encuentras con un código que técnicamente está en Express 5, pero que está lleno de parches de compatibilidad y tareas de limpieza aplazadas.
- Sobrecostes presupuestarios: La estimación original era de tres semanas. Ocho semanas después, sigues apagando incendios con las regresiones. ¿Ese contratista al que contrataste para la migración? Sigue facturando horas. Las funcionalidades se han pospuesto. El coste de oportunidad es real y sustancial.
No estoy diciendo que no haya que actualizar. Actualizar es, sin duda, la solución adecuada a largo plazo. Lo que digo es que las actualizaciones precipitadas, impulsadas por la presión de cumplir con los requisitos normativos, son una forma de fracaso concreta y previsible, y que la afirmación de que «tenemos que hacerlo ahora» rara vez es cierta cuando se dispone de otras opciones.
La solución sencilla: soporte técnico de por vida para las versiones de Express.js que han dejado de recibir actualizaciones
TuxCare lleva más de una década dedicándose a esto, proporcionando parches de seguridad para sistemas operativos, entornos de ejecución, bibliotecas y, ahora, marcos de aplicaciones que han dejado de recibir soporte. Han distribuido más de 220 000 parches de seguridad en todo el ecosistema de código abierto. Cuando afirman que saben cómo mantener seguro el software que ha dejado de recibir soporte a escala empresarial, no se refieren a una capacidad teórica. Lo han demostrado con hechos.
¿Qué diferencia al enfoque de TuxCare?
Cobertura completa del árbol de dependencias: TuxCare no solo aplica parches a Express; también cubre tus dependencias directas y las dependencias transitivas subyacentes, todo ello sin coste adicional. ¿Recuerdas esa extensa cadena de body-parser, serve-static, send, path-to-regexp y todo lo demás? TuxCare lo tiene cubierto. No solo estás protegiendo el marco; estás protegiendo toda la superficie de dependencias de Express.js.
Proceso de aplicación de parches optimizado y automatizado: El proceso de TuxCare combina una automatización avanzada con la validación de expertos. Supervisan el NVD, los avisos de seguridad de los proveedores, los feeds de seguridad de GitHub y todos los lugares donde se revelan vulnerabilidades de Express.js EOL. Cuando se publica un CVE, utilizan herramientas algorítmicas y automatización asistida por IA para aplicar retroactivamente las correcciones de seguridad; a continuación, los expertos en seguridad validan cada parche antes de su lanzamiento. Cada actualización se somete a pruebas de integridad, funcionalidad y regresión antes de llegar a sus repositorios. ¿Quiere ver exactamente cómo funciona esto? Eche un vistazo al el informe técnico de TuxCare sobre su proceso de aplicación de parches de código abierto.
Integración perfecta: Los parches de TuxCare se integran directamente en tu flujo de trabajo npm actual. Si utilizas npm o Yarn, los paquetes ELS funcionan sin más. No tendrás que reestructurar tu canalización de CI/CD ni volver a formar a tu equipo. Seguirás utilizando exactamente lo que ya tienes configurado.
Respuesta rápida respaldada por un acuerdo de nivel de servicio (SLA): Cuando se revelan nuevas vulnerabilidades de Express.js EOL, TuxCare proporciona parches en un plazo garantizado respaldado por acuerdos de nivel de servicio reales. No tendrás que cruzar los dedos esperando a que alguien acabe por adaptar una solución. Recibirás actualizaciones de seguridad listas para producción con las que podrás planificar tu trabajo.
Rentabilidad: Esto es lo que más sorprende a la mayoría de los equipos sobre el soporte ampliado: suele ser bastante más barato que las alternativas. Si se suma honestamente el tiempo de ingeniería a tarifas horarias reales, los ciclos de pruebas, los honorarios de los contratistas, el posible tiempo de inactividad, el retraso en las funciones y el coste de oportunidad, el soporte ampliado suele suponer una fracción de ese total. Además, no se agota a su equipo con una migración de alta presión.
Cumplimiento normativo y transparencia: Cada versión de TuxCare ofrece una visibilidad completa de lo que se ha parcheado, qué CVE se han solucionado, qué componentes se han modificado y cómo verificar todo ello en su lista de materiales de software (SBOM). Eso es exactamente lo que necesita para las auditorías PCI DSS, las revisiones SOC 2 y cualquier otro marco de cumplimiento que plantee preguntas concretas sobre el software al final de su vida útil (EOL).
Cómo empezar
Si utilizas versiones de Express.js que han llegado al final de su ciclo de vida y quieres saber qué cobertura hay disponible, TuxCare mantiene un rastreador de CVE en tiempo real donde puedes ver exactamente qué vulnerabilidades se han corregido. Consulta las vulnerabilidades y correcciones en tiempo real para Express.
¿Quieres conocer todos los detalles sobre las versiones compatibles, los precios y la implementación? Visita el soporte de ciclo de vida ilimitado de TuxCare para Express para obtener más información.
No dejes que Express.jsponga en riesgo tus API
Express.js ha tenido una trayectoria extraordinaria. Ha democratizado el desarrollo de JavaScript en el backend, es la base de una gran parte de las API del mundo y sigue recibiendo mantenimiento activo y mejorando con la versión 5. Eso no es poca cosa.
Pero si estás utilizando versiones de Express.js que han llegado al final de su ciclo de vida (EOL) en producción, ya sea la v3, que lleva fuera de servicio desde 2015, o una instalación de la v4 que se encamina hacia su eventual obsolescencia, que «siga funcionando» no es lo mismo que «siga siendo seguro».
Esto es lo que realmente debes saber: el fin de la vida útil (EOL) de Express.js no tiene por qué suponer un problema. Tienes opciones. Puedes planificar una actualización bien meditada a Express 5 cuando realmente tenga sentido para tu equipo y tu código. Puedes evaluar marcos alternativos si existe una razón arquitectónica real para cambiar. O puedes recurrir al soporte ampliado para mantener la seguridad y el cumplimiento normativo mientras tomas esas decisiones según tu propio calendario, en lugar de según el de una auditoría de seguridad.
Los equipos que gestionan bien las situaciones de fin de vida útil (EOL) de Express.js no son necesariamente los que cuentan con los presupuestos más elevados o los códigos fuente más recientes. Son aquellos que detectan los riesgos a tiempo, comprenden qué recursos tienen realmente a su disposición y toman decisiones meditadas en lugar de reaccionar a los acontecimientos.
Si el fin de la vida útil de Express.js está en tu punto de mira en este momento, vale la pena que descubras lo que ofrece TuxCare. Quizás te des cuenta de que lo mejor no es lanzarte a una migración para la que no estás preparado, sino proteger lo que ya has creado mientras planificas la actualización que realmente quieres llevar a cabo.
Visita la página de TuxCare sobre «Soporte de ciclo de vida ilimitado para software de código abierto» para descubrir cómo el soporte ampliado puede proteger toda su pila de código abierto durante todo el tiempo que lo necesite.
