El Estado de la Seguridad de Node.js

Hola, amigos. Estoy aquí para hablar sobre el estado de la seguridad de Node.js. Es una revisión de dos años desde 2024 hasta 2026. Tenemos conversaciones y características en curso sobre Node.js, y estoy feliz de compartir todo eso con ustedes.

Así que antes de comenzar, me gustaría darles una visión general de qué es exactamente una vulnerabilidad de Node.js. No todos los blogs califican como una vulnerabilidad de seguridad. Usualmente, pueden pensar que si su aplicación falla o si pierde memoria de alguna manera, si su servidor HTTP se cae debido a un paquete malicioso o algo así, pueden pensar que esto es una vulnerabilidad de Node.js. Pero eso no es cierto. Node.js creó el equipo de seguridad de Node.js, pero hemos creado el modelo de amenazas de Node.js, que define exactamente los límites para la seguridad. Así que definimos claramente qué puede considerarse una vulnerabilidad cuando trabajas con Node.js, contra qué necesitas prevenirte y cuál es la responsabilidad de Node.js. Así que voy a compartir eso con más detalles. Y todos los informes de seguridad de Node.js van a HackerOne. Así que si estás haciendo fuzzing al código fuente de Node.js y crees que encontraste una vulnerabilidad, siéntete libre de enviarnos un informe a través de HackerOne. Revisaré todo eso.

Muy bien, este es un ejemplo de no vulnerabilidad en Node.js. Imagina que instalas un paquete, y este paquete cambia el prototipo de array push. Así que cada vez que llamas a array, cualquier array, .push, mostrará interceptado y el array no incluirá un nuevo elemento. Así que puedes pensar, OK, mi código ahora es vulnerable. De hecho, eres vulnerable, pero eso no es una vulnerabilidad de Node.js. Es algo contra lo que deberías crear medidas, que es asegurarte de instalar los paquetes correctos. Siempre revisa los paquetes que instalas cuando ejecutas Node.js. Así que para esta situación específica, tenemos una bandera llamada --"FrozenIntrinsics." Así que cada vez que ejecutas tu aplicación con eso, las personas o cualquier usuario no deberían poder modificar prototipos de datos nativos o primitivos de Node.js. Intenta usar eso, pero eso no es una medida de seguridad. Es solo un cinturón de seguridad, y vamos a hablar de eso más adelante. Tenemos muchos más ejemplos de no vulnerabilidades. Todo está descrito en el modelo de amenazas de Node.js. Por ejemplo, la contaminación de prototipos, esto no es una vulnerabilidad de Node.js. Cuando instalas un módulo de terceros malicioso, esto no es una vulnerabilidad de Node.js. Todo eso es algo contra lo que deberías crear medidas en tu aplicación de producción. Así que, por ejemplo, imagina que tienes un servidor HTTP que recibe una entrada de una fuente no confiable.

Entonces, lo que sucede es que no validas esa entrada y la pasas a una API de Node.js. Por ejemplo, path.join, y luego sirves ese archivo. Si la entrada remota envía un recorrido de ruta, podría acceder a diferentes archivos de tu sistema de archivos. Esto no es una vulnerabilidad de Node.js. Necesitas cambiar la entrada y sanitizarla antes de pasarla a las APIs de Node.js. Así que tenemos muchos otros ejemplos en tu documentación. Tenemos las mejores prácticas de seguridad de Node.js. Es un documento que escribimos. Está disponible en el sitio web de Node.js.org, y puedes revisarlo fácilmente.

Y tenemos algunos ejemplos de vulnerabilidades reales, que son los CVEs contra los que normalmente emitimos. Así que, por ejemplo, si tienes un servidor HTTP, y basado en la solicitud de cualquiera, podría cerrar o colapsar tu servidor HTTP. Esto es una vulnerabilidad. Esto es algo contra lo que Node.js debería protegerse. Así que si experimentas eso de alguna manera, necesitas reportarlo a Node.js, y lo estaremos solucionando lo antes posible. Lo mismo ocurre con el contrabando de solicitudes HTTP, ataques de temporización, violaciones de acceso a la memoria, o cualquier tipo de exposición de información. Tuvimos un informe no hace mucho sobre el reencadenamiento de DNS, donde cada vez que ejecutas Node.js con el protocolo Inspector, eso podría filtrar el Inspector a través de internet a la red, y eso ya fue solucionado. Así que asegúrate de actualizar tu versión de Node.js.

Y hay una fuente aquí, que es el documento de mejores prácticas de seguridad que te sugiero encarecidamente que revises. Estamos hablando de Node.js. Node.js es ampliamente utilizado. Si usas Discord, usas Node.js. Si usas Slack, usas Node.js. Básicamente, todos están usando Node.js en algún momento, ya sea en sus aplicaciones de producción o usándolo en otros proveedores como Discord, Slack, otras plataformas. La seguridad es imprescindible. Tenemos miles de millones de descargas anuales. Tenemos millones de implementaciones en producción, y una sola vulnerabilidad en Node.js Core puede afectar a millones de implementaciones en producción en pocas horas. Por eso todo el trabajo en la seguridad de Node.js es esencial.

Por eso, también, te sugiero encarecidamente que, si puedes, nos ayudes a mantener Node.js. Una característica que creamos desde Node.js 20, así que si usas Node.js 20 o más, y deberías estar usándolo porque Node.js 18 está al final de su vida útil en el momento en que estoy grabando esta presentación. Desde Node.js 20, hemos introducido el dash dash experimental permission, y lo hemos estabilizado en Node.js 23, así que puedes usar solo el flag dash dash permission. Y el modelo de permisos básicamente restringe el acceso de tu aplicación, al sistema de archivos, al proceso hijo, a los hilos de trabajo, complementos nativos, web, Wazzy, red. Esto es experimental en este momento. E imagina que estás tratando de resolver un problema. Usualmente, vas a tu LLM2, y te sugiere instalar un paquete. Y este paquete podría haber sido secuestrado de alguna manera, y tú instalas ese paquete. Y aunque el paquete resuelve el problema, hace cosas detrás de escena de las que no estás al tanto, como leer algunos archivos sensibles, o leer esos archivos y enviarlos a Internet, lo cual es algo que no deseas. Y esta característica del modelo de permisos es un cinturón de seguridad que te ayudará contra eso.

Así que cada vez que ejecutes Node.js con el flag de permisos, debes proporcionar las carpetas o los archivos a los que permites acceso de lectura o escritura, o lo mismo se aplica a la red. Si no proporcionas eso, Node.js bloqueará. Y este es un cinturón de seguridad que te sugiero encarecidamente que uses. Y estoy hablando mucho sobre la filosofía del cinturón de seguridad, pero voy a explicar por qué, incluso con esas medidas de seguridad, no deberías ejecutar código malicioso en Node.js. El modelo de amenazas define eso con confianza en el código ejecutado. Así que si obtienes el código de Internet, si recibes un código de entrada y lo ejecutas, si evalúas eso, esto va en contra del modelo de amenazas de Node.js. Incluso con la filosofía del modelo de permisos, hay formas de eludir eso usando enlaces simbólicos con condiciones de carrera, y ninguna característica única de Node.js te permitirá ejecutar código no confiable de manera segura. Esto es por diseño de JavaScript, diría yo. Pero esto es un cinturón de seguridad.

Cuantas más capas, como capas de seguridad, podrías añadirlo a tu proyecto, el barril, ¿verdad? Así que esa es la idea del modelo de permisos. Te sugiero encarecidamente que lo revises, y tenemos otras medidas de las que voy a hablar a lo largo de esta llamada, ¿de acuerdo?

La siguiente es npx isMyNodeGenerable. Lo he compartido muchas veces. Este es un código QR al repositorio. Y básicamente, tenemos datos que nos dicen que muchos usuarios están usando versiones de Node.js que están al final de su vida útil. Así que, por ejemplo, cada vez que lanzamos una nueva versión, también soy un lanzador de Node.js, y usualmente lanzamos varias medidas de Node.js dos veces al año. Y cada vez que lanzo eso, vamos a la X LinkedIn, y vimos los comentarios. La gente dice, oh Dios mío, estás en Node.js 25. Todavía estoy en Node.js 12 o Node.js 16.

Todas esas versiones están al final de su vida útil, y esto es muy problemático, porque cualquier parche de seguridad que emitamos, que arreglemos, no va a esas líneas, lo que significa que estás inseguro. Si lanzamos un parche de seguridad que es una vulnerabilidad de día cero, te verás afectado porque no parchearemos esa versión. Debes actualizar, especialmente si estás usando servidores de producción. Y si no sabes exactamente si estás usando la versión correcta de Node.js, asegúrate de ejecutar npx isMyNodeVulnerable en una terminal. Esto debería mostrar un peligro si estás inseguro, o un buen mensaje si estás usando una versión segura de Node.js, ¿de acuerdo?

Esto está detrás de la organización Node.js. También lo hemos diseñado para pipelines de CI, estaciones de trabajo de desarrolladores, y puedes usarlo para diferentes auditorías. Por ejemplo, antes de enviar tu código a producción, puedes ejecutarlo, y si muestra un mensaje de error, evitas ese despliegue. Así que es muy importante recibir notificaciones sobre las versiones de seguridad de Node.js, ¿de acuerdo? Como dije, esta herramienta es especialmente crítica para más de 120 millones de descargas que Node.js tiene para versiones al final de su vida útil, Node.js 18 y anteriores. Eso es todo, ¿de acuerdo?

Sigamos adelante. Vamos a hablar sobre la Iniciativa Alpha Omega. He sido patrocinado por la Iniciativa Alpha Omega de OpenSSF durante los últimos cuatro años. Esta financiación me permitió trabajar a tiempo completo en la seguridad de Node.js. He estado trabajando y manejando la seguridad de Node.js durante los últimos cuatro a cinco años, y hemos tomado diferentes medidas que ayudan a los desarrolladores de Node.js a tener un entorno más seguro y algo muy importante a mencionar aquí es que al revisar los informes de HackerOne, hemos descubierto que la mayoría de las vulnerabilidades no afectan a los servidores de producción. Afectan a los desarrolladores. Así que tú que estás tratando de resolver un problema instalando un paquete ejecutando código muy extraño en tu máquina de desarrollador, estás inseguro, ¿de acuerdo? Puedes filtrar diferente información de tu empresa al ejecutar o instalar un paquete malicioso.

Esos paquetes maliciosos podrían tener un script post-instalación que inyecta cosas en tu máquina. Tengo una masterclass llamada 5 Ways You Could Have Hacked Node.js. La presenté hace tres años, y todavía se aplica a Node.js 2026, así que te sugiero encarecidamente que le eches un vistazo. Expuse 5 vulnerabilidades que Node.js solucionó que podrían afectar a personas que están usando versiones al final de su vida útil de Node.js, y a través de este patrocinio, pude trabajar en la seguridad de Node.js, solucionar esos parches, mejorar los procesos de seguridad de Node.js, e incluir algunas características en la seguridad. Así que continuando, una de las evaluaciones o una de las iniciativas que tuvimos en el grupo de trabajo de seguridad de Node.js, y voy a hablar más sobre eso más adelante, es la evaluación de vulnerabilidades de dependencias. Node.js, en el momento en que estoy grabando esta presentación, tenemos 26 dependencias nativas. OpenSSL, energy, HTTP2, LL, HTTP, Libby v8, tenemos cualquier crypto, tenemos muchos más, y todos esos están integrados dentro del binario de Node.js, lo que significa que si alguna de esas dependencias contiene una vulnerabilidad en una de las APIs que Node.js usa, por ejemplo, OpenSSL. Usamos varias APIs de OpenSSL, y exponemos eso a los usuarios.

Usamos varias APIs de OpenSSL, y exponemos eso a los usuarios. Si alguna de esas versiones, alguna de esas APIs contiene una vulnerabilidad, Node.js se verá afectado por eso, podría verse afectado por eso, y por esa razón, tenemos una automatización. Tenemos un repositorio llamado el Node.js Dependency Vulnerability Assessment. Sé que es un nombre largo, pero es lo que es. Puedes ir a ese repositorio, ves los issues, y cada vez que se encuentra un CV público en cualquiera de las cuatro dependencias, por ejemplo, OpenSSL, se crea un issue.

El equipo de seguridad de Node.js evaluará si eso afecta a Node.js o no. Si eso afecta, lo solucionamos en una versión de seguridad, o definimos, está bien, esto es de baja severidad, es poco probable que afecte a nuestros usuarios, y vamos a solucionarlo de todos modos, pero siguiendo el proceso de lanzamiento regular. Así que imagina que usas un escáner de seguridad. Mucha gente hace eso en producción. El escáner de seguridad señala que Node.js 24.8.0 es vulnerable a, porque contiene una dependencia min match, y no sabes exactamente qué hacer porque Node.js no parcheó eso.

Entonces puedes ir a ese repositorio, posiblemente habrá un issue sobre eso, y diremos, está bien, esto está señalando en tu escáner de seguridad, pero esto no te afecta. Es solo un falso positivo, y vamos a solucionarlo siguiendo el calendario de lanzamientos regular, pero esto no te afectará. No necesitas preocuparte por eso, ¿de acuerdo? Y cualquier pregunta puede hacerse allí también. Y también es importante mencionar que la mayoría, si no todas, de esas dependencias, tenemos actualizaciones automáticas.

Entonces, cada vez que hay una nueva versión de OpenSSL, tenemos un bot que abrirá una solicitud. Es una especie de dependabot, pero tenemos archivos de configuración más específicos para cada dependencia que necesita crear o son dependientes de esas versiones. Así que también es muy, muy interesante. Si quieres saber más sobre eso, no dudes en contactarme, ¿de acuerdo?

Así que continuando, tenemos algunas discusiones en curso del grupo de trabajo de seguridad. Estamos automatizando el proceso de lanzamiento de seguridad. Node.js contiene un calendario de lanzamientos de seguridad muy extenso, y vamos a hablar más sobre eso. Y generalmente toma al menos dos semanas de trabajo para emitir un lanzamiento de seguridad de Node.js.

Es muy difícil, para ser honesto. Y estamos automatizando la mayor parte del proceso. Ahora tenemos una CLI que crea el issue de lanzamiento de seguridad. Recupera todos los informes. Tenemos una solicitud lista de HackerOne. Tenemos una automatización que crea la publicación de blog para el lanzamiento de seguridad para enviar mensajes a, porque Node.js no es simple. Como, construyo eso localmente y lo envío a GitHub. Node.js soporta diferentes entornos.

Tenemos soporte para Windows, Windows 64-bits. Tenemos Windows Server. Tenemos MacOS. Tenemos Ubuntu. Tenemos diferentes entornos.

Tenemos ARM64. Tenemos diferentes arquitecturas. Y necesitamos tener binarios para todos esos entornos. Y necesitamos construir, necesitamos probar el binario de Node.js contra todos esos entornos.

Actualmente tenemos más de 55 suites de pruebas, lo que significa que tenemos casi 5,000 pruebas unitarias, y ejecutamos cada lote de pruebas en cada uno de los entornos. Así que es mucho. Es mucho.

Así que es mucho. Es mucho. Y para una sola pull request, generalmente se necesita, no sé, seis horas para ejecutar solo las pruebas. Y luego verificamos si nuestro binario está listo para salir porque verificamos, está bien, ¿esto romperá un paquete popular como Express? Probamos el nuevo binario, ejecutamos la prueba de Express con el nuevo binario y verificamos si eso falla. Y hacemos eso para más de 100 paquetes. Así que es mucho. Toma mucho tiempo. Y estamos tratando de automatizar la mayor parte del proceso. Y aunque no hará el proceso más rápido, reducirá el mantenimiento porque generalmente necesitamos al menos cinco personas para crear un lanzamiento secreto de Node.

js. Está bien, estamos en progreso. Hemos estado haciendo eso por más de un año. Tenemos un buen progreso, pero todavía hay muchas cosas por hacer. Y te invitamos a ayudarnos en ese frente. También tenemos el modelo de amenazas de mantenimiento, que es, hemos definido el modelo de amenazas de Node.js, pero Node.js es una gran organización. Tenemos más de 100 colaboradores. ¿Y qué pasa con las personas del equipo del sitio web, que son rechazadas? ¿Qué pueden hacer? ¿Qué puede hacer una persona malintencionada, que tiene acceso al sitio web podría hacer al binario de Node.js? Hemos creado una larga lista de los roles y el acceso que tienen. Y luego hemos restringido los alcances a una situación específica. Así que el equipo del sitio web solo tiene acceso al repositorio de Node.js.org, pero no pueden acceder a las máquinas de construcción, por ejemplo.

Y luego hemos creado eso, y esto es muy útil. Está concluido, puedes consultar la lista y la tabla también. También tenemos, como mencioné antes, la hoja de ruta del modelo de permisos, hemos creado eso. Y esta fue una pull request que tomó ocho meses en aterrizar. Y tuvimos más de 500 discusiones en esa solicitud. Es una lista larga, pero finalmente la tenemos aterrizada en esta tabla. Puedes usar eso. Hay dos discusiones en curso, que en el momento de grabar esto, estamos discutiendo activamente, que es mover los informes de seguridad a un flujo de trabajo público. Node.js tendrá el Node.js Collaborator Summit del 14 al 15 de abril en Londres. Estaré allí, y voy a discutir estos dos temas. El primero es, ¿qué tal manejar los informes de seguridad en público? Esto es bastante controvertido, y no estoy seguro de los detalles sobre eso en esta llamada, porque en el momento en que estés viendo esto, mucho podría haber cambiado. Así que te sugiero encarecidamente que eches un vistazo a este tema en el canal de Node.js TSC.

Todo eso está en desarrollo activo, y esperamos cierta participación de la comunidad. Así que si quieres ayudar, esta sería una muy buena manera de ayudar. El siguiente son los lanzamientos de seguridad. Node.js, si no me equivoco, de 2024 a 2026, hemos emitido cuatro lanzamientos de seguridad. El 14 de febrero, hemos solucionado el ataque Morphine, múltiples elusiones del modelo de permisos, porque en 2024, el modelo de permisos aún era experimental. Así que significa que cualquier error en esa característica experimental sigue siendo una vulnerabilidad de seguridad, porque es un cinturón de seguridad, ¿verdad? Y luego tenemos el 3 de abril, tenemos HTTP2 DOS, condición de carrera NGTPP2. Muchas solicitudes HTTP son contrabando. Fue otro lanzamiento de seguridad. Luego tuvimos otro en abril.

El siguiente fue en julio, el 21 de enero. El último fue el 13 de enero, en el que solucionamos ocho vulnerabilidades, también en HTTP2. Async hooks, DOS, para este en específico, estoy bastante seguro de que sabes sobre eso, porque esto afectó a aplicaciones Next por DOS. Next y también cualquier APM como Datadog, New Relic. Así que todos esos lanzamientos de seguridad, tenemos una especie de publicación de blog post-mortem, que explica la vulnerabilidad y cómo la solucionamos. Así que si quieres aprender más sobre Node.js, siéntete libre de echar un vistazo a esas publicaciones de blog. Todo está disponible en nodejs.org, ¿de acuerdo?

Y luego una cosa, muy importante, la estrategia de versiones al final de su vida útil. He mencionado aquí que a pesar de estar al final de su vida útil, Node.js 16 y 18 tenían más de 120 millones de descargas semanales, ¿de acuerdo? Y en 2025, esto representa casi el 30% del ecosistema de Node.js, ¿de acuerdo? La solución, hemos intentado muchas maneras de resolver eso. Y una de ellas fue, ¿qué tal emitir un CVE para todas esas versiones al final de su vida útil? Esto es totalmente en contra de la estrategia habitual de emitir CVEs. Un CVE debería tener una vulnerabilidad por definición, pero intentamos, de acuerdo, si la gente está usando mucho los escáneres de seguridad y están usando versiones al final de su vida útil, si emitimos un CVE para esas versiones sin un parche, sentirán el peligro y necesitarán actualizar eso. Intentamos, recibimos buenos comentarios de la comunidad de los usuarios de Node.js, pero también recibimos malos comentarios de Mitre y los investigadores de seguridad porque esto va en contra de la definición de CVE.

Nuestra segunda solución fue, el proyecto Node.js no puede evaluar retroactivamente más de 20 versiones al final de su vida útil. Es mucho. Está fuera de la propuesta de mantenimiento de Node.js, ¿de acuerdo? Y cambiamos nuestra estrategia para que todos los nuevos CVEs ahora incluyan explícitamente las líneas de lanzamiento al final de su vida útil. Así que de ahora en adelante, cualquier CVE que emitamos, también incluimos Node.js 4, Node.js 5, 6, 7, 8, 10 en el rango de la lista de CVEs afectados, ¿de acuerdo? Así que si vamos a lanzar un CVE para HTTP2, también vamos a incluir Node.js 18, Node.js 16 en la lista de versiones afectadas. Esto podría ayudar.

Y mencioné antes, el modelo de amenazas de Node.js es muy importante. Puedes consultarlo en la política de seguridad de Node.js. ¿Y qué es exactamente un modelo de amenazas? Básicamente define cuáles son los límites de seguridad en Node.js. ¿Qué puede considerarse una vulnerabilidad y qué no? ¿Contra qué protege Node.js de forma nativa y contra qué no? Así que para las situaciones contra las que no te protegemos, necesitas sanitizar la entrada, por ejemplo, la entrada remota HTTP. No deberías evaluar eso. Node.js no crea medidas contra eso. Nunca sanitizaremos la entrada remota porque eso va en contra de las reglas ARFC, especificación HTTP. Es tu obligación como desarrollador hacer eso, validar la entrada y validar la salida también.

¿Y en qué confía Node.js? Confiamos, las cosas en las que confiamos son básicamente, cuando decimos que confiamos, significa que no creamos medidas contra eso. Así que si estás ejecutando Node.js en un entorno inseguro, como una versión antigua de Ubuntu o un sistema de archivos compartido con diferentes usuarios maliciosos, simplemente confiamos en el sistema de archivos. Si estás usando eso en un entorno no seguro, es tu elección y podrías ser vulnerable a eso. Y esto no es responsabilidad de Node.js. Sistema operativo, todo el código que ejecuta, así que no puedes copiar un código de internet y ejecutarlo y esperar que Node.js te proteja contra eso. Esto es incorrecto. Por ejemplo, obtienes una entrada remota de tu servidor HTTP y haces un JSON dot parse. Si el usuario malicioso pasa un JSON realmente largo, puedes quedarte sin memoria y tu proceso puede fallar debido al Out-of-memory killer. Así que esta es tu responsabilidad.

¿Y contra qué te protege Node.js? Datos de red entrantes y salientes. Si alguien te envía una solicitud y antes de procesarla, tu servidor se bloquea, esto es culpa de Node.js y posiblemente sea una vulnerabilidad de Node.js. Si estás consumiendo un archivo y tu proceso se bloquea, esto es culpa de Node.js. Así que tenemos una larga lista de ejemplos en tu modelo de amenazas y tengo una sugerencia para revisarlo.

Solo para finalizar aquí, si estás en Node.js 18 o inferior, por favor actualiza. Si estás en Node.js 20, en el momento en que hablo de eso, todavía está activo pero llegará al final de su vida útil a finales de abril de 2026. Y si estás en Node.js 22, estás seguro pero considera actualizar a Node.js 24 y deberías tener un plan de migración a Node.js 26. Eso debería salir en abril de 2026. Vamos a cambiar el calendario de lanzamientos de Node.js. Es otra discusión pero echa un vistazo a los anuncios que vamos a hacer.

Solo como un adelanto, la nueva estrategia de lanzamiento comenzará con Node.js 27 y solo tendremos una línea de lanzamiento por año. Node.js 27 estará en Node.js 2027. Node.js 28 estará en 2028 y solo tendremos una por año y todas esas versiones serán LTS. Así que para aquellos que no dependen de todas las versiones, pueden hacerlo ahora. Comienza con Node.js 27. Es otra masterclass. Si quieres saber más sobre eso, siéntete libre de contactarme en GitHub, Slack, X, no importa. Y eso es todo, eso es todo. Un último comentario es que la seguridad es un viaje, no es un destino. Nunca terminaremos con la seguridad. Nunca se concluirá y gracias a NodeSource, a Alpha Omega OpenJS Foundation, me patrocinaron para trabajar en eso y ayudar a los desarrolladores de Node.js a crear un entorno más seguro. Gracias a todos los voluntarios por mantener Node.js seguro y a los grupos de trabajo en los que participo. Gracias, amigos. Así es como puedes involucrarte. Adiós.