Ciberseguridad
Redacción Teknosfera
Ciberseguridad

HTTP2Shell no es un fallo de HTTP/2, y eso es lo que da miedo

El fallo que afecta a Node.js y, según se informa, a Python está en un decodificador Brotli, no en HTTP/2. Es una lección sobre código compartido que nadie audita y sobre parchear como trabajo de emergencia.

Publicado
24 de octubre de 2026
Lectura
4 min
Categorías
Ciberseguridad

Foto: VIA Gallery from Hsintien, Taiwan / Wikimedia Commons (CC BY 2.0)

Seguramente tu equipo tiene una lista de los frameworks de los que depende. ¿Tiene una lista de los descompresores? HTTP2Shell es uno de los nombres que ahora se asocian a un fallo de ejecución remota de código que afecta a Node.js y, según se informa, a bibliotecas de Python. A pesar del nombre, el culpable no es el protocolo. Es un decodificador de compresión.

El fallo está en el descompresor, no en el protocolo

Como explica Brandefense, se trata de un único fallo, CVE-2026-111497, en el decodificador Brotli que incluye Node.js. Primero se llamó Node2Shell y, desde última hora del 23 de octubre (UTC), también se le llama HTTP2Shell. Node.js lo corrigió el 21 de octubre de 2026 en las versiones 22.23.4, 24.22.1 y 26.12.1. El registro CVE le otorga un 9,2 en CVSS 4.0. El aviso atribuye el informe a OpenAI Codex Security.

Aikido afirma que el mismo fallo de Brotli afecta a muchas bibliotecas y aplicaciones que usan HTTP con Brotli o brotlicffi instalados. La ejecución remota de código en la imagen oficial de Node.js 24.22.0 es, por ahora, lo que han comunicado los investigadores. Aikido lo presenta como un informe y no como una prueba propia, y añade que el exploit no funcionó siempre. Según se informa, el código de prueba de concepto público bloquea Node.js sin parchear, pero no se ha mostrado en código público una ejecución remota que funcione. A nuestro juicio, esa distinción cambia el tono con el que conviene describir el fallo. No cambia la rapidez con la que hay que parchear.

El nombre equivocado apunta a la capa equivocada

Llamarlo HTTP2Shell es comprensible. El fallo aparece en la ruta HTTP y el nombre es pegadizo. Pero dirige la atención a la capa equivocada. Nadie debería ponerse a buscar un ajuste de HTTP/2 para desactivarlo.

La explicación de Brandefense, que recoge la de Vercel, muestra lo corriente que es la exposición. Node.js no decodifica Brotli por sí solo. Una aplicación queda expuesta cuando su propio código, o una biblioteca que usa, descomprime datos Brotli controlados por un atacante. El investigador Ron Masas escribió en X que, en un entorno de ejecución vulnerable, «app.use(express.json) es suficiente». Brandefense dice que eso coincide con lo que hace el código fuente de Express 5. Una petición JSON con codificación de contenido Brotli se decodifica antes de que se ejecute el código de tus rutas.

Esa es la parte incómoda. En muchos equipos, sospechamos, nadie programó una función de Brotli y nadie revisó ninguna. La exposición llegó como comportamiento por defecto de algo que sí elegiste. Y Brandefense señala que otros middleware, frameworks, proxies inversos y tu propio código también pueden decodificar Brotli. Cada uno de ellos es un sitio que revisar.

Parchear debe ser trabajo de infraestructura, no una tarea de sprint

La cronología es el argumento. Node.js publicó las correcciones a las 10:38 UTC del 21 de octubre. Según Brandefense, el primer repositorio de GitHub para el CVE apareció unas cinco horas después, y a última hora del 23 de octubre una búsqueda devolvía 25. A nuestro juicio, los defensores no tienen margen de gracia cuando los parches pueden compararse con el código antiguo.

Ese mismo día, PHP publicó sus propias correcciones para los fallos independientes de PHP2Shell. El equipo de seguridad de la Universidad de Toronto advierte de que se espera una explotación masiva en poco tiempo y de que Cloudflare ya había informado de ataques tempranos. No queremos fundir dos errores sin relación en una sola historia. Pero que dos fallos críticos de entornos de ejecución coincidan es lo que parece una mala semana cuando tanto depende de un puñado de entornos compartidos.

Hay una segunda lección, sobre el software al final de su vida útil. Brandefense cita a Vercel diciendo que Node.js 20 «no recibirá esta corrección». Los equipos anclados a un entorno sin soporte no van un parche por detrás. No tienen ningún parche que aplicar. Es una decisión presupuestaria tomada hace meses que se paga en un fin de semana.

Wiz sostiene en su análisis de PHP2Shell que los modelos de IA de frontera le permitieron desarrollar y adaptar exploits funcionales en horas. Lo trataríamos como una afirmación que merece tomarse en serio, no como un hecho probado. Si se confirma, pierde fuerza el viejo consuelo de que un fallo es demasiado complejo para que alguien lo explote.

Tarea para el lunes: inventariar, actualizar, asignar un responsable

Nuestra recomendación es sencilla. Comprueba tus versiones con node --version y localiza todos los puntos en los que tu código o una dependencia descomprime Brotli procedente del exterior. Actualiza a las versiones corregidas y abandona Node.js 20. No ejecutes código de prueba de concepto de GitHub fuera de un laboratorio aislado, porque el código de exploits de cuentas desconocidas puede esconder malware.

El cambio de fondo es organizativo. Las actualizaciones de entornos de ejecución y bibliotecas no deberían esperar en una cola detrás de las nuevas funcionalidades. Deben tener un responsable, un inventario y un plazo de la misma semana. Un fallo como este no será el último, y creemos que los equipos que lo traten como mantenimiento rutinario de infraestructura serán los que apenas noten el siguiente.

Temas de debate

Aún no hay temas: abre el primero.

Más noticias