The odd thing about CVE-2026-40372 is where it came from. This wasn’t a bug hidden for years. Microsoft introduced it in its own April Patch Tuesday update. The .NET 10.0.6 release on April 14 shipped a regression in the ASP.NET Core encryption component, and a week later the company had to push 10.0.7 out of band to clean up the mess.
What actually breaks
ASP.NET Core Data Protection is the piece that encrypts and signs sensitive data in a web application: authentication cookies, antiforgery tokens, OIDC state, TempData and similar. Its job is to make sure a client cannot tamper with those values without the server noticing.
Starting with version 10.0.6 of the Microsoft.AspNetCore.DataProtection NuGet package, the authenticated encryptor began computing its HMAC validation tag over the wrong bytes of the payload and, in some cases, discarding the computed hash entirely. The integrity check stopped doing its job. An attacker could craft a forged payload that passed as authentic, because the validation routine was no longer comparing what it should compare. Forged payloads produced during the vulnerable window carried all-zero HMAC bytes, a detail the corrected version later used to reject them.
Who is affected, and how badly
The advisory covers versions 10.0.0 through 10.0.6 of Microsoft.AspNetCore.DataProtection, though the regression that breaks validation was introduced in 10.0.6. Any ASP.NET Core application on .NET 10 that uses Data Protection and exposes endpoints to the network is in scope.
The score is CVSS 9.1, critical. With validation broken, an unauthenticated attacker can forge authentication cookies and impersonate any user, including one with SYSTEM-level privileges. The same flaw also lets an attacker decrypt previously protected payloads, which opens the door to reading session tokens, OIDC state and other data that was meant to stay encrypted. There is no impact on availability. This is a confidentiality and integrity problem, which in this context is the expensive kind.
Mitigation: patching isn’t enough
Microsoft published 10.0.7 on April 21 as an out-of-band update. Patching and redeploying closes the wound, but it doesn’t clean up what may have walked through it.
If your application was internet-exposed during the vulnerable window, you need to rotate the Data Protection key ring. That invalidates any token an attacker may have forged, plus any legitimate token the app issued during that period that you can no longer tell apart from a fraudulent one. Without rotation, a forged token would still be valid even after the code is fixed.
The practical checklist: bump Microsoft.AspNetCore.DataProtection to 10.0.7 or later, redeploy, and rotate the keys. The sooner the better, especially for public-facing apps.