Microsoft pushed an out-of-band fix on April 22 for CVE-2026-40372, a critical (CVSS 9.1) elevation-of-privilege bug in Microsoft.AspNetCore.DataProtection. The vulnerability is an improper verification of cryptographic signature on protected payloads, which means an unauthenticated attacker reachable over the network can forge authentication cookies, anti-forgery tokens, OIDC state blobs, password-reset links, or any other artifact the application protects with the DataProtection stack.

For most ASP.NET Core deployments — Identity, cookie auth, session middleware, signed URLs, persistent state for OIDC handlers — DataProtection is the load-bearing primitive. A signature-bypass there is functionally a master key.

What’s affected

Microsoft.AspNetCore.DataProtection NuGet packages 10.0.0 through 10.0.6. The fix is in 10.0.7. The vulnerable package is dragged in transitively by Microsoft.AspNetCore.App 10.0.0–10.0.6 and the broader Microsoft.AspNetCore.Identity.* family, so most apps on .NET 10 GA built before April 22 are exposed.

The flaw lives in the verification path that decides whether a signed payload is authentic. Microsoft has been quiet on the implementation specifics — typical for an actively-fielded auth bypass — but the practical effect is that an attacker can submit a forged payload and have the framework accept it as one issued by the server’s own key ring. From there it’s an authenticated-session impersonation against any privileged user the attacker chooses.

The dangerous property of DataProtection bugs is the lateral blast radius across feature surfaces that share the key ring. An app that uses DataProtection only for cookie auth still uses it for:

  • Anti-forgery tokens (CSRF protection — silently bypassed)
  • OIDC state and nonce round-tripping
  • ASP.NET Core Identity password-reset and email-confirmation tokens
  • Anything wrapped via IDataProtector.Protect(...) in app code (signed URLs, opaque IDs, encrypted query strings)

A forged auth cookie is the obvious abuse path. The subtler one is forging a password-reset token for an admin account, then walking through the legitimate reset flow — no session needed, no audit trail beyond a “successful” reset.

The patching trap: 10.0.7 doesn’t invalidate tokens issued before 10.0.7

This is the part to internalize. Upgrading to 10.0.7 closes the verification flaw, but any tokens an attacker forged or coaxed the server into issuing during the exposure window remain valid after upgrade. They were minted by the same key ring; the patch doesn’t retroactively reject them.

Concretely: if an attacker exploited the bug to forge a cookie, used that forged session to trigger a “Generate API key” or “Send password reset link” flow, then captured the resulting token — that token is a legitimate, server-signed artifact and the new build will happily accept it. Same for any session refresh tokens, long-lived API keys, or password-reset URLs the server emitted under attacker influence.

The mitigation is to rotate the DataProtection key ring after upgrading. New keys invalidate every payload signed under the old keys, including the legitimately-signed ones the attacker harvested. Whatever currency that broke during the rotation (active sessions, in-flight reset emails) is the cost of closing the door.

What to do right now

  1. Pin every project to Microsoft.AspNetCore.DataProtection 10.0.7 (or the matching Microsoft.AspNetCore.App 10.0.7 runtime). Check transitive dependencies — the package gets pulled in via Identity and the metapackage even when you don’t reference it directly.
  2. Restart all instances. DataProtection caches the verification path; old workers stay vulnerable until they restart.
  3. Rotate the DataProtection key ring. For apps using the file-system or Redis key repository, mint a new key, push it as the default, and revoke the prior keys once you’ve confirmed rollover. For Azure Key Vault or DPAPI-NG persistence, follow the equivalent rotation procedure for that backing store.
  4. Review auth and provisioning logs from April 22 backwards for anomalous resets, API-key creations, OIDC sign-ins from unusual geographies, or admin actions that don’t match a known user session. There is no clean IOC for this — you’re looking for actions that succeeded but lack a corresponding legitimate auth event.
  5. Force re-authentication and re-consent on any session created or renewed during the exposure window.

If you’re running a multi-tenant ASP.NET Core platform, consider this an incident-response exercise per tenant rather than a patch deployment. The “patch and move on” playbook leaves forged tokens live.

References