Fallo crítico en ASP.NET Core y cómo proteger tus aplicaciones

En los últimos tiempos, ASP.NET Core se ha visto sacudido por varios fallos críticos de seguridad que afectan directamente a la autenticación, la protección de datos y al propio servidor web Kestrel. Si desarrollas o mantienes aplicaciones sobre .NET, esto no es una simple anécdota técnica: hablamos de vulnerabilidades con puntuaciones CVSS altísimas (9,1 e incluso 9,9), capaces de abrir la puerta a escaladas de privilegios, suplantaciones de usuario y exposición de información muy sensible.

Más allá del ruido de los boletines de seguridad, es clave entender qué está fallando exactamente en ASP.NET Core, qué paquetes y versiones están afectados, y cómo debe reaccionar un equipo de desarrollo moderno que trabaje con CI/CD y buenas prácticas DevSecOps, como IDE y herramientas clave para testear aplicaciones. Vamos a desgranar los casos más graves (incluyendo CVE-2026-40372 y CVE-2025-55315), revisar las medidas de mitigación recomendadas por Microsoft y repasar de paso el modelo de manejo de errores y excepciones en ASP.NET Core, porque una brecha de seguridad sin buen observability es como buscar una aguja en un pajar.

Vulnerabilidad crítica en DataProtection: CVE-2026-40372

Una de las incidencias más delicadas que ha golpeado el ecosistema es CVE-2026-40372, una vulnerabilidad crítica en Microsoft.AspNetCore.DataProtection, parcheada por Microsoft con una actualización fuera de ciclo en la versión .NET 10.0.7. La gravedad no es menor: CVSS 3.1 de 9,1 (Crítica) y explotación remota sin autenticación.

Esta vulnerabilidad afecta a las versiones 10.0.0 a 10.0.6 del paquete NuGet Microsoft.AspNetCore.DataProtection y a dependencias relacionadas, como Microsoft.AspNetCore.DataProtection.StackExchangeRedis. El problema radica en un fallo muy sutil pero devastador en la lógica criptográfica del cifrador autenticado administrado de ASP.NET Core.

El componente vulnerable calcula el tag HMAC de validación sobre los bytes equivocados del payload y, en determinados casos, llega incluso a descartar el hash generado. Esta validación defectuosa rompe por completo el modelo de confianza esperado: un atacante puede construir payloads que aparentan ser legítimos, saltándose las comprobaciones de autenticidad del sistema de protección de datos.

Las consecuencias prácticas son especialmente graves, porque DataProtection no solo se usa para cifrar datos arbitrarios, sino que está en el centro de muchos mecanismos de seguridad de ASP.NET Core: cookies de autenticación, tokens antifalsificación, TempData, estado OIDC y otros elementos que dependen de este anillo de claves. Si estos objetos pueden falsificarse o descifrarse, el atacante tiene una vía muy directa a la escalada de privilegios.

Impacto real: cookies, tokens e identidad comprometida

El fallo en DataProtection permite a un atacante forjar payloads que pasan las comprobaciones criptográficas y, en algunos escenarios, incluso descifrar datos protegidos con anterioridad. En entornos donde se usan las APIs de Protection de ASP.NET Core, esto se traduce en un abanico de ataques muy preocupante.

Entre los datos potencialmente expuestos se encuentran cookies de autenticación, tokens antiforgery, TempData, estado OIDC y otros tokens internos. En el peor de los casos, un atacante no autenticado podría fabricarse una cookie o un token que le identifique como un usuario con privilegios elevados, por ejemplo un administrador de la aplicación o un servicio interno.

El escenario se agrava porque, si durante la ventana vulnerable el atacante logra obtener un nivel de acceso elevado, puede inducir a la aplicación a emitir activos legítimos pero maliciosamente obtenidos: API keys, tokens de actualización de sesión, enlaces de restablecimiento de contraseña o claves de acceso persistentes. Todos esos artefactos seguirían siendo válidos incluso después de actualizar a .NET 10.0.7, a menos que se tomen medidas complementarias.

En otras palabras, aunque apliques el parche, si no reaccionas correctamente, tu sistema podría seguir expuesto a tokens ya emitidos bajo condiciones comprometidas. Por eso Microsoft compara este fallo con vulnerabilidades históricas como MS10-070, relacionadas con problemas de padding-oracle en el cifrado legacy de ASP.NET.

Microsoft descubrió esta regresión a raíz de reportes de clientes que experimentaban fallos de desencriptado tras instalar .NET 10.0.6 durante el Patch Tuesday de abril. Al investigar el incidente (documentado inicialmente en el issue #66335 de aspnetcore), el equipo detectó que no solo se trataba de un bug funcional, sino de un agujero de seguridad importante que exigía un parche urgente fuera de ciclo.

Condiciones de explotación y entornos afectados

Aunque el fallo es crítico, no todos los entornos quedan expuestos por defecto. Según la información oficial, para explotar CVE-2026-40372 deben cumplirse varias condiciones concretas relacionadas con paquetes y entorno de ejecución.

Por un lado, la aplicación debe estar utilizando las versiones vulnerables del paquete Microsoft.AspNetCore.DataProtection (10.0.0 a 10.0.6) o librerías que lo carguen en tiempo de ejecución. Además, la vulnerabilidad tiene un mayor impacto en sistemas operativos no Windows, como Linux y macOS, lo que encaja de lleno con el tipo de despliegue habitual de ASP.NET Core en contenedores, orquestadores y plataformas cloud.

El vector de ataque se ejecuta normalmente a través de la red, sin necesidad de autenticación previa, lo que multiplica su peligrosidad en aplicaciones expuestas a Internet. El atacante puede enviar payloads especialmente diseñados como si fuera un cliente más del sistema, sin requerir credenciales válidas.

En la práctica, esto significa que infraestructuras basadas en microservicios, contenedores Docker y plataformas PaaS que se apoyen en DataProtection para compartir claves o estado de autenticación entre instancias son objetivos prioritarios. Si no se ha parcheado y rotado el anillo de claves, hay un riesgo real de que un compromiso puntual se convierta en un acceso persistente difícil de detectar.

Por todo lo anterior, los equipos de seguridad de aplicaciones tienen que analizar con detalle qué servicios cargan el paquete vulnerable y en qué sistemas operativos se ejecutan, en lugar de asumir que el problema solo afecta a escenarios muy concretos.

Acciones urgentes: actualización a .NET 10.0.7 y rotación de claves

La principal recomendación de Microsoft es clara: actualizar inmediatamente el paquete Microsoft.AspNetCore.DataProtection a la versión 10.0.7 y recompilar las aplicaciones con los runtimes y SDK corregidos (por ejemplo, .NET SDK 10.0.203 y sus runtimes asociados).

Para confirmar que el entorno está correctamente actualizado, se debe ejecutar dotnet –info y verificar que la versión de runtime es la 10.0.7 correspondiente. No basta con instalar el runtime en el servidor; es imprescindible reconstruir y redeplegar las aplicaciones utilizando las imágenes de contenedor o paquetes actualizados, para asegurarse de que el código en producción enlaza contra los binarios corregidos.

Sin embargo, como ya se ha adelantado, aplicar el parche no soluciona por sí mismo los posibles daños ya ocasionados. Microsoft aconseja encarecidamente rotar el anillo de claves de DataProtection en los entornos que hayan estado expuestos, con el fin de invalidar cualquier token, cookie o credencial generada maliciosamente durante la ventana de vulnerabilidad.

Además de la actualización y la rotación de claves, resulta prudente forzar el cierre de sesiones activas (revocación de cookies de login, tokens de acceso, etc.), exigir reautenticaciones y activar una auditoría detallada de logs para revisar actividades sospechosas, sobre todo accesos administrativos atípicos, creación de claves API, restablecimientos de contraseña y operaciones privilegiadas.

Desde una perspectiva de DevSecOps, este incidente refuerza la importancia de incorporar escáneres de dependencias en la cadena CI/CD y de habilitar alertas automáticas cuando aparezcan vulnerabilidades críticas en paquetes de terceros. Con DataProtection sucede como con cualquier librería criptográfica: un pequeño cambio de comportamiento puede desmoronar todo el modelo de seguridad si no se valida con rigor.

Otro fallo crítico: suplantación de solicitudes HTTP en Kestrel (CVE-2025-55315)

Además de la vulnerabilidad en DataProtection, se ha reportado otro fallo de seguridad extremadamente grave en ASP.NET Core, esta vez centrado en el servidor web Kestrel. Identificado como CVE-2025-55315, se ha catalogado como un error de suplantación de solicitudes HTTP con una puntuación de severidad de 9,9 sobre 10.

El núcleo del problema está en que un atacante puede inyectar una segunda solicitud HTTP maliciosa dentro de una petición aparentemente legítima, algo típico de los llamados ataques de request smuggling o de manipulación de framing HTTP. Esta técnica puede servir para eludir controles de seguridad ubicados en proxies, balanceadores o el propio servidor, y conseguir que el backend procese datos que nunca debió aceptar.

Según el aviso de Microsoft, el impacto potencial pasa por acceso a información sensible, robo de credenciales, modificación no autorizada de archivos e incluso la posibilidad de provocar fallos en el servidor que afecten a la disponibilidad. Al tocar directamente la capa de transporte HTTP, el abanico de ataques es muy amplio, desde saltarse autenticaciones hasta desviar tráfico a rutas internas.

La vulnerabilidad afecta específicamente a Microsoft.AspNetCore.Server.Kestrel.Core en determinadas versiones de ASP.NET Core, y se considera uno de los problemas de seguridad más serios que ha afrontado la plataforma en los últimos años. De nuevo, se trata de un vector explotable por atacantes no autenticados, lo que aumenta considerablemente la superficie de riesgo.

Barry Dorrans, responsable técnico de seguridad en .NET, ha explicado que la puntuación tan alta obedece al peor escenario posible, dado que el impacto real depende en gran medida de cómo esté construida cada aplicación. Aun así, la valoración parte de la premisa de un bypass de mecanismos de seguridad con cambios de ámbito, que es el tipo de fallo que en entornos corporativos se considera inasumible.

Versiones afectadas y parches para Kestrel y ASP.NET Core

Para hacer frente a CVE-2025-55315, Microsoft ha publicado actualizaciones de seguridad específicas para distintas ramas de .NET y ASP.NET Core, abarcando tanto versiones antiguas como las más recientes, incluyendo ASP.NET Core 2.3, 8.0 y 9.0.

En entornos donde se utiliza .NET 8 o superior, la mitigación recomendada pasa por aplicar todos los parches disponibles a través de Microsoft Update y validar posteriormente que los runtimes y paquetes han quedado en la versión corregida. Es especialmente importante revisar que las aplicaciones se recompilan con esas versiones y que las imágenes de producción no siguen arrastrando binarios vulnerables.

En el caso de proyectos que siguen ejecutándose sobre .NET 2.3, Microsoft indica que es imprescindible actualizar la referencia del paquete Microsoft.AspNet.Server.Kestrel.Core a la versión 2.3.6, recompilar la solución e implementar de nuevo los despliegues. De lo contrario, Kestrel seguiría procesando solicitudes con la lógica defectuosa que permite la suplantación de peticiones HTTP.

Los despliegues que utilizan aplicaciones autónomas o empaquetadas como un único archivo tienen también la obligación de compilar desde cero con los runtimes parcheados, ya que de lo contrario el ejecutable seguirá incluyendo el código vulnerable. Es fácil olvidar este detalle si se confía en exceso en el simple hecho de actualizar el host.

Junto con las actualizaciones del propio framework, Microsoft ha publicado parches para Microsoft.AspNetCore.Server.Kestrel.Core y otros componentes relacionados, buscando reforzar la robustez del parsing y el manejo de solicitudes HTTP. En resumen, no se trata de un único arreglo aislado, sino de una mejora coordinada en varios puntos de la pila ASP.NET Core.

Actualizaciones críticas adicionales en ASP.NET Core y riesgo global

Más allá de estos casos concretos, Microsoft ha ido liberando parches críticos para otras vulnerabilidades en ASP.NET Core que pueden derivar en ejecución remota de código (RCE), elevación de privilegios y ataques de denegación de servicio (DoS). La combinación de estos fallos deja claro que el framework, por muy maduro que sea, no está exento de regresiones peligrosas.

Estos fallos afectan a componentes clave del runtime de ASP.NET Core, incluyendo el procesamiento de solicitudes HTTP, middlewares de autenticación y autorización, y APIs relacionadas con serialización y deserialización de datos. En muchos casos, los atacantes pueden aprovechar inputs mal formados o payloads manipulados para disparar comportamientos inesperados.

Las versiones afectadas suelen corresponder a releases anteriores a los parches de seguridad publicados en abril de 2026, por lo que resulta obligatoria una auditoría de versiones en todos los entornos productivos que sigan ejecutando builds antiguos. Dejar servidores desactualizados es, hoy en día, apostar a perder.

Desde el punto de vista de negocio, no aplicar estos parches puede tener consecuencias durísimas: pérdida de confidencialidad de datos, integridad comprometida, indisponibilidad de servicios esenciales y un impacto reputacional que cuesta años recuperar. Las organizaciones que dependen de ASP.NET Core para aplicaciones críticas deben contemplar la gestión de parches como un proceso continuo y no como una tarea puntual.

La recomendación general de Microsoft pasa por aplicar los parches tan pronto como estén disponibles, revisar la configuración de seguridad de los entornos, fortalecer el monitoreo de actividad sospechosa y revisar los procesos de desarrollo seguro para minimizar la probabilidad de introducir vulnerabilidades en el propio código de aplicación.

Manejo de errores y excepciones en ASP.NET Core: pieza clave del puzzle

Cuando hablamos de seguridad, muchas veces se piensa solo en parches y criptografía, pero un buen sistema de gestión de errores en ASP.NET Core es fundamental para detectar, investigar y mitigar incidentes. El framework ofrece múltiples mecanismos para manejar excepciones, devolver códigos de estado adecuados y exponer respuestas estándar, como ProblemDetails, en APIs.

En entornos de desarrollo, ASP.NET Core habilita por defecto la Developer Exception Page cuando se cumplen ciertas condiciones (normalmente, estar en el entorno Development). Esta página se activa mediante el middleware DeveloperExceptionPageMiddleware, que se coloca al principio de la canalización HTTP para interceptar excepciones sin controlar, tanto síncronas como asíncronas, y mostrar información detallada.

La página de excepciones del desarrollador puede incluir stack traces, parámetros de querystring, cookies, cabeceras HTTP y metadatos del endpoint. Es una herramienta magnífica durante el desarrollo, pero, lógicamente, no debe estar habilitada en producción, porque exponer detalles internos facilita la vida a los atacantes.

En el entorno Production, la práctica recomendada es configurar una página de error personalizada mediante UseExceptionHandler. Este middleware captura las excepciones no controladas, las registra y vuelve a ejecutar la solicitud a través de una canalización alternativa, normalmente apuntando a una ruta como /Error.

Al reejecutar la canalización, hay que tener en cuenta que los middlewares pueden verse invocados de nuevo con la misma HttpContext, por lo que conviene limpiar estados internos, cachear resultados o reutilizar datos ya leídos (por ejemplo, el cuerpo de la petición), para no provocar errores adicionales. Además, los servicios de ámbito siguen siendo los mismos a lo largo de la reejecución.

Acceso a la excepción y control centralizado con IExceptionHandler

Para obtener información detallada sobre la excepción que ha desencadenado la página de errores, ASP.NET Core expone la característica IExceptionHandlerPathFeature. A través de HttpContext.Features.Get<IExceptionHandlerPathFeature> se pueden recuperar tanto la ruta original de la solicitud como el propio objeto Exception.

Un patrón frecuente en Razor Pages consiste en almacenar el RequestId y un mensaje de error amigable en el modelo de página, usando IExceptionHandlerPathFeature para personalizar el mensaje según el tipo de excepción (por ejemplo, FileNotFoundException) o la ruta que ha provocado el fallo. Esto permite mostrar errores más útiles al usuario, sin filtrar detalles internos.

Además del enfoque basado en páginas o controladores específicos, ASP.NET Core ofrece la interfaz IExceptionHandler como mecanismo centralizado de gestión de excepciones. Las implementaciones de esta interfaz se registran con AddExceptionHandler<T> y se ejecutan en orden, devolviendo true cuando han manejado la excepción y false cuando prefieren delegar en el comportamiento por defecto.

Este sistema facilita, por ejemplo, registrar errores en un sistema externo, aplicar lógica condicional según el tipo de excepción o modificar la respuesta HTTP global sin tener que tocar cada controlador de forma individual. A partir de .NET 10, además, el middleware de excepciones permite configurar SuppressDiagnosticsCallback para decidir cuándo suprimir métricas y logs en caso de excepciones ya gestionadas.

Otra opción muy flexible es usar una lambda en UseExceptionHandler, accediendo directamente al contexto, estableciendo el código de estado, el Content-Type y escribiendo la respuesta a mano. Incluso se puede utilizar IProblemDetailsService dentro de esa lambda para emitir una respuesta estándar de ProblemDetails que describa con claridad el problema ocurrido.

Páginas de códigos de estado y respuestas ProblemDetails

Por defecto, una aplicación ASP.NET Core no muestra páginas amigables para códigos de estado HTTP como 404; simplemente devuelve el código y un cuerpo vacío. Para enriquecer esta experiencia y facilitar depuración, se puede activar el middleware de páginas de códigos de estado mediante UseStatusCodePages.

UseStatusCodePages soporta varias modalidades: texto plano con un mensaje genérico, lambdas para personalizar completamente la respuesta o variantes que redirigen o reejecutan la canalización a un endpoint alternativo, como UseStatusCodePagesWithRedirects y UseStatusCodePagesWithReExecute.

Con UseStatusCodePagesWithRedirects, el middleware emite un 302 Found y redirige al cliente a una URL que suele renderizar una vista más amable, devolviendo normalmente un 200 OK. Este enfoque tiene sentido cuando se quiere que la barra de direcciones refleje la ruta final de error y no interesa preservar el código de estado original.

UseStatusCodePagesWithReExecute, por su parte, no cambia el código de estado inicial, sino que vuelve a ejecutar la petición contra otra ruta para generar el cuerpo de respuesta. La URL original se conserva en la barra del navegador, y el punto de error puede recuperar la ruta y query originales a través de IStatusCodeReExecuteFeature, lo que resulta muy útil para logging y debugging.

En el ámbito de APIs, ASP.NET Core ha abrazado el estándar ProblemDetails como formato habitual para respuestas de error. Registrando AddProblemDetails en el contenedor de servicios, el middleware puede generar automáticamente respuestas JSON con campos como type, title, status y traceId cuando se producen errores de cliente o servidor sin cuerpo previo.

Este comportamiento se puede personalizar mediante ProblemDetailsOptions.CustomizeProblemDetails, añadiendo extensiones como un identificador de nodo (por ejemplo, nombre de máquina) u otros metadatos que ayuden a trazar problemas en entornos distribuidos. También es posible implementar un IProblemDetailsWriter personalizado que decida qué estados maneja y cómo se serializan los detalles.

Lecciones para DevSecOps y buenas prácticas continuas

La cascada de vulnerabilidades en ASP.NET Core y su ecosistema .NET pone sobre la mesa varias lecciones clave para cualquier equipo serio de desarrollo: las dependencias de terceros son un vector crítico, la criptografía mal implementada rompe todo el modelo de confianza y los mecanismos de autenticación se han convertido en objetivo prioritario de los atacantes.

Desde una perspectiva de DevSecOps, se vuelve imprescindible integrar análisis de dependencias en los pipelines CI/CD, ejecutar pruebas de seguridad continuas y mantener una visibilidad clara de todos los componentes de terceros que se incorporan al proyecto. Herramientas de SCA (Software Composition Analysis) y escáneres de vulnerabilidades deben dejar de ser algo opcional para pasar a formar parte del flujo estándar de integración.

También es vital reforzar las auditorías de logs y la monitorización de eventos de seguridad, sobre todo en lo relativo a autenticación, emisión de tokens, creación de sesiones, cambios de permisos y operaciones administrativas. Sin buenos registros y alertas, una vulnerabilidad como CVE-2026-40372 o CVE-2025-55315 puede explotarse silenciosamente durante meses.

Pese a la complejidad y el volumen de fallos recientes, ASP.NET Core sigue siendo un framework sólido siempre que se mantenga correctamente actualizado y se configure de forma segura. La combinación de parcheo rápido, rotación de claves cuando toca, buenas prácticas de manejo de errores y un enfoque proactivo de seguridad marca la diferencia entre una plataforma robusta y un blanco fácil para atacantes.

Todo este conjunto de vulnerabilidades y mecanismos de mitigación nos recuerda que la seguridad en ASP.NET Core no es solo cuestión de aplicar parches puntuales, sino de asumir una disciplina continua: vigilar las versiones de paquetes y runtimes, cuidar el manejo de errores y excepciones, revisar las respuestas HTTP y ProblemDetails que exponemos, y apoyar todo ello en procesos DevSecOps maduros que permitan reaccionar rápido cada vez que aparezca un nuevo fallo crítico en el ecosistema .NET.