CRITICAL: Microsoft Patches CVSS 9.1 ASP.NET Core Flaw Letting Attackers Forge Authentication Cookies on Linux

If you run anything on .NET 10 that touches the Microsoft.AspNetCore.DataProtection library, and you happen to host it on Linux or macOS, you have something interesting waiting in your morning ticket queue. Microsoft published an advisory yesterday for CVE-2026-40372, a CVSS 9.1 elevation-of-privilege flaw in the data protection plumbing that ASP.NET Core uses to sign and seal almost every sensitive blob the framework hands back to a client. Authentication cookies. Antiforgery tokens. Anything you encrypt with the framework's built-in IDataProtector. The bug, baked into versions 10.0.0 through 10.0.6 of the NuGet package, lets a network-positioned attacker forge those payloads and, in some cases, decrypt the legitimate ones.

That last bit is the part that should make you reach for the coffee. This is not a denial of service. This is not an information leak you can hand-wave at the next change advisory. An attacker who reaches a vulnerable endpoint on the open internet can manufacture cookies that the server will dutifully accept as if they had been issued by the framework itself. Sign in as anyone. Bypass antiforgery checks. Pry open whatever the developer trusted DataProtection to keep sealed. The reason the public-facing internet has not yet caught fire is that proof-of-concept code is not circulating in mass-market form, but the technical description in the advisory is detailed enough that any competent researcher with an afternoon and a debugger will reproduce it.

Microsoft labels the advisory as Important rather than Critical, which is its usual under-slung scoring posture, but the CVSS 3.1 vector tells the real story. AV:N, AC:L, PR:N, UI:N, S:U, C:H, I:H, A:N. Network attack vector, low complexity, no privileges required, no user interaction, high confidentiality and integrity impact, with availability untouched because the attack does not need to break the server in order to abuse it. The scoring rubric calls anything between 9.0 and 10.0 critical, and 9.1 sits comfortably in that bracket regardless of marketing language. If you have not run an inventory of your exposed .NET 10 services in the past 24 hours, that is task one before lunch.

The technical mechanism, for those who like the gory details, is a regression in the managed authenticated encryptor that ships with the DataProtection stack. Under normal operation the encryptor wraps a payload, computes an HMAC validation tag over the ciphertext, and concatenates the two so that the receiver can verify the tag before bothering to decrypt. That HMAC is the entire reason authenticated encryption is called authenticated. Without it, you have a padding-oracle factory and a long history of every framework that built one ending up in the breach headlines. The regression in 10.0.0 through 10.0.6 causes the encryptor to compute the HMAC over the wrong slice of the payload bytes and then, in some code paths, discard the tag entirely before it ever gets compared. The check is not failing. The check is being skipped. Forged payloads sail through.

The advisory itself nods toward the historical comparison most defenders will reach for, which is MS10-070. That older bulletin covered the padding-oracle attack against ASP.NET's legacy encryption, and it was the kind of vulnerability that produced live exploitation kits within days of disclosure and showed up in compromise notifications for years afterward. The 2026 incarnation has a wider blast radius because DataProtection is the default key management surface for everything modern .NET ships, including Identity, antiforgery, session state, and any custom code that simply calls IDataProtector.CreateProtector and trusts the framework to handle the rest. If you wrote a feature that takes a sensitive value, runs it through a Protect call, and stashes the result somewhere a user can hand back to you later, that feature is in scope.

Affected configurations are narrower than the raw version count suggests, but not by as much as a defender would want. The vulnerable code paths are exercised primarily on non-Windows hosts, because Windows deployments tend to lean on the DPAPI-backed encryptor that sidesteps the regressed code. Linux and macOS deployments, which is most modern .NET workloads in the wild given Kubernetes, App Service Linux, and the entire container ecosystem, run the affected encryptor by default. If your build pipeline targets a Linux base image and pulls Microsoft.AspNetCore.DataProtection at any version between 10.0.0 and 10.0.6, you are in scope. Transitive dependencies count here too. The package is dragged in by a long list of common middleware, so a clean grep for the literal string in your csproj files is not sufficient. Ask the dotnet CLI for the resolved dependency graph with dotnet list package --include-transitive and look for the version range there.

Patching is the easy part. Microsoft shipped 10.0.7 of the package on April 21 alongside the advisory, and a normal dotnet add package or a NuGet pin update followed by a redeploy closes the immediate hole. The harder part, and the part many teams will skip and regret later, is the cleanup. If your application was internet-exposed during the vulnerable window, which began with the 10.0.0 release in late 2025, you cannot assume the absence of evidence is the evidence of absence. An attacker who used the bug to authenticate as a privileged user during that window may have triggered the application to issue its own legitimately-signed long-lived tokens to itself. Password reset links. API keys. Refresh tokens. Anything the application produces and lets a user redeem later. Those tokens were minted by your real keys, and they will keep working after you upgrade to 10.0.7 unless you also rotate the DataProtection key ring.

Key rotation is straightforward in concept and a good place to break production in practice if you have not rehearsed it. The framework exposes IKeyManager.RevokeAllKeys and a CreateNewKey API that together force the ring to rotate, but every active session, every persisted antiforgery token, and every encrypted artifact your application has stashed in a database becomes garbage at the moment of rotation. The advisory recommends rotation for any application that served internet-exposed endpoints during the vulnerable window. Pair the rotation with a forced re-authentication for all users and a sweep of any long-lived tokens you have issued in the last six months. If your application does not record token issuance in an auditable log, that is a process gap worth fixing before the next time something like this lands on a Tuesday morning.

Detection guidance is thinner than the patching guidance, because a successful forgery looks indistinguishable from a legitimate authentication on the application's own logs. The cookie validates. The session starts. There is no MAC-failed exception to alert on. The defender's best signal sits one layer up. Look for sign-in patterns that do not match the rest of a user's history, especially privileged accounts authenticating from new IP space without a corresponding identity provider event. If you front your .NET applications with a WAF or reverse proxy that logs request bodies, repeated POSTs to authentication endpoints with malformed cookies and request volume anomalies during the vulnerable window are worth a look. The padding-oracle family of attacks tends to produce a noisy fingerprint at the network edge, and even after the patch, a retroactive review of those logs may surface what real-time alerting missed.

There is also an architectural hardening conversation worth having while the incident is fresh in everyone's memory. Applications that store DataProtection keys on the local filesystem of an ephemeral Linux container without external key protection are exposing themselves to a much larger problem than this single CVE. Microsoft has published guidance on protecting key rings with Azure Key Vault, certificate-based encryption, or DPAPI-NG where Windows is involved. Adopting one of those patterns means that even if a future bug compromises the encryptor, the key material itself is not sitting in a tmpfs path for any process with read access to walk away with. That is a lift, but it is the kind of lift that gets cheaper to fund the day after a CVE like this one drops.

For the managed services crowd, this is a clinic in why a software bill of materials is not just a compliance checkbox. The clients who can answer "do we use Microsoft.AspNetCore.DataProtection at version 10.0.x on Linux today" inside an hour are the ones who survive. Everyone else is grepping repositories and praying. There is a service offering inside that gap. Continuous SBOM monitoring tied to a live CVE feed, with auto-generated tickets and a defined SLA for vulnerable dependency replacement, is the kind of thing a midmarket client did not know they needed until the fire drill makes the absence painful. The same conversation opens the door to identity threat detection, because the practical fallout of CVE-2026-40372 is forged sessions, and forged sessions are exactly what identity-aware monitoring exists to catch.

Expect a long tail on this one. The advisory is fresh and proof-of-concept code has not yet circulated publicly, but padding-oracle and HMAC-bypass bugs have a track record of getting weaponized inside the same week the technical writeup goes out. Patch to 10.0.7 today, rotate keys after, and treat any privileged authentication during the vulnerable window as suspect until proven otherwise. The DataProtection layer earned its reputation by quietly working for years. Earning that trust back is going to take some homework.