Un fallo en Brotli obliga a actualizar Node.js, Bun y ciertos despliegues de Envoy

Introducción

El riesgo puede entrar por una operación rutinaria: descomprimir una respuesta de otro servidor o el contenido de una petición web. Un fallo en Brotli, identificado como CVE-2026-111497, permite que datos manipulados dañen la memoria del proceso y, bajo determinadas condiciones, abran la puerta a ejecutar código sin autenticación previa. Node.js publicó correcciones el 21 de octubre [1]. Los avisos de Bun [4] y Envoy [3], fechados el 23, delimitan también sus productos afectados.

La Agencia de Ciberseguridad de Singapur [2] recomienda actualizar inmediatamente y le atribuye una puntuación de 9,8 sobre 10 en CVSS 3.1. Esa cifra debe acompañarse de su procedencia: Node.js y Bun clasifican el problema como de gravedad alta, mientras Envoy lo considera crítico, con un 9,2 en CVSS 4.0. Las etiquetas y las escalas no son intercambiables. Todos estos avisos justifican atender el fallo.

Qué se rompe al descomprimir

Brotli permite reducir el tamaño de los datos para transmitirlos y recuperar después su contenido. El defecto está en el código que los descomprime. Según la explicación de Node.js, una transición inválida dentro del flujo comprimido se interpretaba como una necesidad temporal de recibir más datos. El procesamiento continuaba y podía escribir fuera de un pequeño espacio de memoria reservado para el decodificador.

Esa escritura fuera de sus límites puede provocar una caída del proceso, revelar información de su memoria o permitir ejecutar código. Para que exista una vía de ataque, los datos controlados por el atacante deben alcanzar el descompresor vulnerable. Encontrar Node.js en un inventario identifica algo que revisar. Por sí solo no demuestra que una aplicación concreta sea explotable.

La exposición tampoco se limita a recibir peticiones. Bun explica que su función fetch puede descomprimir automáticamente respuestas Brotli de servidores a los que se conecta. Envoy circunscribe el impacto a los despliegues que tengan configurado el descompresor Brotli. Por eso hay que seguir el recorrido real de los datos y comprobar la configuración.

Una prueba de ejecución no equivale a una campaña de ataques

La empresa de seguridad Imperva comunicó el 22 de octubre [7] que había conseguido ejecutar código en aplicaciones de prueba sobre la imagen oficial de Node.js 24.22.0 para Linux arm64. Afirma que no necesitó un depurador ni un binario instrumentado y que los mismos datos fueron rechazados por la versión corregida 24.22.1. El resultado necesitó varios intentos y se refiere a las configuraciones ensayadas. Esta redacción no ha reproducido la prueba.

Es evidencia de que el impacto puede ir más allá de una caída del servicio. La prueba publicada no acredita por sí misma ataques masivos ni servidores comprometidos fuera de ese ensayo. El registro CVE incorpora una evaluación de CISA fechada el 23 de octubre que consigna «none» en su campo de explotación. Es una observación fechada, no una garantía de que no haya ataques ni una razón para posponer el parche. Registro CVE [6].

El aviso de Node.js y el registro CVE atribuyen el hallazgo a Khai Tran y Sylvie Mayer, de OpenAI Codex Security. Ese crédito identifica a los investigadores. No permite deducir por sí solo cuánto trabajo realizó una herramienta de IA ni que el descubrimiento fuera enteramente autónomo.

Qué actualizar y qué comprobar después

Estas son las versiones que incorporan la corrección según los avisos originales. Se puede instalar una versión posterior corregida de la misma rama compatible.

Las filas proceden de los boletines de Node.js, Bun y Envoy enlazados al comienzo. Envoy identifica expresamente como afectadas las versiones 1.36.11, 1.37.7, 1.38.5 y 1.39.2. En la biblioteca Brotli, las correcciones son 1.0.10, 1.1.1 y 1.2.1, según la rama, conforme al registro CVE y a la publicación de Brotli 1.2.1 [5]. No se debe trasladar la numeración de la biblioteca a la del producto que la incorpora.

Para quien administra un proyecto, la comprobación útil tiene tres pasos: localizar el componente que procesa datos externos, actualizar el entorno que lo ejecuta y verificar la versión que está funcionando después del despliegue. Una actualización del ordenador de desarrollo no cambia por sí sola los servidores ni las imágenes de contenedor. Bun añade una advertencia concreta: sus ejecutables compilados incluyen el entorno de ejecución y deben reconstruirse con la versión corregida.

Mientras se completa la actualización, limitar la llegada de datos Brotli no fiables puede reducir la exposición en las rutas identificadas. Bun advierte de que sus medidas temporales no constituyen una solución para todo el proceso. Hay que comprobar su alcance y su compatibilidad con el servicio. La reparación del componente sigue siendo la medida principal.

La dependencia que comparte la web

El episodio llega después de los dos fallos críticos de PHP corregidos el 21 de octubre [8]. Son vulnerabilidades diferentes. La conexión está en que aplicaciones muy distintas pueden heredar un problema del software común sobre el que funcionan.

Reutilizar componentes permite construir servicios sin desarrollar cada pieza desde cero. Abandonar esa práctica no ofrece una respuesta razonable a este incidente. La responsabilidad consiste en saber qué incorpora cada servicio y poder sustituirlo cuando aparece una corrección. Un parche disponible solo protege un proyecto cuando llega al componente que realmente está ejecutando su aplicación. Esa es la distancia que conviene cerrar ahora.