Fallo en Node.js: qué hacer ahora

El 21 de octubre el proyecto Node.js publicó una actualización de seguridad para diez fallos. El más grave, CVE-2026-111497, está en la parte que descomprime datos comprimidos con Brotli. Con datos preparados a propósito, un atacante puede escribir fuera de la memoria reservada. Eso puede bloquear un programa, filtrar memoria o, en el peor de los casos, ejecutar el código del atacante. El fallo afecta a todas las versiones de Node.js con soporte y a todas las anteriores. Las versiones 22.23.4, 24.22.1 y 26.12.1 lo corrigen.

Por qué esto llega más lejos de lo que parece

Node.js funciona por debajo de muchas aplicaciones web, API, portales de clientes y herramientas internas, y también de muchas herramientas de desarrollo y de IA. No hace falta que uses Brotli tú mismo para verte afectado. Brotli es una forma habitual de reducir el tráfico web, y la función fetch integrada de Node.js descomprime esas respuestas automáticamente. Si tu aplicación descarga algo de una dirección que controla otra persona, eso ya puede bastar.

Además, Node.js en un servidor a menudo no se actualiza solo. Si alguna vez se instaló desde una fuente de paquetes propia o con un script de instalación, se queda en esa versión hasta que alguien lo actualiza a propósito. Las actualizaciones de seguridad automáticas del sistema operativo normalmente no lo incluyen.

Qué hacer ahora

1. Averigua qué funciona con Node.js en tu organización: tu web o aplicación web, un portal de clientes, las conexiones entre sistemas y los servidores donde trabajan desarrolladores o agentes de IA. ¿No estás seguro? Pregunta a tu desarrollador web o a tu proveedor de TI.
2. Actualiza a 22.23.4, 24.22.1 o 26.12.1, según la versión que uses. Si usas una versión sin soporte, no llegará ninguna corrección: pasa a una versión con soporte.
3. Después comprueba qué versión funciona de verdad. Un paquete actualizado no sirve de nada mientras el proceso antiguo siga en marcha; la nueva versión solo funciona tras un reinicio.
4. Comprueba si desde principios de octubre algún proceso de Node.js se ha bloqueado de forma inesperada. Un ataque fallido suele dejar un bloqueo. Si encuentras uno, recurre a alguien que sepa del tema.
5. Anota qué hiciste y cuándo. Si tu organización está sujeta a NIS2, o un cliente pide pruebas de tu seguridad, lo tendrás a mano.

Y Stilops

Stilops funciona con Node.js, y nuestros agentes descargan páginas web para su trabajo. Así que estábamos afectados. El mismo día que vimos el fallo, hicimos que cada despliegue lleve primero Node.js a la versión corregida, y que las máquinas en las que trabajan los agentes se reconstruyan con esa versión. Nuestro entorno de pruebas ahora también descarga siempre la última versión.

Después buscamos señales de abuso. No encontramos ningún bloqueo inesperado de Stilops desde el 8 de octubre, hasta donde llegan nuestros registros, ni archivos de bloqueo. Que no haya rastros no prueba que no haya pasado nada, pero es lo que se puede medir. Seguimos vigilando.