28 octubre 2026
Noticias, Seguridad
3 minutos de lectura

Microsoft lanza parches urgentes de .NET para el fallo crítico HTTP2Shell

Antonio

Microsoft ha publicado actualizaciones de emergencia de .NET para corregir HTTP2Shell (CVE-2026-111497), el fallo crítico del decodificador Brotli, y recomienda instalarlas cuanto antes: .NET 8.0.33, 9.0.22, 10.0.14 y 11 RC3. Para quien ejecuta .NET en la nube, contenedores o Kubernetes, actualizar el runtime del servidor no es suficiente: las aplicaciones autocontenidas y las imágenes de contenedor tienen que reconstruirse.

Las claves del parche de .NET para HTTP2Shell en 20 segundos

Microsoft publicó el 25 de octubre .NET 8.0.33, 9.0.22, 10.0.14 y 11 RC3.
Afecta a aplicaciones que descomprimen datos Brotli no fiables; no está activo por defecto.
Las aplicaciones autocontenidas, NativeAOT y los contenedores deben reconstruirse.
Hay pruebas de concepto públicas y la CISA lo considera explotado.

El fallo, una escritura fuera de límites en la biblioteca Brotli de Google, puede provocar caídas, fugas de memoria y, en algunos casos, ejecución remota de código. Opensecurity explica en detalle cómo HTTP2Shell afecta a .NET, ClickHouse y Apache Arrow por incluir copias propias de Brotli. El runtime de .NET llevaba integrada la versión 1.1.0, y Microsoft publicó sus versiones corregidas fuera de ciclo el 25 de octubre, según BleepingComputer y Brandefense. .NET Framework no está afectado.

Qué aplicaciones .NET están expuestas

Según Microsoft, la descompresión Brotli no está activada por defecto en una instalación estándar de .NET o ASP.NET Core, así que la exposición depende de cada aplicación. Están en riesgo las que procesan datos Brotli no fiables mediante:

La descompresión de peticiones de ASP.NET Core.
La descompresión automática de respuestas en HttpClient.
Las API de Brotli de System.IO.Compression, como BrotliDecoder y BrotliStream.

Los dos vectores son simétricos: un servidor que acepta peticiones con Content-Encoding br, o un cliente que descarga una respuesta comprimida desde un servidor malicioso o comprometido. En arquitecturas de microservicios, donde un servicio llama a otro y a API externas, el segundo caso es tan relevante como el primero.

Cómo parchear en servidores, contenedores y Kubernetes

El primer paso es inventariar qué runtimes hay instalados en cada máquina:

dotnet --list-runtimes

Después de actualizar, hay que reiniciar los procesos para que carguen el nuevo runtime. Las aplicaciones publicadas como autocontenidas o con NativeAOT llevan su propio runtime dentro, de modo que no se corrigen al actualizar el servidor: hay que recompilarlas y desplegarlas de nuevo. Lo mismo ocurre con las imágenes de contenedor, que deben reconstruirse sobre una imagen base corregida y volver a desplegarse en los clústeres, y con los entornos de compilación y las canalizaciones de CI/CD que generan esos artefactos.

Si el parche no puede aplicarse de inmediato, las medidas provisionales son bloquear en el proxy o el WAF las peticiones comprimidas con Brotli o desactivar su descompresión en la aplicación. Azure WAF incluye una regla, la 920450, que bloquea por defecto las peticiones manipuladas analizadas, y Cloudflare ha publicado reglas de emergencia que por defecto solo registran. Ninguna de estas medidas protege a una aplicación cliente que descarga una respuesta maliciosa, así que no sustituyen a la actualización. Hay pruebas de concepto públicas y la CISA incluyó el fallo en su catálogo de vulnerabilidades explotadas el 27 de octubre.

Preguntas frecuentes

¿Qué versiones de .NET corrigen HTTP2Shell?

.NET 8.0.33, 9.0.22, 10.0.14 y .NET 11 RC3. .NET Framework no está afectado.

¿Está mi aplicación .NET expuesta?

Solo si descomprime datos Brotli no fiables con la descompresión de peticiones de ASP.NET Core, HttpClient o las API Brotli de System.IO.Compression; no está activo por defecto.