PatchDay Alert

Editorial coverage · CVE-2026-40372

Patch CVE-2026-40372, then rotate the keys

The ASP.NET Core DataProtection fix stops new forged payloads. It does not clean up the tokens your app may have issued while the vulnerable code was live.

Editorial CVE · 2 min read By The Field Notes Desk · Field Notes

What we say

The package update is the visible part of this CVE. It is not the hard part.

What dotnet add package does for you: replaces the vulnerable Microsoft.AspNetCore.DataProtection 10.0.6 with 10.0.7 and the runtime underneath. New protected payloads — cookies, tokens, OIDC state — are generated by code that validates HMAC correctly.

What the package update does not do: revoke any payload that the app already issued while 10.0.6 was the active runtime. Those payloads were signed by a key ring the vulnerable code accepted, and the post-patch runtime accepts the same key ring by default. A token forged during the window — or a cookie that should never have validated — keeps validating until either the key it depends on is gone from the active ring or the token expires on its own schedule.

The advisory does not say “rotate the keys.” The package release notes do not say “rotate the keys.” dotnet list package --vulnerable clears once the package version is past the fixed range, and the dashboard turns green. That is the trap.

What “rotate” actually means in DataProtection terms: generate a new key in the ring, mark the prior keys as no longer the default activation key, and — for the tokens you cannot trust — revoke them outright. For an app sitting behind a single load balancer, that is a key-ring rotation plus a forced re-sign for active sessions. For an app sitting behind a shared key ring across multiple deployments (a common pattern), the rotation also has to coordinate across every node that reads the ring.

This is the operator action item the patch advisory was silent on, and it is why every internet-facing ASP.NET Core app that updated to 10.0.6 deserves a key-rotation ticket alongside the upgrade ticket. The package list shows you patched. It does not show you cleaned up after the bug.

What NVD says

CWE-347 — improper verification of a cryptographic signature. Base score 9.1, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. The NVD entry names the integrity and confidentiality impact but does not enumerate the surfaces inside ASP.NET Core that depend on DataProtection (auth cookies, antiforgery tokens, OIDC state, TempData), which is where the practical exposure is.

NVD entry →

What the vendor says

Microsoft shipped .NET 10.0.7 out of band on April 21, 2026 after decryption failures in apps that had updated to 10.0.6 surfaced the regression. The advisory recommends installing 10.0.7 and notes a security regression in DataProtection where the HMAC validation tag could be calculated over the wrong bytes and discarded. It does not direct operators to rotate the DataProtection key ring or revoke tokens issued during the vulnerable window — the gap is the entire post-patch remediation step.

Compliance impact

SOC 2
Common Criteria CC6 (logical access) and CC7 (system operations) read patch state as a binary: the package version is past the fixed range, the control evidence shows the upgrade ticket, the auditor moves on. Neither control narrative carries a field for 'tokens issued under the vulnerable runtime are still authenticating today.' The trust boundary CC6.1 names — who has access to what, established through which credentials — depends on whether a forged cookie minted on April 20 still validates on April 22. The package list cannot answer that question. The honest CC7.1 evidence is the key-ring rotation ticket, the forced re-sign event, and the timestamp on which long-lived tokens were revoked.
HIPAA
§164.308(a)(1)(ii)(B) risk analysis has to account for the residual-state problem, not just the package version. A covered entity running an ASP.NET Core app that touched ePHI through DataProtection-backed auth between the 10.0.6 install and the 10.0.7 install must evaluate whether tokens issued during that window remained valid afterwards — the analysis is not 'we patched the package' but 'we patched the package and revoked the credentials that were issued under the vulnerable code path.' §164.312(c)(1) integrity controls also reach this surface: the HMAC validation regression is exactly the kind of integrity failure the Security Rule expects technical safeguards to detect and remediate, and the remediation is the rotation, not the upgrade.

Sources

Every source on this list has been read by the editorial team. We do not cite something we have not opened.

Deeper read

Coverage in PatchDay Alert

View all posts tagged #cve-2026-40372 →

One email, every weekday morning.

You're in. Check your inbox.

Get the digest

Free. Weekday mornings. Plain English CVE triage.

Check your inbox to confirm.