Microsoft lanza parche urgente para .NET por fallo Brotli

Qué pasó con el parche urgente de .NET

Microsoft publicó actualizaciones de seguridad fuera de calendario (out-of-band) para .NET 8, .NET 9, .NET 10 y la Release Candidate 3 de .NET 11. El motivo principal es CVE-2026-111497, un desbordamiento de búfer en el uso que hace .NET del algoritmo de descompresión Brotli.

Según el aviso de Microsoft recogido por BleepingComputer, un atacante sin autenticar puede usar un flujo comprimido malicioso para provocar caídas, fugas de memoria y, en algunos casos, ejecución remota de código. La compañía recomienda instalar las actualizaciones cuanto antes.

Google, que asignó el CVE, califica el fallo con 9.2 sobre 10 en el registro oficial, según The Next Web. Microsoft lo marca como crítico para .NET y Visual Studio, e importante para PowerShell.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Qué versiones de .NET hay que instalar?

El paquete de correcciones trae una actualización por cada línea soportada:

.NET 8: 8.0.33
.NET 9: 9.0.22
.NET 10: 10.0.14
.NET 11: Release Candidate 3. Quien esté en la RC2 debe pasar a la RC3.

¿Quién está realmente expuesto al fallo de Brotli?

Las aplicaciones afectadas son las que procesan datos comprimidos con Brotli por tres vías: la descompresión de peticiones de ASP.NET Core, la descompresión automática de respuestas de HttpClient o las API de Brotli de System.IO.Compression.

Microsoft precisa que las dos primeras no vienen activadas por defecto y que .NET Framework no está afectado. Es decir, el riesgo no es universal: depende de si tu aplicación descomprime datos que controla un tercero.

El fallo no es solo de Microsoft: Node.js, Python y Google

Node.js divulgó la vulnerabilidad el 21 de octubre de 2026 junto con parches para sus líneas 22.x, 24.x y 26.x (versiones 22.23.4, 24.22.1 y 26.12.1), según CSO Online. El problema se originó en el decodificador Brotli que Node.js empaqueta. La firma Imperva lo bautizó Node2Shell; también circula como HTTP2Shell y Broccoli2Shell.

Los investigadores Khai Tran y Sylvie Mayer, del equipo Codex Security de OpenAI, reportaron el fallo. OpenAI señaló que la causa raíz se había corregido en el código fuente de Brotli en febrero, pero en ese momento no se sabía que daba lugar a una vulnerabilidad de seguridad y no hubo una nueva release.

Google publicó versiones corregidas de su librería Brotli (1.0.10, 1.1.1 y 1.2.1) y los paquetes de Python Brotli 1.2.1 y brotlicffi 1.2.1.0 también recibieron parches, según CSO Online.

¿Qué tan grave es? Los datos del ecosistema

Wiz, firma de seguridad en la nube, afirma que el 91% de los entornos cloud tienen recursos vulnerables al fallo y que el 82% tienen instancias de Node.js expuestas públicamente, según The Next Web. JFrog encontró el fallo también en FFmpeg, ClickHouse y Apache Arrow, reportó The Hacker News.

Hasta la fecha no hay reportes de explotación en el mundo real, aunque ya existe código de prueba de concepto publicado en GitHub.

El parche que repara parches anteriores

Microsoft reconoce que dos correcciones del Patch Tuesday del 13 de octubre no resolvieron del todo sus fallos. Vuelve a publicar los avisos de CVE-2026-70197 (corrupción de memoria en SocketAsyncEventArgs, .NET 8-11) y CVE-2026-102870 (inyección de código en el depurador de Blazor WebAssembly, .NET 10 y 11). Las actualizaciones de ahora incluyen esas correcciones.

Ese Patch Tuesday de octubre batió un récord: 1.413 CVE corregidos, un 45% más que el máximo anterior de 974 en septiembre, según TheCyberExpress. Redmond Mag atribuye parte del volumen al uso creciente de IA para encontrar vulnerabilidades más rápido de lo que los humanos pueden.

El segundo arreglo: solo para Linux

El paquete incluye CVE-2026-114148, exclusivo de Linux. Algunos archivos tarball de .NET llevaban metadatos de propiedad inseguros, lo que podría permitir a un atacante local modificar archivos y ganar privilegios.

En .NET 10 y 11 afecta solo a los tarball de source-build. En .NET 8 y 9 afecta también a quien instaló ASP.NET Core desde sus tarball, aunque no compile .NET desde el código fuente.

¿Qué significa esto para tu startup?

Si mantienes servicios en .NET, este es el momento de mirar qué corre de verdad en producción, no solo qué versión crees que tienes instalada.

Revisa hoy si algún servicio descomprime Brotli de clientes externos. Esos son los primeros que hay que actualizar. Usa dotnet --list-runtimes en cada máquina para ver qué hay instalado realmente.
No te quedes en instalar el runtime. Las aplicaciones self-contained llevan su propio runtime empaquetado: hay que recompilarlas y volver a publicarlas. Los contenedores hay que reconstruirlos con las imágenes actualizadas. Solo las framework-dependent se arreglan instalando el runtime y reiniciando la aplicación.
Si no puedes parchear de inmediato, bloquea las peticiones comprimidas con Brotli usando un proxy o firewall, o desactiva la decodificación Brotli hasta que puedas aplicar el parche.
Ojo con las copias empaquetadas. Actualizar la librería Brotli del sistema no arregla las apps que incluyen su propia copia de la librería, como advierte el tracker público del fallo.

La lección de fondo es la misma que con un servidor que ejecuta una versión de PHP sin actualizar aunque WordPress esté al día: lo que importa es la capa que de verdad corre en producción. Un parche urgente que además repara parches anteriores es la mejor razón para no dar por cerrado un aviso de seguridad solo porque ya instalaste algo.

Conclusión

CVE-2026-111497 es un recordatorio de que las dependencias de compresión, esas que rara vez miramos, pueden convertirse en la puerta de entrada de un ataque. La ventana de exposición es corta: ya hay prueba de concepto pública, aunque todavía no se ha visto explotación real.

Para un equipo pequeño, la prioridad es clara: identificar qué servicios descomprimen datos de terceros, actualizar runtime y artefactos, y reconstruir lo que esté empaquetado. Media hora de inventario hoy puede ahorrar un incidente mañana.