José ZegarraUna falla en el descompresor Brotli puede comprometer aplicaciones que procesan contenido manipulado por un atacante. Hay actualizaciones para Node.js, Bun y paquetes de Python. La prioridad es localizar dónde se utiliza el componente vulnerable, comprobar si recibe datos externos y desplegar las correcciones en los servicios que realmente están ejecutándose.
Lima, Perú, 25 de octubre de 2026.— El proyecto Node.js publicó el pasado 21 de octubre de 2026 actualizaciones que corrigen una vulnerabilidad en la biblioteca Brotli incorporada en su entorno de ejecución. Identificada como CVE-2026-111497 y difundida como Node2Shell, la falla puede provocar corrupción de memoria, interrupciones del servicio, exposición de información o ejecución remota de código cuando una aplicación descomprime datos maliciosos. Wednesday, October 21, 2026 Security Releases
El problema también alcanza a otros productos que incorporan versiones vulnerables del descompresor. Esto exige revisar dependencias compartidas, aunque no significa que cualquier aplicación que utilice Brotli esté automáticamente expuesta a un ataque remoto.
La condición decisiva es que contenido controlado por un atacante llegue al código vulnerable de descompresión.
Table of Contents
La falla está en el descompresor, no en HTTP/2
Brotli permite reducir el tamaño de los datos transmitidos o almacenados. En la web, la identificación br suele indicar contenido comprimido con este formato.
El defecto se encuentra en el decodificador: la parte que reconstruye los datos originales. Según Node.js, una entrada comprimida malformada puede provocar que el procesamiento continúe cuando debería terminar con un error. El resultado es una escritura fuera de los límites de un búfer interno.
Esa escritura puede alterar memoria del proceso. Sus consecuencias dependen del programa, la plataforma y las protecciones existentes; no todos los fallos de memoria producen una ejecución de código aprovechable.
Los nombres Node2Shell y HTTP2Shell facilitan reconocer el incidente, pero el segundo puede inducir a error. No se trata de una vulnerabilidad del protocolo HTTP/2. También deben evaluarse aplicaciones que reciben archivos comprimidos o consumen respuestas externas, aunque no sean servidores web.
Por ejemplo, un servicio interno que descarga información de terceros podría descomprimir automáticamente una respuesta Brotli. Estar fuera de la exposición directa a internet no elimina esa posible ruta de entrada.
Qué está confirmado y qué requiere cautela
El aviso de Node.js clasifica la vulnerabilidad como de severidad alta y acredita su reporte a Khai Tran y Sylvie Mayer, de OpenAI Codex Security. La publicación oficial de Brotli 1.2.1 también identifica la corrección de CVE-2026-111497. Wednesday, October 21, 2026 Security Releases
Imperva informa haber conseguido ejecución de código en una prueba sobre la imagen oficial de Node.js 24.22.0 para Linux ARM64. Es una demostración relevante, pero corresponde a un entorno concreto y no acredita explotación equivalente en todas las arquitecturas o productos. Fuente: Imperva
La distinción aparece expresamente en el aviso de seguridad de Bun: sus responsables indican que no han probado un ataque contra Bun y recomiendan tratar el defecto como un riesgo de ejecución remota de código. Fuente: GitHub
Al cierre de esta revisión, el 25 de octubre, las fuentes consultadas permiten confirmar vulnerabilidad, correcciones y demostraciones técnicas. No permiten establecer aquí la magnitud de una eventual explotación en organizaciones. La falta de una confirmación no debe interpretarse como prueba de que no existan ataques.
Tabla analítica: dónde revisar y qué actualizar
| Componente | Alcance que debe revisarse | Corrección de referencia | Comprobación necesaria |
|---|---|---|---|
| Node.js | Líneas 22.x, 24.x y 26.x anteriores a los parches; revisar también instalaciones fuera de soporte. | 22.23.4, 24.22.1 o 26.12.1, según la línea. | Versión del proceso en producción y rutas que descomprimen contenido externo. |
| Bun | El aviso identifica versiones desde 1.0.21 hasta anteriores a 1.4.4. | 1.4.4. | Actualizar el entorno y reconstruir ejecutables que lo incorporen. |
Python: brotli |
El aviso de paquetes identifica versiones desde 1.0.3 hasta anteriores a 1.2.1. | 1.2.1. | Entorno virtual, contenedor y dependencias efectivamente desplegadas. |
Python: brotlicffi |
El aviso identifica versiones desde 1.0.3 hasta anteriores a 1.2.1.0. | 1.2.1.0. | Versión instalada y clientes o servicios que utilizan su descompresión. |
| Biblioteca Brotli original | Versiones vulnerables de la familia 1.0.3–1.2.0, con excepciones para las publicaciones corregidas. | 1.0.10, 1.1.1 o 1.2.1, según la rama. | Copias incorporadas al producto y posibles parches del distribuidor. |
| Envoy e Istio | Descompresión Brotli habilitada y componente vulnerable presente. | Actualización indicada por el proveedor para la rama utilizada. | Configuración, versión de los proxies y reemplazo de instancias antiguas. |
Las referencias corresponden a los avisos de Node.js, Bun, los paquetes Python y las publicaciones de Brotli. No deben intercambiarse los números de versión entre productos.
Istio advierte específicamente que deben actualizar quienes habilitan la descompresión Brotli, por ejemplo mediante un EnvoyFilter. La mera presencia de Istio no describe por completo la exposición. istio.io
Cómo responder sin dejar copias vulnerables en producción
Localizar el componente y su ruta de entrada
El inventario debe incluir aplicaciones, tareas programadas, servicios de integración, imágenes de contenedores y ejecutables que incorporen su propio entorno de ejecución.
La revisión debe responder dos preguntas: ¿qué versión está funcionando y qué contenido puede llegar al descompresor? Buscar únicamente paquetes en el servidor puede omitir componentes incluidos dentro de una imagen o de un binario.
En un portal web, comprimir las páginas que se envían al lector no demuestra que exista la ruta vulnerable. Hay que identificar si algún componente también descomprime entradas externas.
Priorizar la exposición y desplegar la corrección
Conviene atender primero los servicios que reciben solicitudes o archivos no confiables y los que descargan contenido de destinos externos. También deben considerarse los permisos del proceso, los datos a los que accede y su importancia operativa.
Actualizar el equipo de desarrollo no corrige automáticamente lo desplegado. Después del cambio corresponde reconstruir las imágenes o ejecutables necesarios, desplegarlos y reemplazar las instancias anteriores.
Bun señala expresamente que los programas generados con bun build --compile conservan el entorno incorporado: deben reconstruirse con la versión corregida.
Aplicar medidas temporales con un alcance definido
Si el parche necesita una ventana de pruebas, puede evaluarse impedir que entradas no confiables alcancen el descompresor. La medida debe comprobarse en cada aplicación.
Retirar br de una negociación HTTP no demuestra que hayan desaparecido otras rutas de descompresión. Tampoco una regla de firewall o WAF sustituye la actualización del componente.
Las medidas temporales deben tener responsable, fecha de revisión y pruebas de funcionamiento. Los ensayos con contenido malformado deben realizarse en un laboratorio autorizado, no sobre producción.
Verificar la recuperación y revisar indicios
El cierre debería registrar versiones desplegadas, instancias reemplazadas y resultados de las pruebas funcionales. En paquetes de una distribución, corresponde revisar su aviso de seguridad: un parche puede haberse aplicado sin adoptar la numeración de la publicación original.
También conviene revisar reinicios inesperados, errores del descompresor, fallos de memoria y comportamientos anómalos del proceso. Ninguno confirma por sí solo un ataque. Si aparecen indicios consistentes, la respuesta debe incluir preservación de evidencia y evaluación del alcance; actualizar no elimina una intrusión previa.
Visión estratégica para Perú y Latinoamérica
Para bancos, comercios, entidades públicas y proveedores regionales, el desafío es conocer qué componentes sostienen sus servicios y quién responde por actualizarlos. Una dependencia compartida puede aparecer en aplicaciones desarrolladas internamente, plataformas contratadas y herramientas de integración.
Las organizaciones deberían pedir a sus proveedores evidencia concreta: producto afectado, exposición identificada, corrección aplicada y fecha de despliegue. Una respuesta genérica de «no usamos Node.js» resulta insuficiente cuando la falla reside en una biblioteca incorporada también por otros productos.
Este caso refuerza el valor de mantener inventarios de dependencias y ensayar actualizaciones fuera de emergencia. La decisión empresarial debe combinar exposición, impacto y capacidad de recuperación. El objetivo es reducir el riesgo con cambios verificables y mantener una ruta de actualización para las instalaciones que ya no reciben soporte.
Glosario
- Brotli.- Formato de compresión y biblioteca utilizada para comprimir y descomprimir datos.
- Decodificador o descompresor.- Componente que reconstruye los datos originales a partir del contenido comprimido.
- CVE.- Identificador público de una vulnerabilidad; permite relacionar avisos y correcciones del mismo problema.
- Búfer.- Zona de memoria reservada temporalmente para almacenar datos durante su procesamiento.
- Escritura fuera de límites.- Operación que escribe fuera de la memoria reservada y puede alterar otros datos del proceso.
- RCE.- Ejecución remota de código: posibilidad de que un atacante consiga ejecutar instrucciones en el sistema afectado.
- Dependencia incorporada.- Biblioteca incluida dentro de otro producto, que puede necesitar una actualización de ese producto.
- Parche retroportado.- Corrección adaptada a una versión anterior, sin adoptar necesariamente la numeración de la versión más reciente.
- SBOM.- Inventario estructurado de los componentes de software de un producto.
- PoC.- Prueba de concepto que demuestra una condición técnica bajo circunstancias determinadas; no acredita por sí sola ataques reales.
Tu Opinión Nos Importa 🗣️
Si hoy tuvieras que localizar una biblioteca vulnerable en todos tus servicios, ¿podrías hacerlo con tu inventario actual? Me interesa conocer qué cuesta más en tu organización: identificar las dependencias, obtener respuestas de los proveedores o completar el despliegue de los parches.
Comparte tu experiencia con nuestros hashtags #ItusersAwards2026 y #superfan.
Apoya al Periodismo Independiente
¿Te sirvió en algo este contenido?, ayúdanos a combatir la Desinformación, dona desde S/ 1.00 a nuestro PLIN 943-438-457
