Microsoft ha publicado una actualización de seguridad fuera de su ciclo habitual para .NET 8, .NET 9 y .NET 10, además de .NET 11 Release Candidate 3. El aviso del 25 de octubre recomienda actualizar cuanto antes. Entre los problemas corregidos están un fallo en la descompresión Brotli y otro relacionado con los permisos de archivos distribuidos en determinados paquetes de Linux. Para los equipos que mantienen aplicaciones, el punto práctico es identificar qué runtime utiliza cada despliegue.
Los números de versión corregidos son 8.0.33, 9.0.22 y 10.0.14; quienes utilizan .NET 11 RC2 deben pasar a RC3. El anuncio oficial de Microsoft también explica que esta entrega completa dos correcciones de la actualización del 13 de octubre que no habían quedado resueltas íntegramente. Haber aplicado aquel paquete no sustituye la comprobación de estas versiones.
El alcance depende del código y del despliegue
El fallo de Brotli, identificado como CVE-2026-111497, puede permitir leer o corromper memoria del proceso cuando una aplicación descomprime datos afectados. Microsoft señala varias vías posibles, entre ellas la descompresión de solicitudes de ASP.NET Core y determinadas operaciones de HttpClient. Esas funciones no están activadas por defecto en los escenarios que detalla el aviso. No es correcto convertir la presencia de .NET en un servidor en la afirmación de que ha sido atacado.
La documentación del middleware de ASP.NET Core ayuda a localizar la descompresión de solicitudes dentro de la aplicación. Es una revisión de configuración y del camino que siguen los datos; no basta con observar que una web comprime las respuestas. El aviso distingue además .NET de .NET Framework, que no está afectado por este fallo de Brotli.
Por qué hay que revisar también contenedores y aplicaciones autónomas
Microsoft Learn diferencia los programas que utilizan un runtime instalado en el entorno de los que llevan el suyo incluido. En una aplicación dependiente del framework, actualizar el runtime correspondiente y reiniciar forma parte de la respuesta indicada. En una publicación autónoma, instalar una versión nueva en el servidor no reemplaza automáticamente la copia empaquetada dentro de la aplicación.
Consultar qué revisar según el modelo de publicación
| Modelo | Comprobación |
|---|---|
| Dependiente del framework | Runtime actualizado en el entorno y reinicio de la aplicación |
| Autónomo | Reconstruir y volver a publicar con el runtime corregido |
| Contenedor | Reconstruir la imagen y volver a desplegar |
La guía de publicación y la selección de versiones explican esa separación. También conviene revisar los entornos de construcción: corregir una máquina y seguir distribuyendo una imagen antigua mantendría una copia anterior del runtime. La verificación debe hacerse sobre lo que ejecuta realmente cada aplicación.
El criterio coincide con la explicación de TodoWeb sobre las vulnerabilidades críticas de PHP: identificar producto y versión antes de actuar, y comprobar después la actualización efectiva. Más avisos y contexto en Tecnología.
Fuentes
- Actualizaciones de seguridad extraordinarias de octubre — Microsoft .NET Blog, 2026-10-25
- Modelos de publicación de aplicaciones .NET — Microsoft Learn
- Descompresión de solicitudes en ASP.NET Core — Microsoft Learn
- Selección de la versión de .NET — Microsoft Learn
Elaborado por la redacción de TodoWeb con asistencia de inteligencia artificial a partir de las fuentes enlazadas. ¿Has visto un error? Escríbenos desde correcciones.
