.NET 10.0.7 sale out-of-band para arreglar CVE-2026-40372 en ASP.NET Core Data Protection

Microsoft lanzó .NET 10.0.7 out-of-band hoy para parchar CVE-2026-40372, un bug de elevation-of-privilege en Microsoft.AspNetCore.DataProtection que afecta a toda release 10.0.x desde 10.0.0 hasta 10.0.6. Si corres ASP.NET Core en la línea LTS 10.0, esta no es una actualización de “esperar al Patch Tuesday”. Antiforgery tokens, auth cookies, TempData, y cualquier cosa ruteada por IDataProtector vive sobre este componente, así que el radio de explosión cubre la mayoría de las apps ASP.NET Core en producción.

Cómo el HMAC se computó sobre los bytes equivocados

ASP.NET Core Data Protection usa encriptación autenticada: los ciphertexts llevan un tag de validación HMAC que el framework chequea en cada llamada Unprotect. La implementación managed en ManagedAuthenticatedEncryptor estaba computando ese tag sobre el slice equivocado del payload y luego descartando el hash computado, lo que significa que el paso de validación no estaba realmente validando los bytes que el atacante controla. Eso rompe la promesa de integridad de la construcción y abre la puerta a que tokens falsificados sean aceptados como genuinos.

La regresión se introdujo junto con un breaking change separado en la release de servicing 10.0.6. Los usuarios golpeaban CryptographicException: The payload was invalid. al tratar de desencriptar datos que habían sido protegidos en 10.0.5 o anteriores, con el error saliendo dentro de ManagedAuthenticatedEncryptor.CalculateAndValidateMac. Mientras el equipo perseguía la regresión de desencriptación rastreada en aspnetcore#66335, encontraron el bug HMAC más profundo, de ahí la release out-of-band en lugar de meterlo en el servicing de mayo.

El radio de explosión de dos capas

Data Protection está cableado en casi todo servicio del framework que necesita hacer round-trip de estado opaco al cliente:

// Antiforgery, auth cookies, TempData, BearerToken, OpenIdConnect state,
// and your own IDataProtector consumers all flow through the same pipeline.
builder.Services.AddDataProtection()
    .PersistKeysToFileSystem(new DirectoryInfo(@"/var/keys"))
    .ProtectKeysWithCertificate(cert);

public class TokenService(IDataProtectionProvider provider)
{
    private readonly IDataProtector _protector =
        provider.CreateProtector("TokenService.v1");

    public string Protect(string userId) => _protector.Protect(userId);
    public string Unprotect(string token) => _protector.Unprotect(token); // trusts the MAC
}

En 10.0.0 a 10.0.6, Unprotect es el eslabón débil. Un payload armado podría pasar el chequeo de validación porque el encryptor no estaba hasheando los bytes que reclamaba estar hasheando. Combinado con la regresión de desencriptación 10.0.6, a los operadores les dejaba elegir entre una app rota o una vulnerable. 10.0.7 quita esa elección.

Qué hacer antes de cerrar la pestaña

Actualiza el runtime y el paquete juntos. El runtime embarca el encryptor in-box, y el paquete NuGet embarca el contrato para apps que lo referencian directamente.

# 1. Install the 10.0.7 SDK or runtime from the download page,
#    then verify:
dotnet --info

# 2. Bump the package if your project pins it explicitly:
dotnet add package Microsoft.AspNetCore.DataProtection --version 10.0.7

# 3. Rebuild and redeploy. Existing key rings stay valid; this fix
#    does not force a key rotation.

Un par de notas operativas. Si desplegaste 10.0.6 y los usuarios empezaron a pegar CryptographicException: The payload was invalid., 10.0.7 restaura compatibilidad con ciphertexts escritos por 10.0.5 y anteriores, así que la regresión de desencriptación se desbloquea al mismo tiempo. Las apps framework-dependent levantan el fix cuando el runtime del host se actualiza, pero las apps self-contained o AOT-publicadas necesitan un rebuild contra 10.0.7. Si estás en 9.0.x o 8.0.x, no estás afectado por este CVE, pero el ciclo de servicing de abril 2026 todavía aplica.

Las releases out-of-band de .NET son raras. Esta es más acotada en alcance que CVE-2025-55315, el bug de request-smuggling del otoño pasado, porque la explotación necesita código que llame a Unprotect sobre input influenciado por el atacante. Eso todavía describe esencialmente a toda app ASP.NET Core autenticada. Parchea hoy.