On April 21, Microsoft pushed an emergency out-of-band update for ASP.NET Core to fix CVE-2026-40372. The headline number is CVSS 9.1. The one-liner is that an unauthenticated network attacker can forge authentication cookies and payloads, and from there reach SYSTEM on the web host. Versions 10.0.0 through 10.0.6 are affected. The fixed version is 10.0.7. That is the patch story, and if you run ASP.NET Core 10.x you should stop reading and go update, because the rest of this post is about something worse than the bug itself.
The bug sits in Microsoft.AspNetCore.DataProtection, the NuGet package that ASP.NET Core uses to protect cookies, anti-forgery tokens, and anything else the framework encrypts for you. The managed authenticated encryptor, the piece that is supposed to combine AES-CBC for confidentiality and HMAC-SHA256 for integrity, was processing its HMAC incorrectly. "Incorrectly" here means the integrity check did not do what the name implies. A forged cookie that should have failed verification passed verification. From there, you are inside the authentication boundary, and on a typical web host that boundary sits in front of a process running with enough privilege that a compromised session is an entry point to SYSTEM.
The Real Finding Is the Six Months
I want to be clear about what actually happened here, because "Microsoft shipped a patch" makes this sound like a routine CVE.
The regression was introduced in a library update to DataProtection. It landed in the stable NuGet release that ASP.NET Core 10.0 customers pulled into their builds. It passed whatever automated testing Microsoft runs on that package. It passed whatever manual review the DataProtection team does on crypto changes. It shipped to customers in 10.0.0. It stayed in 10.0.1, 10.0.2, 10.0.3, 10.0.4, 10.0.5, and 10.0.6. For every version of that window, any ASP.NET Core app running on .NET 10 had a broken integrity check on its auth cookies, and nobody noticed.
I am not calling out the Microsoft DataProtection team specifically. I am saying that the dominant assumption in most enterprise security programs is that the crypto you did not write, shipped by a major vendor, in a foundational package that millions of apps use, is not a part of your threat model. You worry about your application logic. You worry about third-party dependencies of uncertain provenance. You do not worry about Microsoft.AspNetCore.DataProtection. That assumption just got a counterexample.
The six-month window also has a second-order implication. Any attacker who found this independently, and who was operating at scale against ASP.NET Core apps any time between the 10.0.0 release and the April 21 patch, had a foothold that would not show up in any standard audit. Forged cookies do not trigger an alert. They just pass verification.
What to Actually Do This Week
Two things immediately, and one thing over the next quarter.
One. Patch to .NET 10.0.7 on every ASP.NET Core 10.x host. This is not a "put it in the next sprint" patch. The public advisory, combined with the class of bug, makes it a weekend patch. If your environment has any internet-facing ASP.NET Core 10.x app, assume the exploit is in circulation by the end of the week.
Two. Rotate the data protection keys for every app that ran on 10.0.0 through 10.0.6. DataProtection's key ring is what encrypts and signs your auth cookies and anti-forgery tokens, and if the integrity check on that key ring was broken for six months, the safe assumption is that the key material is contaminated. Rotating forces any attacker-forged sessions to become invalid, because sessions tied to the old keys will no longer deserialize cleanly. If you are using the default key storage provider, this is an operational chore. If you are using a custom provider, this is the moment you find out whether your custom provider supports clean rotation at all.
Three, and this is the structural one. Add a supply-chain dimension to your patch-window risk model for foundational Microsoft packages. The implicit contract most enterprise teams operate under is that Microsoft-shipped crypto is assumed-safe, which means it lives outside the regular vulnerability management cadence. That assumption is not free. It is a bet that regressions in foundational packages will be caught quickly by someone else. This CVE is the demonstration that the bet can lose. Concretely: if you are running NET 10.x in any load-bearing customer-facing application, track the DataProtection package version explicitly in your SBOM, pin it in your build, and include it in your weekly patch review the same way you would include a third-party library.
The Durable Lesson
The deeper story here is about how crypto bugs get found in production. They do not get found by routine testing, because routine testing mostly checks that the happy path works. They get found by someone looking for them on purpose. Microsoft presumably has that someone. The fact that this specific regression took six months to surface suggests that the rate of "someone looking on purpose" at foundational Microsoft crypto packages is lower than the rate of change in those packages, and that gap is the actual threat model.
Patch today. Rotate keys this week. And the next time a CVE advisory arrives that says "a cryptographic regression in a foundational library," do not read it as a one-off. Read it as the ambient rate of this class of bug, and budget your review accordingly.
Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if you'd rather hear about your weak spots from a friendly face.