If you run ASP.NET Core on .NET 10 and you haven't updated in the last 48 hours, stop reading and update now. Microsoft released an emergency out-of-band patch for CVE-2026-40372 — a CVSS 9.1 privilege escalation vulnerability in the Data Protection stack that lets unauthenticated attackers forge authentication cookies and decrypt protected payloads. This isn't a theoretical concern: the bug sits in the cryptographic validation path that guards every cookie, antiforgery token, and TempData value your application issues.

But here's the part most teams will miss: updating to .NET 10.0.7 fixes the validation routine, but it doesn't invalidate tokens that were forged while the bug was live. If your application served internet-facing traffic on any .NET 10 release from 10.0.0 through 10.0.6, patching is step one of a multi-step response.

What Broke

ASP.NET Core's Data Protection system uses AES-256-CBC with HMACSHA256 for authenticated encryption. The flow is straightforward: encrypt the payload, compute an HMAC tag over the ciphertext, and append it. On decryption, verify the HMAC before touching the ciphertext. This "encrypt-then-MAC" pattern is the industry standard for preventing tampering.

The bug in Microsoft.AspNetCore.DataProtection versions 10.0.0 through 10.0.6 broke both sides of that contract. The managed authenticated encryptor computed its HMAC validation tag over the wrong bytes of the payload and then, in some cases, discarded the computed hash entirely. The server would accept tampered ciphertext as legitimate.

// IMPORTANT

Microsoft classifies this as CWE-347 (Improper Verification of Cryptographic Signature). The CVSS vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N — network-exploitable, no privileges required, no user interaction needed, with high impact on both confidentiality and integrity.

The Exploitation Path

With HMAC validation effectively disabled, the vulnerability opens a classic padding-oracle attack surface. An attacker can repeatedly modify ciphertext and observe the server's response to recover plaintext block by block. This requires many requests per byte recovered, but the attack is well-understood and automatable.

The practical impact goes beyond reading protected data. Once an attacker can forge a valid authentication cookie, the application treats them as the impersonated user. Worse, during that authenticated session, the application may issue legitimate downstream artefacts — refresh tokens, API keys, password reset links — that are properly signed with the real key material. Those artefacts survive the patch because they were genuinely issued by your application.

This is what makes CVE-2026-40372 different from a typical "update and move on" vulnerability. The attack creates legitimate credentials that outlive the bug.

What's Affected

The vulnerability exists in the managed cryptographic implementation path, which means the impact varies by platform:

Primary affected configurations:

Less affected:

// WARNING

Don't assume Windows means safe. If your application explicitly configures a non-default encryptor, or if you're consuming the package via net462/netstandard2.0 assets, you're on the managed path regardless of OS.

Everything Data Protection Touches

Before deciding this doesn't affect you, consider what Data Protection actually secures in a typical ASP.NET Core application:

If the server can't reliably distinguish authentic protected data from attacker-controlled ciphertext, this stops being a narrow cryptography issue and becomes a trust-boundary failure across your entire request pipeline.

How It Was Discovered

The vulnerability came to light almost accidentally. After the .NET 10.0.6 Patch Tuesday release in April 2026, users started reporting decryption failures in their applications (tracked in dotnet/aspnetcore#66335). Microsoft's investigation into these decryption regressions revealed the underlying HMAC validation flaw — a bug that had been present since .NET 10.0.0 but only became apparent when a related code change in 10.0.6 started causing visible failures.

Microsoft compared the vulnerability to MS10-070, which exploited a similar padding-oracle condition in ASP.NET's legacy encryption infrastructure back in 2010. The parallel is apt: both involve broken cryptographic validation in a framework component that applications trust implicitly.

Step 1: Patch

Update Microsoft.AspNetCore.DataProtection to 10.0.7 or install the .NET 10.0.7 runtime:

terminal 
dotnet --info | grep "Microsoft.AspNetCore.App"

Verify you're running 10.0.7 or later. For containerised deployments, rebuild your images — updating the host runtime doesn't help if your container ships the vulnerable binary.

Check for transitive dependencies pulling in the old package:

terminal 
dotnet package list --include-transitive --vulnerable

// TIP

Use dotnet nuget why to trace exactly how a vulnerable package enters your dependency graph. Direct references are obvious; transitive ones often aren't.

Step 2: Rotate the Key Ring

This is the step most teams will skip, and it's the most important one for internet-facing applications. Patching fixes the validation routine going forward, but any tokens forged during the vulnerable window remain valid until the keys that issued them are revoked.

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

var services = new ServiceCollection();
services.AddDataProtection();
// Add your key storage configuration — FileSystem, DbContext, Redis, Azure Blob, etc.

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

keyManager.RevokeAllKeys(
    revocationDate: DateTimeOffset.UtcNow,
    reason: "Emergency revocation: CVE-2026-40372 remediation");

This forces all new protection operations onto fresh keys and invalidates every previously-issued protected payload. The consequences are intentional and immediate:

// WARNING

If you run a web farm, the key revocation must propagate to the shared key store (database, Redis, Azure Blob Storage, file share) before all nodes pick it up. Ensure your key ring persistence is correctly configured before running the revocation.

Step 3: Audit Application-Layer Artefacts

Key rotation handles everything Data Protection encrypts directly. But if an attacker used a forged cookie to authenticate and then triggered your application to issue downstream artefacts, those live outside the key ring:

These need to be invalidated or rotated separately. If you store creation timestamps, you can scope the invalidation to the vulnerable window. If you don't — consider invalidating all active tokens and forcing reissuance.

Step 4: Rotate Secrets Protected by Data Protection

This is the step that catches people off guard. If your application uses IDataProtector.Protect() to encrypt long-lived secrets — database connection strings, third-party API keys, sensitive configuration values — those secrets should be treated as potentially disclosed.

Example.cs 
// Bad — if this pattern exists in your codebase, rotate the underlying secret
var encrypted = protector.Protect(thirdPartyApiKey);
await store.SaveAsync("payment-gateway-key", encrypted);

The encrypted value itself isn't the concern — it's that an attacker with a forged cookie could have called endpoints that return or use the decrypted value. Rotate the secrets at their source (the third-party dashboard, the database password, the storage account key).

Step 5: Hunt for Exploitation Evidence

If your application was internet-facing during the vulnerable window, check your logs for signs of a padding-oracle attack:

terminal 
# Search application logs for correlation failures during the vulnerable window
grep -i "correlation failed\|antiforgery.*failed\|data protection.*failed" /var/log/app/*.log

// NOTE

Absence of evidence is not evidence of absence. A sophisticated attacker may have probed during low-traffic windows or used distributed source IPs. Treat the key rotation and artefact audit as necessary regardless of what your logs show.

Verifying Remediation

After completing all steps, validate that the fix is working:

  1. Old cookies are rejected — attempt to use a pre-rotation authentication cookie and confirm it's denied
  2. Pre-rotation reset links fail — password reset tokens issued before key rotation should no longer work
  3. Fresh artefacts succeed — new logins, new tokens, and new protected payloads work normally
  4. dotnet package list --vulnerable returns clean for Microsoft.AspNetCore.DataProtection

Common Pitfalls

Confusing runtime and package patching. Containerised deployments must rebuild images with the updated NuGet package or runtime. Patching the host operating system doesn't change what's inside the container.

Checking only direct dependencies. Many applications reference Microsoft.AspNetCore.DataProtection transitively through authentication, identity, or antiforgery packages. Use --include-transitive when checking for vulnerable packages.

Assuming patching is the complete response. The patch fixes the validation routine. It doesn't revoke forged tokens, invalidate downstream artefacts, or rotate compromised secrets. Those are separate, mandatory steps for any application that was exposed.

Misunderstanding the Windows exception. The CNG code path exception applies only to net10.0 framework-dependent deployments on Windows. If your application targets net462 or netstandard2.0, or explicitly configures a managed encryptor, you're vulnerable on Windows too.

Skipping key rotation because "we're internal." Internal applications behind a VPN are lower risk, but not zero risk. If your threat model includes compromised internal networks (and it should), the key rotation cost — a brief user disruption — is worth the certainty.

Summary