Vulnerabilidades de Node.js: principales riesgos y cómo proteger las aplicaciones en 2026

Principales conclusiones

• Las vulnerabilidades de Node.js se introducen a través de tres vectores: el entorno de ejecución, las dependencias de npm (incluidas las transitivas) y las API de HTTP, TLS o del sistema de archivos mal configuradas.
• El recorrido de rutas, la contaminación de prototipos, los ataques ReDoS y los fallos de seguridad de tipo DoS en HTTP/2 son los tipos de vulnerabilidades que causarán daños reales en los entornos de producción en 2026.
• Las últimas actualizaciones de seguridad han solucionado problemas de alta gravedad en todas las versiones activas; sin embargo, las correcciones para Node.js 20.x y versiones anteriores han llegado al final de su ciclo de vida y ya no recibirán correcciones del desarrollador original.
• Para detectar estos problemas es necesario combinar npm audit, un escáner SCA y comprobaciones de versiones en tiempo de ejecución; ninguna herramienta por sí sola lo detecta todo.

La mayoría de las brechas de seguridad en Node.js no comienzan con una vulnerabilidad de día cero. Comienzan con un archivo `package.json` que nadie ha modificado en 14 meses, ejecutándose en una versión LTS que ha dejado de recibir soporte sin que nadie se haya dado cuenta. Las vulnerabilidades de Node.js son inusualmente fáciles de pasar por alto, hasta que aparece un CVE en una dependencia transitiva que ni siquiera sabías que tenías, y de repente el escáner te avisa con insistencia y no puedes determinar de inmediato qué es lo que realmente está expuesto.

Este artículo aborda los riesgos reales en 2026: qué problemas han solucionado las últimas actualizaciones de seguridad, qué tipos de vulnerabilidades siguen apareciendo en el entorno real, cómo detectarlas en su infraestructura y las prácticas de aplicación de parches que resisten el escrutinio de una auditoría.

Por qué las aplicaciones Node.js suelen ser objeto de ataques

Node.js se encuentra en la encrucijada de tres elementos que atraen a los atacantes: un enorme ecosistema de paquetes públicos, un bucle de eventos de JavaScript de un solo subproceso que penaliza el uso excesivo de la CPU, y un entorno de ejecución que suele estar expuesto directamente a Internet a través de servidores HTTP y API. Esa combinación da lugar a una amplia superficie de ataque y a una larga lista de implementaciones sin parches.

Más concretamente:

• npm es el mayor repositorio de paquetes del mundo , y el objetivo más activo para los paquetes maliciosos. Sonatype bloqueó 136 107 ataques de malware de código abierto solo en el primer trimestre de 2026, y npm representó el 75 % de todos los nuevos paquetes maliciosos detectados ese trimestre.
• Ejecución en un solo subproceso significa que una sola expresión regular lenta o una sola solicitud que consuma muchos recursos de la CPU puede bloquear todo el proceso: no se atienden otras solicitudes hasta que haya terminado.
• Las implementaciones de producción de larga duración a menudo se ejecutan en versiones de Node.js al final de su ciclo de vida (EOL), ya que actualizar implica comprobar si hay cambios que rompan la compatibilidad en todas las dependencias, algo que los equipos posponen indefinidamente.
• Los marcos como Express, Next.js y NestJS constituyen la capa de cara al público de una gran proporción de las API web, por lo que cualquier fallo en el análisis de HTTP, los encabezados o el enrutamiento es accesible directamente desde Internet.
• Profundidad de las dependencias transitivas : una aplicación típica de Node.js utiliza cientos de paquetes, y la mayoría de los equipos solo revisan los que ellos mismos han declarado. Todo lo demás se ejecuta basándose en la confianza.

Las vulnerabilidades más comunes de Node.js

Estas son las categorías que aparecen con mayor frecuencia en los informes de CVE, los resultados de los escáneres y los análisis posteriores a los incidentes. Cada una tiene un patrón de corrección diferente, por lo que reconocerlas a primera vista ahorra tiempo cuando se publica un CVE.

Contaminación por prototipos

La vulnerabilidad de tipo «prototype pollution» permite a un atacante inyectar propiedades en Object.prototype, que luego aparece en todos los objetos del entorno de ejecución. Suele colarse a través de operaciones de fusión o clonación sin validar en entradas JSON; es el tipo de cosa que parece inofensiva hasta que te das cuenta de que la propiedad que acabas de establecer ahora puede ser leída por código que no tiene nada que ver. lodash, minimist, y varios cargadores de configuración han notificado CVE al respecto. El impacto varía desde la elusión de la autenticación hasta la ejecución de código arbitrario, dependiendo de qué código posterior utilice la propiedad contaminada.

Recorrido de rutas en las API de archivos y HTTP

El recorrido de rutas sigue apareciendo en esta lista porque Node.js sigue encontrando nuevos casos extremos. 27210 era una solución incompleta para un error específico de Windows en path.normalize() y path.join() que afecta a nombres de dispositivos como CON, PRN y AUX —el tipo de problema que solo se da en Windows y que casi nadie comprueba—. CVE-2025-55130, corregido en enero de 2026, es un problema relacionado: las cadenas de enlaces simbólicos manipuladas pueden eludir las restricciones –allow-fs-read y –allow-fs-write del modelo de permisos. Cualquier código que acepte una ruta de archivo proporcionada por el usuario se ve afectado.

Denegación de servicio mediante expresiones regulares (ReDoS)

ReDoS es prácticamente una vulnerabilidad característica de Node.js. El bucle de eventos de un solo subproceso implica que una expresión regular lenta no solo ralentiza una solicitud, sino que bloquea todo el sistema hasta que finaliza la expresión. Un atacante remoto puede enviar una cadena de entrada manipulada —a menudo de apenas unos cientos de caracteres con el patrón de retroceso adecuado— para saturar la CPU al 100 % y bloquear todas las demás solicitudes.

La vulnerabilidad CVE-2024-21538 en cross-spawn es un buen ejemplo del alcance que tiene el efecto dominó. Cross-spawn es una dependencia transitiva de Jest, ESLint, Webpack, Create-React-App y miles de herramientas más; la mayoría de los proyectos de Node.js lo tienen integrado en varias capas sin saberlo. Una sola vulnerabilidad en un paquete como ese afecta a millones de proyectos al mismo tiempo.

Ataques a la cadena de suministro a través de npm

Los paquetes maliciosos en el registro de npm —ya sean publicados directamente o introducidos a través de cuentas de mantenedores comprometidas— constituyen un problema cada vez mayor. El typosquatting (publicar «lodesh» con la esperanza de que alguien se salte la «e») lleva años existiendo, pero los ataques más sofisticados comprometen directamente paquetes legítimos y de uso generalizado. Una vez que una versión maliciosa está en el registro, cualquier proyecto que utilice un rango de versiones (^ o ~) en lugar de una versión fija la instalará en la próxima actualización.

Denegación de servicio en HTTP/2 y TLS

La implementación de HTTP/2 en Node.js ha sido una fuente recurrente de vulnerabilidades de denegación de servicio (DoS). CVE-2025-59465 es el problema más reciente relacionado con el servidor HTTP/2: un marco HEADERS de HTTP/2 mal formado provoca un bloqueo por denegación de servicio sin necesidad de autenticación. CVE-2025-59464 implica una fuga de memoria en la gestión de errores TLS durante el procesamiento de certificados de cliente que se acumula hasta que el proceso se queda sin memoria. Ninguna de ellas requiere una explotación sofisticada; solo es necesario enviar los bytes adecuados a un puerto abierto.

Vulnerabilidades de Node.js corregidas en las actualizaciones de seguridad de 2026

Node.js lanzó dos actualizaciones de seguridad importantes en 2026 —el 13 de enero y el 24 de marzo— que afectaron a todas las líneas de versiones activas. La actualización de marzo es especialmente reveladora: una de sus correcciones de alta gravedad era un parche incompleto de enero, lo que significa que la vulnerabilidad de TLS no se había solucionado por completo en la primera ocasión. Esto no es inusual en entornos de ejecución complejos, pero pone de relieve por qué es importante mantenerse al día con la última versión menor, y no solo con la última versión principal.

13 de enero de 2026. Actualización de seguridad:

Versiones parcheadas: 20.20.0, 22.22.0, 24.13.0, 25.3.0.

24 de marzo de 2026: Actualización de seguridad

Versiones actualizadas: 20.20.2, 22.22.2, 24.14.1, 25.8.2.

Nota: Node.js 20.x y versiones anteriores han llegado al final de su vida útil (EOL) —18.x desde abril de 2025, 20.x desde el 30 de abril de 2026— y no se prevén parches de los desarrolladores originales. v24.16.0 La versión LTS activa actual es la 24.x (última versión: v24.16.0).

Cómo detectar vulnerabilidades en Node.js

Ninguna herramienta por sí sola lo detecta todo. Las brechas entre herramientas son, de hecho, donde las vulnerabilidades permanecen más tiempo: algo que no aparece en npm audit porque aún no figura en la base de datos de avisos, algo que aparece en tu escáner SCA pero no en tu comprobación de versiones en tiempo de ejecución. Los pasos que se indican a continuación constituyen la base mínima.

Ejecuta «npm audit», pero no te quedes ahí

npm audit es una herramienta gratuita e integrada que analiza tus paquetes npm comparándolos con las entradas conocidas de Vulnerabilidades y Exposiciones Comunes (CVE) de la base de datos de avisos. Dicho esto, sigue siendo la primera revisión más rápida:

npm audit--audit-level=high
npm audit fix

No detectará vulnerabilidades en el propio entorno de ejecución de Node.js, en paquetes internos no publicados ni en nada que aún no se haya comunicado al canal de avisos de GitHub. Piensa en ello como un mínimo, no como un máximo.

Añadir un escáner SCA

Una herramienta de análisis de la composición del software —como Snyk, Trivy o GitHub Dependabot— cubre las lagunas que deja la auditoría de npm: dependencias transitivas, problemas de licencia, vulnerabilidades CVE en tiempo de ejecución e imágenes base de contenedores. El informe «Snyk State of Open Source Security» de 2024 reveló que el 25 % de los equipos solo realiza un seguimiento de las dependencias directas y que casi el 5 % no realiza ningún tipo de seguimiento. Así es precisamente como las vulnerabilidades transitivas permanecen sin parchear durante meses. El mismo informe reveló que las organizaciones que invierten en formación sobre seguridad de la cadena de suministro se redujeron del 53 % en 2023 a solo el 35 % en 2024, a pesar de que el número de equipos que tuvieron que parchear o sustituir paquetes vulnerables se mantuvo estable por encima del 40 %. Los equipos están haciendo menos para mantenerse a la vanguardia, mientras que el problema no disminuye.

Comprueba la versión de tu entorno de ejecución de Node.js

Ejecutar node -v de acuerdo con el calendario de lanzamientos de Node.js y los últimos boletines CVE. A fecha de mayo de 2026, la versión LTS actual es la 24.x, y la 22.x sigue en mantenimiento LTS. Por debajo de la 22.x, estás distribuyendo un entorno de ejecución vulnerable, independientemente de lo limpio que parezca tu árbol de dependencias. Esta comprobación se omite con frecuencia porque el entorno de ejecución se percibe como infraestructura —algo de lo que se encarga el equipo de la plataforma— en lugar de código de aplicación, que es responsabilidad del desarrollador. En la práctica, es ambas cosas.

Generar y supervisar una SBOM

A Lista de componentes de software te ofrece el gráfico completo de dependencias transitivas en un formato que podrás volver a consultar más adelante sin necesidad de volver a compilar desde el código fuente. Genera uno con cyclonedx-npm o syft, guárdalo y compáralo semanalmente con las listas de CVE actualizadas. Una SBOM te permite detectar vulnerabilidades que se hayan dado a conocer después del lanzamiento; sin ella, tendrías que recompilar el código desde el principio para descubrirlas.

Sigue la lista de correo sobre seguridad de Node.js

Suscríbete a la lista de correo nodejs-sec: en ella se recogen todas las publicaciones relacionadas con la seguridad del proyecto Node.js y de la organización de GitHub en general, gestionada por el equipo de Node.js. Los avisos previos al lanzamiento suelen publicarse entre 3 y 7 días antes de los parches, lo que supone un margen de tiempo suficiente para programar ventanas de mantenimiento e informar al equipo de guardia. La mayoría de los ingenieros se enteran de las vulnerabilidades CVE de Node.js a través de su escáner, que ya va con uno o dos días de retraso respecto al canal de avisos.

Buenas prácticas para mitigar las vulnerabilidades de Node.js

Automatizar la aplicación de parches

Los ciclos de parcheo manuales no son escalables. Para cuando una persona ha revisado, probado e implementado una corrección, el CVE lleva ya tanto tiempo a la vista del público que los escáneres oportunistas ya lo han detectado. El informe de Snyk de 2024 reveló que el 74 % de los equipos establecen objetivos de SLA de una semana o menos para las vulnerabilidades de alta gravedad; sin embargo, el 52 % incumple habitualmente esos plazos. La diferencia no radica en el esfuerzo, sino en el enorme volumen de elementos que hay que parchear.

La automatización es lo que realmente acorta esa brecha: actualizaciones automáticas de las dependencias en la integración continua, aplicación automática de parches en tiempo de ejecución en la capa de infraestructura y alertas automáticas que dirigen los CVE pertinentes a las personas adecuadas, en lugar de saturar a todo el mundo con alertas innecesarias del escáner.

Fija y bloquea tus dependencias

Utilice package-lock.json (o pnpm-lock.yaml o yarn.lock) y guárdalo. A continuación, ve un paso más allá: fija las dependencias directas a versiones concretas en package.json, no rangos. El ^ y ~ Los operadores son la forma en que una «corrección» en un paquete transitivo modifica silenciosamente el comportamiento en tiempo de ejecución sin que el usuario tenga que hacer nada. En la integración continua (CI), ejecuta npm ci en lugar de npm install – La compilación falla ante cualquier discrepancia entre el archivo de bloqueo y el manifiesto, por lo que se detecta el problema antes de que se lance el producto.

Mantente al día con las versiones LTS activas

El proyecto Node.js sigue un calendario LTS predecible: las versiones pares pasan a ser LTS, mientras que las impares no. Node.js 20.x llegó al final de su ciclo de vida el 30 de abril de 2026, y 24.x es la versión LTS activa. Node.js 18.x llegó al final de su ciclo de vida en abril de 2025; 16.x, en septiembre de 2023. Si utilizas cualquiera de estas versiones, estás acumulando CVE sin que haya soluciones por parte del desarrollador original.

La actualización de las versiones 16.x, 18.x o 20.x a las 22.x o 24.x suele ser factible, pero requiere comprobar todas las dependencias. El verdadero obstáculo suele ser uno o dos paquetes que no se han adaptado a las nuevas API de Node; vale la pena identificarlos y resolverlos, en lugar de seguir utilizando indefinidamente un entorno de ejecución que ha llegado al final de su vida útil.

Validar todas las entradas en el límite

La contaminación de prototipos, el recorrido de rutas, los ataques ReDoS y la inyección de comandos son, en el fondo, fallos en la validación de entradas. Un validador de esquemas como zod, joi o ajv en cada punto de control HTTP detecta la mayor parte de estos problemas antes de que lleguen a la lógica de tu aplicación. No incorpores la entrada del usuario en objetos. No pases la entrada del usuario a exec, eval, Function ni a patrones de expresiones regulares sin límites. Ninguna de estas tareas es glamurosa, pero es ahí donde reside el riesgo real.

Ejecutar con el mínimo de privilegios

Utiliza el modelo de permisos de Node.js cuando sea adecuado (teniendo en cuenta que aún se encuentra en fase experimental y presenta algunas deficiencias documentadas). Ejecuta los contenedores sin privilegios de root. Utiliza sistemas de archivos de solo lectura siempre que sea posible, elimina las capacidades que no necesites y considera el modelo de permisos como una capa más entre otras, en lugar de como un entorno aislado completo.

¿Utilizas una versión de Node.js que ha llegado al final de su ciclo de vida? TuxCare ofrece cobertura de seguridad ampliada

No todas las organizaciones pueden actualizar sus sistemas según el calendario del proveedor. Node.js 16.x llegó al final de su ciclo de vida (EOL) en septiembre de 2023. Node.js 18.x le siguió en abril de 2025. Para los equipos que siguen utilizando estas versiones —a menudo debido a una cadena de dependencias específica, un requisito de cumplimiento normativo o una migración en curso—, el problema práctico es evidente: las vulnerabilidades (CVE) siguen acumulándose sin que haya ningún parche disponible por parte del desarrollador original.

El servicio Endless Lifecycle Support (ELS) de TuxCare para Node.js aborda este problema directamente. TuxCare adapta los parches de seguridad para Node.js 12, 14, 16, 18 y 20, y los distribuye a sus sistemas durante todo el tiempo que los necesite, sin tener que esperar a una versión oficial que nunca llega. Esto resulta especialmente útil para:

• Equipos que se encuentran en pleno proceso de migración y necesitan asistencia durante el cambio a una versión LTS compatible
• Organizaciones con requisitos de cumplimiento normativo (PCI DSS, SOC 2, FedRAMP) que consideran los entornos de ejecución en fase de fin de vida útil como hallazgos de auditoría automáticos
• Equipos de infraestructura que gestionan grandes flotas en las que las actualizaciones de Node.js requieren pruebas coordinadas en decenas de servicios

Los parches de ELS cubren las vulnerabilidades de seguridad (CVE) que realmente importan —esas que aparecen en tu escáner y en los informes de cumplimiento— sin que tengas que actuar con más rapidez de la que permite tu plan de migración.

Reduce el riesgo de vulnerabilidades de Node.js con TuxCare

Las vulnerabilidades de Node.js no van a disminuir. npm es demasiado grande, el entorno de ejecución está muy extendido y la brecha entre el momento en que se da a conocer un CVE y el momento en que la mayoría de los equipos lo corrigen sigue siendo inquietantemente amplia. Los equipos que gestionan esto bien no hacen nada extraordinario: han automatizado las partes tediosas, supervisan las fuentes adecuadas, saben qué hay en su árbol de dependencias y tienen un plan para cuando una línea de versiones llega al final de su vida útil (EOL).

Tanto la detección como la mitigación son necesarias. La detección te indica qué falla; la mitigación es donde se lleva a cabo el trabajo propiamente dicho. De ambas, el factor más determinante suele ser el tiempo de aplicación de los parches: acortar el intervalo entre la divulgación y la implementación es lo que reduce la exposición real, no solo la limpieza que detecta el escáner.

Si tienes alguna pregunta sobre la estrategia de aplicación de parches o la asistencia técnica ampliada para versiones de Node.js que han llegado al final de su ciclo de vida, ponte en contacto con un experto en seguridad de TuxCare.

Resumen

Nombre del artículo

Vulnerabilidades de Node.js: principales riesgos y cómo proteger las aplicaciones en 2026

Descripción

Las principales vulnerabilidades de Node.js a las que se enfrentarán los desarrolladores en 2026 y cómo reducir el riesgo, aplicar parches más rápidamente y proteger la infraestructura de las aplicaciones.

Autor

Rohan Timalsina

Nombre del editor

TuxCare

Logotipo de la editorial