Microsoft rushed an out-of-band ASP.NET Core patch. If you shipped between April 14 and April 21, you need to rebuild.

Microsoft shipped an out-of-band .NET 10.0.7 release on April 21 to fix CVE-2026-40372, a CVSS 9.1 flaw the April 14 Patch Tuesday accidentally introduced into ASP.NET Core’s Data Protection library. Authentication cookies and tokens on affected apps can be forged. Every Linux and macOS deployment that updated in that week is exposed until rebuilt on 10.0.7.

What broke

The bug is in Microsoft.AspNetCore.DataProtection, the NuGet package that ASP.NET Core apps use to sign and encrypt cookies, tokens, and other at-rest secrets. Microsoft’s own write-up is blunt about the mechanism: “the managed authenticated encryptor could compute its HMAC validation tag over the wrong bytes of the payload and then discard the computed hash, which could result in elevation of privilege.” In practice, that means validation tags were being computed off an incorrect offset, so forged cookies pass the integrity check.

BleepingComputer and CSO Online both put the risk as unauthenticated remote privilege escalation: an attacker who can forge a validated cookie can impersonate any user whose session the app signs with Data Protection. On default Linux and macOS configurations, the managed code path is the one in use, which is why non-Windows deployments are the primary blast radius. Windows hosts only hit the bug if the app explicitly opted into UseCustomCryptographicAlgorithms.

Who’s exposed, and who isn’t

The pattern here is familiar: the patch that introduced the regression was 10.0.6, released as part of the April 14 Patch Tuesday cycle. Any ASP.NET Core app that updated to 10.0.6 between April 14 and April 21 and hasn’t bumped to 10.0.7 is vulnerable. Long-lived hosts on automatic server updates will pick up 10.0.7 on their own, but Docker-based deployments are the landmine. If you built an image on top of dotnet/aspnet:10.0.6 or any base tag that resolved to 10.0.6 during that window, the image carries the vulnerable runtime and will keep doing so until rebuilt.

Self-contained app deployments are in the same boat. The runtime is bundled, so OS-level update channels don’t help you. You rebuild or you stay exposed.

Apps pinned below 10.0 aren’t affected. The regression was introduced inside the .NET 10 track specifically. If you’re still on 8.x or 9.x LTS, you’re fine on this particular CVE, though you have your own upgrade horizon to worry about.

How to fix, in order of urgency

Read Microsoft’s advisory for the full matrix, but the short version:

• Docker / self-contained builds: bump your base image to the 10.0.7-tagged runtime and rebuild. Re-push. Redeploy. Don’t wait for a staged rollout; the window between Patch Tuesday and the out-of-band fix is exactly the period where production traffic may have been signing cookies with a compromised HMAC.
• Framework-dependent apps on Linux/macOS: updating the installed runtime to 10.0.7 is enough. Restart the app so the new bits load.
• Windows apps: only at risk if you wired UseCustomCryptographicAlgorithms into the DI container. If you did, same update path: bump to 10.0.7.
• Anyone who signed anything sensitive during the window: consider rotating Data Protection keys after the upgrade. The forged-cookie path relied on the HMAC check being wrong, not on key exfiltration, so new keys aren’t mandatory. But if you have a high-value surface (finance, healthcare, admin consoles), a rotation is cheap insurance.

What this means for you

The last week of ASP.NET news is a small education in how .NET regressions land in production. A Patch Tuesday in .NET isn’t OS-level; the runtime has to be rebuilt into your image or installed into your host. That’s usually a safety feature, but when the patch itself ships the bug, the same mechanism slows the fix.

If you ship ASP.NET on Linux or macOS, the single highest-payoff move this week is to scan your running images for the 10.0.6 runtime and rebuild. docker inspect your running containers. Grep the labels. Rebuild anything that’s stale. It’s 20 minutes of work compared to the days you’d spend rotating every session in your identity store if a forged-cookie incident ever hit the access logs.

Also worth doing: write yourself a note for the next time Microsoft’s runtime ships with a critical regression. Two quick wins are alerting on new .NET CVEs inside your SIEM (most don’t today) and keeping a one-command rebuild path for your production images. Both are cheap. Neither happens after you need them.