How CVE 2026 40372 Breaks ASP.NET Core Authentication

The security fix Microsoft shipped in 2010 to stop attackers from decrypting ASP.NET traffic and forging authentication cookies just got quietly broken by a regression in .NET 10. Microsoft.AspNetCore.DataProtection 10.0.6 shipped on April 14, 2026. One week later, on April 21, Microsoft released 10.0.7 out of band with the fix. In those seven days, any Linux or macOS server running 10.0.6 may have handed out real, signed login tokens to attackers, and those tokens still work after the patch unless the key ring is rotated. 😏

CVE-2026-40372 was published by Microsoft on April 21, 2026 with a severity rating of Important and a CVSS score of 9.1 in Microsoft’s MSRC advisory and 8.1 in their GitHub announcement. The difference comes down to one parameter in the scoring vector: whether the attacker needs any privileges to pull off the attack. The flaw falls under CWE-347, improper verification of a cryptographic signature. The fix is in Microsoft.AspNetCore.DataProtection 10.0.7. .NET 8 and .NET 9 are clean.

To understand why this bug is such a mess, it helps to know what DataProtection does inside an ASP.NET Core application.

When someone logs in, the cookie that the server sends back is not plain text. It needs to survive a round trip to the browser and come back without being changed on the way, so the framework encrypts it and attaches a signature. That signature is called an HMAC, which works a bit like a wax seal on an old letter. The server writes the cookie, stamps the seal on it, and sends it out. When the cookie comes back, the server checks the seal. If even one byte was changed in transit, the seal no longer matches and the server throws the request away.

The same signing system protects anti-forgery tokens, TempData values, OIDC state parameters, password reset links, and a long list of other things an ASP.NET application hands out. DataProtection is the foundation all of that sits on. If the signing holds, the whole login system holds with it.

The signing no longer holds.

Inside the managed encryptor, two things went wrong at the same time. The code that builds the HMAC signature was running over the wrong bytes of the payload, which means the seal was being stamped on the wrong part of the envelope. On top of that, in some cases the seal the code did calculate was then thrown away before it could be compared to the one on the cookie. A cookie with nothing but zeros where the signature should be goes right through.

That means an attacker who knows the cookie format can build one from scratch with empty signature bytes, send it to the server, and the server accepts it as legitimate. At that point the attacker is logged in as whoever they claimed to be. The real trick is what happens next. Once logged in, the application itself starts issuing real tokens to the attacker’s account. Session refresh tokens, API keys, password reset links, email confirmation links. All of them signed with the real server key. Those tokens look exactly like the ones the application gives out to real customers. Same signature, same format, no difference. The server logs show a normal login. The audit trail says everything is fine.

Microsoft’s own advisory points right at MS10-070, the famous ASP.NET padding oracle attack from September 2010. Juliano Rizzo and Thai Duong, the two cryptographers who found it, showed that ASP.NET encryption could be cracked byte by byte by an attacker who did nothing more than watch the error responses. The server would respond in a slightly different way for a cookie with valid padding versus one with invalid padding, and that small difference was enough to read the plaintext out of the server one byte at a time. The attackers could eventually pull the web.config file straight out of a running site, database passwords and all. Microsoft’s answer in 2010 was to start signing every encrypted payload with an HMAC, so the server would refuse to even try decrypting anything that had been tampered with. That HMAC signing is the foundation the modern DataProtection system was built on.

Sixteen years later, the bug is in the HMAC itself. And because the HMAC was the only thing stopping the padding oracle attack in the first place, both vectors are back on the table. An attacker can forge cookies with empty signatures to log in, or decrypt existing protected payloads byte by byte by firing many requests and watching how the server responds. The same family of attack Rizzo and Duong demonstrated in 2010, on the same system Microsoft built to stop it.

Not every application is affected. The bug lives in one specific code path, and whether that path runs depends on the operating system and a few other settings.

Windows apps are mostly safe. By default, ASP.NET Core on Windows uses a built-in cryptographic API called CNG, and CNG is not touched by this bug. The only Windows apps that run into it are the ones that went out of their way to switch to managed algorithms through UseCustomCryptographicAlgorithms.

The main target here is anything running on Linux, macOS, or any other non-Windows host with Microsoft.AspNetCore.DataProtection 10.0.6 on net10.0. That is the one version where the bug is actually reachable for net10.0 apps, and 10.0.6 only shipped on April 14, 2026. The fix arrived seven days later in 10.0.7.

A smaller group is affected across the entire 10.0.0 to 10.0.6 range: apps targeting net462 or netstandard2.0 that reference the DataProtection NuGet package directly. Microsoft describes this population as much smaller, but the window for this group stretches back to November 2025.

There is one exemption worth noting. Applications that run framework-dependent on net10.0 with a shared framework version equal to or higher than the DataProtection NuGet reference are safe, because the shared framework copy is loaded instead of the NuGet binary. Self-contained deployments do not get this exemption.

Applications still on DataProtection 8.0.x or 9.0.x are clean. The broken code was written during .NET 10 development and was never carried back into the older versions.

There is a second twist here.

Upgrading to 10.0.7 fixes the checking code going forward. It does not undo the tokens that were handed out during the vulnerable window. If an attacker used this bug while an application was running 10.0.6 and walked away with a password reset link, a refresh token, or an API key, that token is signed with the real secret, and it still works after the patch. The server has no way to tell it apart from a token issued to a real user, because the signature is the same.

Rotating the DataProtection key ring with RevokeAllKeys is the step that actually throws out the old keys and forces every user to sign in again. Without that rotation, anything an attacker grabbed during the window is still live.

Rotating the key ring is not the end of the cleanup either.

Some tokens live outside DataProtection entirely. API keys stored in the database, refresh tokens, password reset links that have not expired yet, email confirmation tokens. These are generated by the application itself and stored separately, so key rotation does not touch them. They have to be revoked and reissued one by one.

If the application ever stored secrets like database connection strings or third-party API keys inside a DataProtection payload, those should be treated as if an attacker could have read them out. Rotate those secrets where they originally came from, at the database, at the third-party service, wherever the real source is.

Microsoft did not wait for May’s Patch Tuesday to fix this one. 10.0.7 went out as an out-of-band release on April 21, outside the normal monthly patch cadence. That is a step Microsoft only takes when they do not want a known flaw sitting on the shelf waiting for the next scheduled release.

The story around this CVE is worth telling too.

On April 14, Microsoft published a denial of service advisory for a different package in the same ecosystem, and the standard vulnerability auditing tools started telling developers to upgrade their DataProtection references. On April 16, five days before CVE-2026-40372 became public, a developer on GitHub named nth-commit opened issue 66335 with the title CRITICAL BREAKING CHANGE in Microsoft.AspNetCore.DataProtection from 10.0.5 to 10.0.6. The issue came with a full reproduction showing that secrets protected by 10.0.5 could not be unprotected by 10.0.6, plus a stack trace pointing right at CalculateAndValidateMac, which is the exact function where the HMAC flaw sits. That was the bug being visible to anyone reading GitHub issues, five days before Microsoft officially called it a security problem.

There is no public proof of concept circulating yet. Microsoft lists the exploit code maturity as unproven. CISA rates the vulnerability as automatable with total technical impact, which means that once someone writes working exploit code it can be fired at targets at scale without much manual work per victim. The absence of a public PoC is a small mercy and probably a temporary one given how much ASP.NET Core runs on the public internet.

Here is what actually reduces exposure right now.

• → Check the installed .NET runtime with dotnet --list-runtimes to see which versions are on the host. If Microsoft.AspNetCore.App 10.0.6 shows up on a Linux or macOS box, the primary configuration for this CVE is in scope. For apps targeting net462 or netstandard2.0 with a direct DataProtection NuGet reference, any version from 10.0.0 to 10.0.6 is in scope.

• → Inspect project dependencies with dotnet list package --include-transitive and look for Microsoft.AspNetCore.DataProtection or any package that pulls it in, such as the StackExchangeRedis, EntityFrameworkCore, AzureKeyVault, or AzureStorage variants.

• → Run dotnet list package --vulnerable --include-transitive to let the tooling flag the affected versions directly.

• → Upgrade with dotnet add package Microsoft.AspNetCore.DataProtection --version 10.0.7, rebuild, redeploy. For framework-dependent deployments, installing the .NET 10.0.7 runtime on the server is the equivalent step.

• → Once the patch is deployed, rotate the DataProtection key ring. The advisory includes a code snippet that calls RevokeAllKeys on IKeyManager with the current timestamp and a reason string, which marks every existing key as revoked and generates a fresh one on the next protect operation. Every user will need to sign in again and every anti-forgery token will be reissued. That is the intended cost.

• → Audit application-level long-lived tokens that were handed out through authenticated endpoints during the vulnerable window. API keys in the database, refresh tokens, password reset links, email confirmation tokens. These survive the key rotation and have to be dealt with in the application layer.

• → Review server logs for the attack signature described by Microsoft. The exploit pattern produces orders of magnitude more requests than normal against a single authenticated endpoint with varying cookie or query parameter values. Sustained high-volume traffic against one endpoint is the fingerprint to hunt for in retrospect.

• → For applications that stored long-lived secrets such as database connection strings or third-party API keys inside IDataProtector.Protect output, rotate those secrets at their source.

The fix Microsoft shipped in 2010 has been the foundation every ASP.NET authentication system was built on. Sixteen years of servers trusting that a valid signature means a real request. A regression in .NET 10 broke that trust for a week in April 2026, on every Linux and macOS host running 10.0.6. The signature check was still there. It just calculated the wrong bytes and threw the answer away before it could be compared to anything. And the server carried on, decrypting forged cookies as if they were the real thing, without raising a single alarm or logging a single error.

Going from a single forged cookie to full system compromise, finding the weak points in real applications, and thinking like an attacker at every step of the way is exactly what I cover in my ethical hacking course, including reconnaissance and OSINT, scanning and enumeration with Nmap, web application attacks with Burp Suite and SQLMap, exploitation with Metasploit, Linux and Windows privilege escalation, credential dumping with Mimikatz, Windows LOLBins, WiFi cracking, social engineering, and the full attack chain from initial access to persistence.

• → Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Source: Microsoft Security Advisory CVE-2026-40372 | dotnet/announcements