Node.js corrige una vulnerabilidad de alta gravedad en su decodificador Brotli

El proyecto Node.js ha publicado actualizaciones de seguridad para corregir CVE-2026-111497, un fallo de escritura fuera de límites en su decodificador de Brotli integrado que, según el proyecto, podría permitir ejecución remota de código. La falla está clasificada como de gravedad alta, no crítica, y afecta a las ramas 22.x, 24.x y 26.x. Las organizaciones que mantienen aplicaciones Node.js deben actualizar sus entornos y revisar si procesan contenido comprimido de origen no confiable.

Cómo funciona el fallo

Brotli es un algoritmo de compresión muy usado para reducir el tamaño de las respuestas web. Node.js incluye su propia copia de la biblioteca, de modo que el error reside en código que el propio runtime distribuye. Según la información disponible, un flujo de datos comprimido malformado puede hacer que el decodificador escriba fuera del búfer de memoria reservado para los datos descomprimidos. La corrección upstream hace que la entrada inválida se rechace antes de llegar a esa condición insegura.

La vía de exposición depende de cómo entran los datos en la aplicación. Una llamada directa a las APIs de descompresión de node:zlib es una ruta evidente. Pero también puede bastar con que fetch() reciba una respuesta con Content-Encoding: br, porque Node.js la descomprime de forma automática. Por eso son especialmente sensibles los servicios de vista previa de URL, rastreadores, procesadores de webhooks, pasarelas proxy y cualquier aplicación que descargue contenido remoto elegido por un usuario o por un tercero.

Versiones afectadas y alcance

Las versiones corregidas son Node.js 22.23.4, 24.22.1 y 26.12.1, publicadas en el lanzamiento de seguridad del 21 de octubre de 2026, que resolvió diez vulnerabilidades en total. Las ramas anteriores a 20.x ya no reciben soporte y no tendrán esta corrección, así que las organizaciones que las usen deben migrar a una rama soportada. El código vulnerable proviene también del proyecto Brotli, cuyas correcciones se publicaron en las versiones 1.0.10, 1.1.1 y 1.2.1; otras aplicaciones que incorporen copias antiguas de la biblioteca podrían necesitar parches propios aunque no usen Node.js.

Conviene matizar la gravedad. Un proof of concept público logró ejecución de código solo contra una versión de prueba deliberadamente debilitada. En una versión estándar, el investigador documentó un fallo del proceso y una divulgación limitada de memoria, pero no consiguió ejecución fiable. Al 22 de octubre no se había informado de explotación activa. Tampoco se han publicado indicadores de compromiso específicos de campaña, como IP, dominios o hashes, en la investigación citada.

Medidas prioritarias

La mitigación principal es actualizar el runtime y reiniciar los servicios afectados, porque los procesos de larga duración siguen usando la versión antigua hasta que se reinician. En contenedores, actualizar Node.js en el host no basta: hay que reconstruir las imágenes para que incorporen el runtime corregido. Las organizaciones que usen Brotli por separado también deben revisar sus inventarios de software y sus SBOM para localizar copias integradas en aplicaciones, dispositivos o paquetes de terceros.

Si una actualización inmediata no es posible, pueden reducirse temporalmente la superficie de ataque y la exposición:

• Rechazar cuerpos de solicitud comprimidos con Brotli cuando la compresión no sea necesaria.
• Restringir las peticiones HTTP del lado del servidor a destinos de confianza y evitar que los usuarios introduzcan URL remotas arbitrarias.
• Limitar la conectividad saliente de las cargas de trabajo vulnerables.
• Vigilar fallos de la aplicación, errores de memoria y procesos hijos inesperados.

Un filtro WAF no sustituye al parche. Vercel añadió reglas para bloquear datos Brotli maliciosos en solicitudes entrantes, pero esas protecciones no cubren las respuestas maliciosas que la aplicación descarga por su cuenta desde servidores externos. Ante una sospecha de explotación, conviene aislar la carga de trabajo, conservar telemetría y volcados de fallo, y revisar las credenciales y tokens accesibles desde el proceso, dado que la divulgación limitada de memoria obliga a considerar esos secretos como potencialmente expuestos.