Microsoft parchea .NET y PowerShell por Brotli

Un parche en domingo cuesta dinero. Hay que movilizar guardias, ingenieros de soporte y equipos de despliegue fuera de horario, y las empresas solo lo aceptan cuando esperar al martes sale más caro que romper el fin de semana. Microsoft lo hizo ayer con las versiones 8.0.33, 9.0.22, 10.0.14 y la RC3 de la 11, todas del framework .NET y todas publicadas fuera de banda según la nota de la entrega, para tapar un desbordamiento de búfer en el decodificador Brotli que el framework lleva dentro.

El fallo se registra como CVE-2026-111497 y permite que un atacante sin credenciales lea o corrompa la memoria del proceso, lo que puede derivar en filtración de datos, caída del servicio o escalada de privilegios, tal como recoge el aviso de dotnet/runtime. No es una novedad aislada: es el mismo defecto que obligó a Node.js a publicar versiones nuevas el miércoles 21, y el caso .NET Brotli añade su propia vuelta de tuerca porque Microsoft califica el impacto de forma más tibia que el resto del ecosistema.

La vía de entrada no es el framework en abstracto, sino tres rutas de descompresión muy concretas: la descompresión de peticiones de ASP.NET Core, la descompresión automática de respuestas de HttpClient y las API de Brotli de System.IO.Compression. Las dos primeras no vienen activadas por defecto, lo que reduce el universo expuesto sin anularlo. Quien haya tocado esas opciones tiene trabajo este lunes.

De un bloque inválido a un búfer de ocho bytes

El defecto no nació en Redmond. Vive en Google Brotli, la biblioteca que usan casi todos los servidores web para servir contenido con `Content-Encoding: br`, y arranca en un error de gestión de estado al leer el flujo comprimido.

Un flujo mal formado puede declarar un cambio de tipo de bloque que su propia estructura invalida. El decodificador lo interpretaba como una petición de más entrada y seguía escribiendo en un búfer interno de ocho bytes, según el análisis técnico del fallo.

Las versiones afectadas van de la 1.0.3 a la 1.2.0, y el arreglo upstream llegó en 1.0.10, 1.1.1 y 1.2.1. La puntuación pública del CVE es 9.2 sobre 10 en CVSS v4, con un requisito de ataque nada trivial: el atacante tiene que controlar los datos comprimidos que alcanzan el decodificador.

Microsoft califica el caso como alto y describe el impacto como escalada de privilegios antes que ejecución remota de código, una diferencia de criterio que conviene tener presente: el fallo .NET Brotli se prioriza por lo que permite, no por la etiqueta que reciba.

La comparación con la semana pasada se impone. El fallo crítico de PHP pasó a la historia reciente como php2shell y este lo repite con otra pieza: nadie instala Brotli a mano, porque llega escondido dentro del runtime que ya usas, del contenedor que despliegas o del paquete que declaras como dependencia. Ese es el motivo de que un CVE de biblioteca termine convertido en cuatro releases de framework un domingo cualquiera.

¿Qué cambia en cada versión?

El paquete es corto en número de ramas y largo en consecuencias. Cuatro líneas de producto reciben runtime nuevo, y dos de ellas están a dos semanas de quedarse sin soporte, así que la decisión de qué instalar este lunes condiciona también la migración que viene después.

El segundo CVE de la lista casi pasa desapercibido y es el que más incomoda a quien empaqueta. CVE-2026-114148 afecta a los metadatos de propiedad de los tarballs para Linux, donde unos permisos mal puestos dejan que un atacante local modifique ficheros y gane privilegios. Las ramas 8 y 9 lo heredan en las distribuciones de ASP.NET Core repartidas como tarball, incluso entre quien no compila el framework desde el código fuente. Descargar el archivo nuevo no corrige por sí solo una instalación que ya existe.

Los dos avisos que vuelven a la lista

Reaparecer es la parte incómoda del domingo. Dos avisos que se arreglaron el 13 de octubre vuelven a la lista porque aquella entrega no cerraba del todo ninguno de ellos: CVE-2026-70197, corrupción de memoria en SocketAsyncEventArgs, y CVE-2026-102870, ejecución remota a través del depurador de Blazor WebAssembly.

La nota de la actualización de .NET 10 admite que esta nueva entrega corrige además el empaquetado de BrowserDebugHost, que era lo que faltaba para que el parche del depurador funcionase de verdad sobre instalaciones reales.

Para quien ya aplicó el martes 13, la consecuencia práctica es que tiene que volver a actualizar: la recomendación oficial es instalar esta entrega aunque el parche mensual esté puesto. Ese detalle explica también la insistencia en reiniciar procesos.

Un runtime nuevo en disco no cambia la memoria de un proceso que lleva días corriendo con las bibliotecas viejas cargadas. En un servidor ASP.NET Core, eso puede significar reciclar el pool de aplicaciones o el contenedor entero durante la madrugada.

¿Por qué el runtime instalado no salva a todos?

La regla que más trabajo da es la de las aplicaciones autocontenidas. Al publicar con `–self-contained`, el ejecutable se lleva su propia copia del runtime y de Brotli; instalar el 8.0.33 en la máquina no sustituye nada dentro de esa carpeta, así que el binario sigue expuesto hasta que alguien lo recompile.

Con NativeAOT ocurre lo mismo en peor versión, porque el decodificador queda enlazado dentro del ejecutable y ni siquiera existe un fichero que puedas reemplazar, como detalla la guía de publicación. Los contenedores caen en el mismo saco cuando la imagen fija una etiqueta concreta: hay que reconstruir y redesplegar.

Y luego está PowerShell, que da sentido al titular. Cada versión mayor se construye sobre una versión distinta de .NET, y las instalaciones autocontenidas copian el runtime en su propio directorio, de modo que tapar el fallo pasa por subir de versión de PowerShell, según la relación entre versiones. Windows PowerShell 5.1 se libra porque corre sobre .NET Framework, el mismo que el aviso deja fuera.

Hay que sumar imágenes de contenedor, artefactos publicados en repositorios internos y binarios sueltos que cargan su propio runtime dentro. Esa lista casi nunca está en un único sitio ni tiene dueño claro, y ahí el caso .NET Brotli deja de ser una descarga para convertirse en un trámite de despliegue.

Quince días para las ramas 8 y 9

Hay un reloj que corre en paralelo y no depende de este CVE. La rama 8 y la rama 9 dejan de tener soporte el 10 de noviembre de 2026, así que estas 8.0.33 y 9.0.22 están entre las últimas entregas que van a ver, de acuerdo con el calendario de soporte.

Para una empresa que todavía no ha migrado, el parche del domingo es una excusa razonable para no invertir en una rama que caduca en dos semanas y saltar a la versión 10, con soporte hasta noviembre de 2028. El salto no es gratis, porque hay que revisar paquetes y probar la serialización.

Aun así, sostener dos ramas a la vez sale más caro que planificar una migración con fecha, y los parches fuera de banda existen justamente porque el calendario no admite atrasos. Una rama en mantenimiento solo recibe parches de seguridad.

Un domingo que cuesta más que un martes

La entrega fuera de banda se mide por lo que evita, no por lo que publica. No hay indicios públicos de explotación real, y el estado del fallo en el ecosistema Node es el de una prueba de concepto funcional sin campaña confirmada hasta hoy. El cálculo depende de cada casa: quien descomprime Brotli de terceros en un servicio expuesto tiene una ventana corta, y quien solo sirve ficheros estáticos con otro servidor puede respirar.

La disciplina de parchear es más una rutina que una alerta, y conviene tratarla como una revisión semanal, igual que se repasa la actualidad en las claves de la semana del 23 de octubre.

Con dos ramas caducando en quince días, el trabajo pendiente ya no consiste solo en instalar cuatro números nuevos, sino en decidir en qué versión va a vivir el código el año que viene, y esa decisión no la resuelve ningún parche de domingo.