Patch CVE-2026-40372, then rotate the keys

If you run ASP.NET Core apps on Linux or macOS and you pulled Microsoft.AspNetCore.DataProtection 10.0.6 from NuGet, treat CVE-2026-40372 as more than a package update. Install 10.0.7, then decide whether you need to rotate the DataProtection key ring and revoke anything the app issued during the vulnerable window.

That second step is the one teams will miss.

Microsoft shipped .NET 10.0.7 out of band on April 21, 2026 after customer reports showed decryption failures in apps updated to .NET 10.0.6. The investigation found a security regression in DataProtection. In the affected managed encryptor path, the HMAC validation tag could be calculated over the wrong bytes and then discarded in some cases. Microsoft scored CVE-2026-40372 at 9.1 and tied it to CWE-347, improper verification of a cryptographic signature.

In plain terms: protected ASP.NET Core payloads could pass checks they should have failed. That includes auth cookies, antiforgery tokens, TempData, OIDC state, and similar values that use DataProtection underneath.

Check whether you are actually affected

Do this before you turn the ticket into a company-wide outage. Not every .NET 10 app is in scope.

Start with the runtime and package inventory:

dotnet --info
dotnet --list-runtimes
dotnet list package --include-transitive
dotnet list package --vulnerable --include-transitive
dotnet nuget why Microsoft.AspNetCore.DataProtection

You are primarily in scope if all of this is true:

• The app referenced Microsoft.AspNetCore.DataProtection 10.0.6 from NuGet, directly or through a package such as Microsoft.AspNetCore.DataProtection.StackExchangeRedis, .EntityFrameworkCore, .AzureKeyVault, or .AzureStorage.
• The affected NuGet binary actually loaded at runtime.
• The app ran on Linux, macOS, or another non-Windows OS.
• The app did not load the safe ASP.NET Core shared framework copy instead of the NuGet package.

There is a smaller secondary path too. If an app or library referenced Microsoft.AspNetCore.DataProtection 10.0.0 through 10.0.6 and consumed the net462 or netstandard2.0 asset, it may be affected. Microsoft expects that population to be smaller, mostly .NET Framework server or desktop apps that happen to use ASP.NET Core DataProtection, plus netstandard2.0 libraries with the 10.0 package.

Do not include apps just because they run ASP.NET Core. Microsoft says DataProtection 8.0.x and 9.0.x are not affected. Framework-dependent net10.0 apps can also be safe when the installed ASP.NET Core shared framework version is greater than or equal to the PackageReference version and the shared framework copy is the one that loaded.

The load path matters. Check it, write it down, then decide.

Patch first

Upgrade the affected package to 10.0.7 or later and redeploy.

dotnet add package Microsoft.AspNetCore.DataProtection --version 10.0.7
dotnet restore
dotnet build

For framework-dependent deployments, install the .NET 10.0.7 runtime or SDK on the host or rebuild the container image from a 10.0.7 base image. Then redeploy the application and verify the running host:

dotnet --info
dotnet --list-runtimes

The patch fixes the validation routine going forward. Microsoft says forged payloads created for the vulnerable path should be rejected by corrected code.

That does not mean cleanup is done.

Rotate the DataProtection key ring

If the app was affected and served internet-exposed endpoints during the vulnerable window, rotate the DataProtection key ring. Microsoft is explicit about why: if an attacker used forged payloads to authenticate as a privileged user, the app may have issued legitimate tokens to them. Those tokens can remain valid after 10.0.7 unless the key ring is rotated.

The blunt option is RevokeAllKeys. Run it once from an application context that can reach the same key repository your production app uses.

using Microsoft.AspNetCore.DataProtection;
using Microsoft.AspNetCore.DataProtection.KeyManagement;
using Microsoft.Extensions.DependencyInjection;

var services = new ServiceCollection()
    .AddDataProtection()
    // Keep your existing key repository and protection configuration here.
    .Services
    .BuildServiceProvider();

var keyManager = services.GetRequiredService<IKeyManager>();

keyManager.RevokeAllKeys(
    revocationDate: DateTimeOffset.UtcNow,
    reason: "CVE-2026-40372 DataProtection validation bypass");

Expect user impact. Existing auth cookies stop working. Users sign in again. Antiforgery tokens are reissued. That is not a side effect to avoid; it is the point of the rotation.

If you can prove only one key was active during the vulnerable window, use RevokeKey(Guid keyId, string reason) instead. Most teams will not have that confidence on the first pass. Use the broad rotation when the exposure is real and internet-facing.

Revoke what key rotation cannot touch

Key rotation invalidates DataProtection-protected payloads. It does not clean up every artifact your application may have issued after accepting a forged session.

Review anything created during the vulnerable window that carries identity or capability:

• API keys stored in the application database.
• Refresh tokens or access tokens issued through authenticated endpoints.
• Password reset links that have not expired.
• Email confirmation links that grant account access or change account state.
• Any persistent token or one-time link an authenticated request could generate.

If the app lets a logged-in admin create API keys, assume an attacker who forged an admin session could have created one. Rotate or revoke those keys at the application layer. If the app issued refresh tokens from a database table, expire the rows created during the window or force reauthentication for the affected users.

Also check whether the application stored long-lived secrets inside DataProtection-protected payloads. Microsoft calls out database connection strings and third-party API keys as examples. If your app did that, treat those secrets as disclosed and rotate them at the source.

Review logs for the noisy path

Microsoft recommends looking for unusual request volume against endpoints that accept protected payloads. That includes auth cookies, antiforgery tokens, state parameters, and similar inputs.

The useful pattern is not one bad request. It is sustained traffic with changing cookie or query-parameter values against the same protected endpoint during the vulnerable window. Microsoft notes that the padding-oracle style attack requires many requests per byte recovered, so the volume should look different from normal login or callback traffic.

Start with these questions:

1. Which apps loaded the affected DataProtection package?
2. Which of those apps were internet-exposed?
3. Which endpoints accept auth cookies, antiforgery tokens, OIDC state, TempData, or other protected payloads?
4. Did any of those endpoints see abnormal request volume between the 10.0.6 deployment and the 10.0.7 redeploy?
5. Were long-lived tokens or API keys created by accounts that also show odd request patterns?

Escalate if you find abnormal endpoint traffic, privileged sessions created during the window, or long-lived credentials issued from sensitive accounts. At that point this stops being routine patch work and becomes incident review.

Close the ticket with evidence

For a normal patch ticket, “package upgraded” might be enough. For this one, close it with four pieces of evidence:

• A dependency check showing whether Microsoft.AspNetCore.DataProtection 10.0.0 through 10.0.6 was present.
• A runtime check showing whether the affected binary could load on the deployed host.
• A remediation record showing 10.0.7 or later deployed.
• A key and token cleanup note explaining whether rotation was required, when it was done, and which application-layer artifacts were revoked.

If the app was not affected, record why. “Windows host using DataProtection 9.0.x” is useful. “Not vulnerable” is not.

PatchDay Alert tracks the awkward part of advisories like this: the work vendors put after the version number. In this case, that work is the difference between fixing the bug and leaving a valid token behind.