Lo curioso de CVE-2026-40372 es de dónde salió. No fue un fallo que llevara años escondido, sino algo que Microsoft introdujo en su propio parche del Patch Tuesday de abril. La actualización .NET 10.0.6 del 14 de abril metió una regresión en el componente de cifrado de ASP.NET Core, y una semana después la empresa tuvo que publicar la 10.0.7 fuera de banda para arreglar el destrozo.
Qué falla exactamente
ASP.NET Core Data Protection es la pieza que cifra y firma datos sensibles en una aplicación web: cookies de autenticación, tokens antiforgery, estado de OIDC, TempData y similares. Su trabajo es asegurar que un cliente no pueda manipular esos valores sin que el servidor lo note.
A partir de la versión 10.0.6 del paquete NuGet Microsoft.AspNetCore.DataProtection, el cifrador autenticado empezó a calcular el HMAC de validación sobre los bytes equivocados del payload y, en determinados casos, descartaba directamente el hash calculado. La consecuencia es que la comprobación de integridad dejaba de servir para nada. Un atacante podía construir un payload falsificado que pasaba como auténtico, porque la rutina de validación ya no comparaba lo que tenía que comparar. Los payloads falsos generados durante la ventana vulnerable llevaban bytes de HMAC todos a cero, detalle que luego sirvió para que la versión corregida los rechazara.
A quién afecta y con qué gravedad
Afecta a las versiones 10.0.0 a 10.0.6 del paquete Microsoft.AspNetCore.DataProtection, aunque la regresión que rompe la validación se introdujo en la 10.0.6. Cualquier aplicación ASP.NET Core con .NET 10 que use Data Protection y exponga endpoints a la red está en el rango de tiro.
La puntuación es CVSS 9.1, crítica. Con la validación rota, un atacante no autenticado puede falsificar cookies de autenticación y hacerse pasar por cualquier usuario, incluido uno con privilegios de nivel SYSTEM. Además puede descifrar payloads protegidos previamente, lo que abre la puerta a leer tokens de sesión, estado OIDC y otros datos que se suponía cifrados. No hay impacto en disponibilidad: el problema es de confidencialidad e integridad, que en este contexto es lo más caro.
Mitigación: actualizar no basta
Microsoft publicó la 10.0.7 el 21 de abril como actualización fuera de banda. Pero parchear y desplegar solo cierra la herida; no limpia lo que pudo entrar por ella.
Si tu aplicación estuvo expuesta a internet durante la ventana vulnerable, hay que rotar el key ring de Data Protection. Esto invalida cualquier token que un atacante pudiera haber falsificado o que la propia aplicación hubiera emitido de forma legítima durante ese periodo y que ahora no puedas distinguir de uno fraudulento. Sin la rotación, un token falsificado seguiría siendo válido aunque el código ya esté corregido.
El resumen práctico: subir Microsoft.AspNetCore.DataProtection a 10.0.7 o posterior, volver a desplegar y rotar las claves. Cuanto antes mejor, sobre todo si la app es de cara al público.