.NET: actualizaciones de servicio de septiembre de 2026, versiones y checklist

Microsoft publicó el 8 de septiembre de 2026 las actualizaciones de servicio de .NET y .NET Framework. Para las ramas modernas de .NET, las versiones anunciadas son 10.0.12, 9.0.20 y 8.0.31. La actualización contiene correcciones de seguridad y otras correcciones de mantenimiento.

Para un equipo backend, la tarea no consiste solo en cambiar un número en el pipeline. Hay que identificar el runtime que se ejecuta realmente, revisar el alcance de las correcciones, reconstruir los artefactos y comprobar que autenticación, serialización, bases de datos y despliegues continúan funcionando.

TL;DR

• .NET 10 recibe la versión 10.0.12; .NET 9, la 9.0.20; y .NET 8, la 8.0.31.
• Microsoft enumera ocho CVE corregidos en la actualización. El anuncio no sustituye las fichas de Microsoft Security Response Center (MSRC) ni asigna por sí solo una severidad o una condición de explotación.
• Actualiza primero en una rama, imagen o entorno de staging. Ejecuta restore, compilación, pruebas y un despliegue de humo antes de cambiar producción.
• .NET 10 es la rama LTS recomendada por Microsoft para nuevos ciclos de soporte; .NET 8 y .NET 9 tienen fin de soporte previsto para el 10 de noviembre de 2026.
• La comprobación final de este artículo se realizó el 9 de septiembre de 2026. Confirma las páginas oficiales antes de actuar porque pueden aparecer revisiones posteriores.

Versiones publicadas

Esta es la correspondencia que aparece en el anuncio oficial de Microsoft:

Rama	Actualización de septiembre	Uso que debes comprobar
.NET 10	10.0.12	Runtime, ASP.NET Core, Desktop Runtime, SDK y contenedores
.NET 9	9.0.20	Runtime, ASP.NET Core, Desktop Runtime, SDK y contenedores
.NET 8	8.0.31	Runtime, ASP.NET Core, Desktop Runtime, SDK y contenedores

El número del runtime no siempre es el mismo que el del SDK. Por ejemplo, la página de descargas consultada para .NET 10 muestra el SDK 10.0.401 y los runtimes 10.0.12 incluidos. Usa la descarga correspondiente a tu sistema operativo y arquitectura; no copies un identificador de Windows x64 a un runner Linux o ARM sin comprobarlo.

Las imágenes de contenedor y los paquetes Linux tienen sus propios canales de publicación. Una aplicación puede ejecutarse con una imagen base actualizada aunque el SDK del equipo de desarrollo sea diferente, o puede compilar con un SDK actualizado y seguir desplegándose sobre una imagen antigua. Registra ambos datos en CI y en el inventario de producción.

Qué corrige la actualización

El anuncio de Microsoft separa las correcciones de .NET de las de .NET Framework y enlaza las notas de ASP.NET Core, Entity Framework Core y Runtime. Para las ramas .NET 8, .NET 9 y .NET 10, enumera estos ocho identificadores:

• CVE-2026-69805
• CVE-2026-69439
• CVE-2026-71328
• CVE-2026-69522
• CVE-2026-69304
• CVE-2026-58649
• CVE-2026-66822
• CVE-2026-69806

La publicación de Microsoft identifica cada CVE como una vulnerabilidad de seguridad de .NET y especifica las ramas afectadas. No asigna en esa tabla una severidad, puntuación CVSS, explotación activa ni un requisito de configuración. Por eso, este artículo no infiere esas propiedades: consulta la ficha individual de MSRC y compárala con los componentes que usa tu aplicación.

La tabla del anuncio indica que CVE-2026-69522 también aplica a .NET Framework 4.6.2, 4.7, 4.7.1, 4.7.2, 4.8 y 4.8.1. Los otros identificadores de esta lista aparecen asociados a .NET 8, 9 y 10. Si mantienes una aplicación .NET Framework, revisa además las notas específicas de Windows Update y el historial oficial de actualizaciones de .NET Framework.

¿Debo actualizar de inmediato?

En un servicio expuesto a Internet, las correcciones de seguridad justifican priorizar la evaluación. “Priorizar” no significa desplegar sin pruebas: significa identificar rápidamente los artefactos afectados, comprobar las fichas de MSRC y preparar una actualización reversible.

También importa el ciclo de soporte. Microsoft indica que .NET 10 es LTS y tiene soporte hasta noviembre de 2028. .NET 8 y .NET 9 tienen fin de soporte el 10 de noviembre de 2026, aunque una migración de versión mayor no debería mezclarse automáticamente con un parche de mantenimiento. Primero aplica el parche de tu rama compatible; después planifica la migración con sus propias pruebas y criterios de rollback.

La decisión debe considerar:

• si el proceso corre sobre .NET 8, 9 o 10, y no solo el TargetFramework del repositorio;
• si la aplicación usa ASP.NET Core, EF Core, autenticación, TLS, serialización JSON o librerías nativas;
• si la imagen final se reconstruye desde una etiqueta mutable o desde un digest fijado;
• si existe una ventana de cambio, una copia de seguridad y una forma probada de volver al artefacto anterior.

Checklist para actualizar sin perder trazabilidad

1. Inventariar lo que está en ejecución

Antes de cambiar archivos de proyecto, registra el runtime y el SDK que usa cada entorno:

dotnet --info
dotnet --list-sdks
dotnet --list-runtimes

En contenedores, comprueba también la etiqueta o digest de la imagen base. Guarda la salida como artefacto de CI para poder relacionar una incidencia con una versión concreta.

2. Revisar dependencias y CVE

Lee el anuncio de servicio de septiembre y las ocho fichas de MSRC. Después revisa las notas de ASP.NET Core, EF Core y Runtime de la rama correspondiente.

No asumas que un paquete de NuGet aislado actualiza el runtime del servidor. Los paquetes, el SDK, el runtime y la imagen de contenedor son piezas relacionadas, pero se actualizan por canales distintos.

3. Actualizar una rama o entorno aislado

Actualiza el SDK mediante la página oficial de descargas de .NET y fija la versión en global.json cuando el proyecto lo requiera. El valor exacto depende del SDK disponible para el sistema operativo y la arquitectura del runner.

Después, actualiza la imagen base o el runtime instalado en staging. Evita probar contra latest si necesitas reproducibilidad; fija una versión concreta y documenta el cambio.

4. Compilar y ejecutar pruebas

Un mínimo razonable para una solución .NET es:

dotnet restore
dotnet build --configuration Release
dotnet test --configuration Release --no-build

Adapta --no-build a tu solución. Añade pruebas de humo para:

• arranque, apagado y health checks;
• autenticación y autorización;
• consultas y migraciones de base de datos;
• serialización y deserialización de contratos JSON;
• llamadas HTTP salientes, TLS y resolución DNS;
• trabajos en segundo plano y colas;
• generación de logs, métricas y trazas;
• publicación y ejecución de la imagen final.

Compara errores, latencia, memoria, tamaño de imagen y tiempo de arranque con el artefacto anterior. Si una métrica cambia, captura el escenario y no atribuyas automáticamente la diferencia a una CVE o a una mejora del parche.

5. Desplegar con rollback preparado

Promueve primero a un entorno pequeño o a un despliegue gradual. Conserva el artefacto anterior, la configuración compatible y las migraciones de base de datos separadas de la actualización del runtime. Define de antemano qué métrica detiene la promoción y cómo volver a la versión anterior.

Tras el cambio, vuelve a ejecutar dotnet --info dentro del proceso o contenedor y registra la versión observada. Comprueba que el servicio no está resolviendo una etiqueta antigua por caché del nodo.

Seguridad y limitaciones

Un parche de mantenimiento no sustituye un análisis de seguridad de la aplicación. La presencia de un CVE en el anuncio no demuestra que tu despliegue sea vulnerable, y la ausencia de una configuración mencionada en la tabla no demuestra que esté fuera de riesgo. El impacto depende de la rama, componente, configuración, sistema operativo y forma de exposición.

No incluyas secretos, cadenas de conexión ni datos personales en los logs de dotnet --info o en los artefactos de CI. Revisa también los permisos del pipeline y de los registros de contenedores antes de compartir resultados.

Si tu organización necesita una evaluación formal, usa la ficha de MSRC de cada CVE, el inventario de componentes y el procedimiento interno de gestión de vulnerabilidades. La recomendación de este artículo es operativa: comprobar, probar, actualizar y conservar rollback.

Conclusión

Las versiones 10.0.12, 9.0.20 y 8.0.31 son las actualizaciones de servicio de .NET anunciadas para septiembre de 2026. La prioridad correcta es conocer qué versión ejecuta cada entorno, revisar los ocho CVE en sus fuentes oficiales y validar el artefacto completo antes de promoverlo.

Si usas .NET 8 o .NET 9, incorpora además su fecha de fin de soporte del 10 de noviembre de 2026 a la planificación. El parche de septiembre resuelve mantenimiento inmediato; la migración a otra rama es una decisión separada que debe tener su propio plan.

Fuentes oficiales consultadas

• Actualizaciones de servicio de .NET y .NET Framework de septiembre de 2026 — Microsoft, 8 de septiembre de 2026.
• Descargas de .NET 10 — versión 10.0.12 y SDK 10.0.401 observados el 9 de septiembre de 2026.
• Todas las versiones de .NET — estado de soporte y últimas versiones.
• Fin de soporte de .NET 8 y .NET 9 — Microsoft.
• Guía de actualizaciones de seguridad de Microsoft (MSRC) — fichas individuales enlazadas en el artículo.

Nota editorial: Esta publicación refleja las fuentes consultadas el 9 de septiembre de 2026. Confirma las versiones, notas de seguridad y fichas de MSRC antes de actualizar un entorno de producción; los números y el estado de soporte pueden cambiar con nuevas publicaciones.