Broccoli2Shell demuestra que tu código más arriesgado es el que no elegiste

¿Qué biblioteca descomprime los datos que recibe tu servidor? Si no sabes responder en menos de un minuto, Broccoli2Shell también es tu problema, hayas escrito o no alguna vez la palabra "Brotli" en tu código.

El fallo es el CVE-2026-111497, una escritura fuera de límites en el descodificador Brotli de Google. Según Strobes, afecta a las versiones de Brotli de la 1.0.3 a la 1.2.0 y tiene una puntuación de 9,2 (crítica) en CVSS 4.0. Como los clientes y servidores HTTP descodifican Content-Encoding: br de forma automática, llega a Node.js, Python, Bun y otros entornos a través del tráfico web normal. Node.js publicó correcciones el 21 de octubre en las versiones 22.23.4, 24.22.1 y 26.12.1, según informan Qualys y otros. El nombre ha cambiado varias veces (Node2Shell, HTTP2Shell, Broccoli2Shell), siempre para el mismo CVE.

El cambio de nombre es la verdadera noticia

Strobes señala algo muy acertado: el apodo cambió tres veces en cuatro días, y cada nombre reflejaba a quién creía expuesto el sector. Empezó como un parche de un entorno de ejecución y acabó siendo un problema de dependencias y de cadena de suministro. Creemos que ese recorrido es la lección. El código vulnerable está en una biblioteca en C que muchos proyectos incluyen, enlazan o heredan. Nadie la "instaló" por decisión propia. Venía con el entorno de ejecución, el cliente HTTP o la imagen.

Por eso es una infraestructura invisible. Semgrep apunta que el fallo no está en un paquete de npm llamado brotli, ni en el propio body-parser. Sin embargo, body-parser entrega al descodificador datos comprimidos controlados por el atacante. Tu escáner de dependencias puede quedarse callado mientras el problema está una capa por debajo. Strobes también menciona un seguimiento público, mantenido por investigadores independientes, que enumera los proyectos cuyas copias incluidas seguían sin parchear el 24 de octubre, entre ellos el entorno de ejecución de.NET, la extensión brotli de PHP y la gema brotli de Ruby. Actualizar tu distribución no sirve de nada con el software que lleva su propia copia privada.

La exposición depende de las rutas, y la peor es la saliente

No todos los servicios de Node corren el mismo riesgo, y conviene decirlo claro para evitar el pánico. Semgrep subraya que la aplicación debe ejecutar una versión afectada, usar un analizador compatible con Brotli, tener la descompresión activada y exponer una ruta donde esté montado. Strobes afirma que Express 5 con body-parser 2.x descodifica por defecto los cuerpos de petición en Brotli, de modo que un simple app.use(express.json) puede poner el descodificador ante tráfico anónimo.

La ruta que más nos inquieta es la que nadie vigila: las respuestas que recoge tu propio código. El fetch integrado de Node descodifica Brotli automáticamente, y Strobes dice que urllib3, aiohttp y httpx de Python hacen lo mismo cuando hay un paquete de Brotli instalado, aunque tu código nunca lo importe. Los webhooks, las vistas previas de enlaces, la función de "importar desde URL", los rastreadores y los agentes de IA que navegan son puertas por las que puede entrar un extraño. Strobes añade que ningún WAF verá esta ruta. El WAF de Vercel, según TuxCare, bloquea la ruta entrante, pero no las respuestas obtenidas de otros sitios.

Parchear a la carrera no escala; los inventarios sí

La reacción habitual es un fin de semana de actualizaciones frenéticas. Con Node 22, 24 y 26 funciona: la corrección es, en palabras de TuxCare, aburrida. Pero TuxCare también advierte de que Node.js 20, 18 y anteriores no reciben nada del proyecto original, y el parque que has olvidado es justo el que muerde. Y está la trampa del reinicio: un proceso en ejecución conserva el viejo descodificador en memoria.

La cronología también debería preocuparnos. TuxCare, citando a The Hacker News, dice que el cambio que lo corrige entró en el código fuente de Brotli en febrero de 2026, pero no llegó en una versión de seguridad hasta el 21 de octubre. Strobes añade que nadie lo relacionó con la ejecución remota de código hasta octubre. Un parche público es un mapa, como dijo un autor en Medium. Strobes indica que existen pruebas de concepto públicas, y TuxCare señala que hasta el 22 de octubre no se había informado de explotación activa. Nosotros consideraríamos esa calma algo temporal, no tranquilizador.

La misma semana trajo PHP2Shell, que Semgrep describe como un fallo que existe en PHP desde hace más de una década, y Google Cloud afirma que las aplicaciones con PHP 7.4 siguen siendo vulnerables. Dos revelaciones sobre entornos de ejecución con un día de diferencia no prueban que la seguridad se haya derrumbado; la propia Semgrep dice que la tendencia general se gesta desde hace años. Pero sí muestra lo poco tiempo que tenemos para averiguar qué ejecutamos.

Nuestro veredicto

Parchea ya, evidentemente. Y luego haz el trabajo aburrido que de verdad te protege: mantén un inventario que baje más allá de los manifiestos de paquetes y cubra entornos de ejecución, bibliotecas nativas incluidas, imágenes base de contenedores, runners de CI y cada lugar donde tu código descarga una URL que controla otra persona. Retira los entornos de ejecución sin soporte en lugar de confiar en la suerte. Esperamos que tarde o temprano llegue el próximo fallo de descompresión, y el equipo que sepa responder en minutos a "¿dónde ejecutamos esto?" superará al que tenga las mejores hazañas de parcheo.