HTTP2Shell afecta a Microsoft .NET: por qué los parches fuera de

El parche que no da en el clavo

Microsoft lanzó el 25 de octubre una actualización de seguridad extraordinaria (out-of-band) para .NET 8 (v8.0.33), .NET 9 (v9.0.22) y .NET 10 (v10.0.14), además de un release candidate para .NET 11. La corrección aborda CVE-2026-111497, una falla de corrupción de memoria en la biblioteca de descompresión Brotli de Google, conocida también como Node2Shell o HTTP2Shell.

Esa doble denominación es en sí misma una señal. No se trata del bug de un solo proveedor. Vive en Brotli, un formato de compresión utilizado por Node.js, Python, Bun, Envoy y, ahora, por la pila de runtime de Microsoft. La vulnerabilidad permite que un atacante no autenticado lea o corrompa la memoria del proceso, lo que conduce a divulgación de información, denegación de servicio o escalada de privilegios.

Instalar el parche es la parte fácil. Entender quién sigue expuesto es donde se esconde el riesgo real.

Por qué esto no es solo una historia de .NET

La cobertura en japonés de Windows Magazine (窓の杜) enfatiza detalles operativos —números de versión, niveles de parcheo, instrucciones para reconstruir contenedores— que la prensa occidental ha sido más lenta en igualar. Esa brecha importa aquí porque HTTP2Shell es fundamentalmente un problema de cadena de suministro, no un problema del producto.

Brotli está integrado en la tubería de compresión de prácticamente todos los stacks web modernos. Un atacante que controle o intercepte el tráfico entre un cliente y un servidor con Brotli habilitado puede crear una carga útil comprimida maliciosa que active la corrupción de memoria. La misma falla apareció primero en Node.js, de ahí el nombre Node2Shell, pero no respeta los límites del runtime. Vive en la capa de descompresión, donde los cuerpos de las respuestas HTTP se desempaquetan antes de que el código de tu aplicación los vea.

La inclusión de actualizaciones de PowerShell junto con los parches de Visual Studio y el runtime de .NET sugiere que la organización reconoce que esto no está contenido. El hecho de que CVE-2026-114148 —una vulnerabilidad de metadatos de propiedad de tarballs específica de Linux que permite escalada de privilegios local— se parcheara en la misma ventana refuerza que la superficie de ataque de .NET va más allá de la sola biblioteca de compresión.

La trampa de lo autocontenido

Esto es lo que la mayoría de los cronologías de brecha pasarán por alto en los primeros días: el parche OOB solo ayuda a entornos que ejecutan el runtime compartido de .NET en el SO.

Si tu aplicación es autocontenida —es decir, el runtime de .NET viaja con el binario de la app en lugar de depender de la versión instalada en el sistema operativo—, instalar el runtime actualizado en la máquina anfitriona no hace nada. La app continúa usando su runtime empaquetado. Lo mismo aplica a los despliegues en contenedores que fijan una etiqueta específica de imagen .NET. Extraer una imagen base más nueva sin reconstruir y reimplantar deja la vulnerabilidad intacta.

Microsoft es claro al respecto. Las directrices indican que las organizaciones deben reconstruir y redistribuir las aplicaciones autocontenidas con el runtime actualizado. Los contenedores deben reconstruirse contra imágenes parcheadas. No puedes parchear tu salida de esto actualizando solo el sistema operativo anfitrión.

Esa distinción separa a las organizaciones que pasarán desapercibidas de las que no. Muchas empresas ejecutan cientos o miles de microservicios autocontenidos, cada uno compilado en momentos diferentes con versiones de runtime distintas. Solo el inventario es una tarea no trivial.

Estados predeterminados y riesgo oculto

Hay un aspecto positivo en la postura de Microsoft: la descompresión de solicitudes Brotli y la descompresión de respuestas están deshabilitadas de forma predeterminada en .NET. Si tu aplicación nunca habilitó explícitamente estas funciones, es probable que no seas vulnerable a la vía de descompresión de CVE-2026-111497.

Pero esa protección desaparece en el momento en que cualquier librería en tu árbol de dependencias llama directamente a la API Brotli de System.IO.Compression. Paquetes de terceros, incluso aquellos que no anuncian la compresión como una característica, pueden encaminar el tráfico a través de Brotli tras bambalinas —especialmente si manejan respuestas HTTP que fueron comprimidas por un CDN o equilibrador de carga upstream.

Aquí es donde la disciplina de auditoría importa. Ejecutar dotnet --list-runtimes te dirá si el SO anfitrión está parcheado. No te dirá si el código de tu aplicación o sus dependencias transitivas están haciendo llamadas directas a Brotli. Los desarrolladores necesitan revisar sus propios gráficos de dependencias.

Qué sigue

La Release Candidate 3 de .NET 11 ya está disponible, y Microsoft exhorta a los usuarios de RC2 a actualizar. Ese patrón —empujar a los primeros adoptantes hacia la última candidata— es práctica estándar cuando se disclose una vulnerabilidad crítica a mitad del ciclo de lanzamiento. Señala que la corrección se considera lo bastante estable para despliegue en producción en .NET 11, pero que la organización quiere sacar a la base de usuarios de RC3 de versiones candidatas más antiguas que pueden arrastrar otros problemas sin parchear.

Los parches simultáneos para CVE-2026-70197 (una falla de corrupción de memoria en SocketAsyncEventArgs de la actualización del 13 de octubre que estaba incompleta) y CVE-2026-102870 (un fallo en el depurador de Blazor WebAssembly) sugieren que el ciclo de actualizaciones de octubre de Microsoft ha sido bastante intenso. Dos vulnerabilidades previamente parcheadas requirieron correcciones de seguimiento en la misma ventana. Ese patrón eleva la probabilidad de que existan otros problemas en lanzamientos recientes que aún no han saltado a la vista.

La verdadera conclusión

HTTP2Shell es un recordatorio de que las bibliotecas de compresión son parte de tu perímetro de seguridad. Brotli, Deflate, GZIP: no son detalles de implementación. Son superficies de ataque.

El parche existe. Los números de versión están publicados. El trabajo más difícil consiste en responder: ¿cuáles de nuestros servicios usan despliegues autocontenidos? ¿Qué contenedores necesitan reconstrucción? ¿Qué bibliotecas de terceros llaman directamente a APIs Brotli? ¿Cuántas de nuestras instalaciones de .NET 8, 9 y 10 tienen runtimes que no han sido actualizados porque a nadie se le ocurrió verificar?

.NET Framework exclusivo para Windows no se ve afectado. Esa frontera está clara. Todo lo demás —y hay mucho de lo demás— necesita atención antes de que llegue el próximo exploit.