What is CVE-2026-40372?
CVE-2026-40372 is an elevation of privilege vulnerability in ASP.NET Core caused by improper verification of cryptographic signatures in the Data Protection library. The flaw sits in the HMAC validation routine of the managed authenticated encryptor, where a defective comparison lets an attacker submit a forged payload that the application accepts as legitimately signed.
The vulnerability carries a CVSS v3.1 base score of 8.1 (Important), as assigned by Microsoft in the official advisory. Exploitation does not require prior authentication. An attacker only needs the ability to send HTTP requests to an affected endpoint and a sample protected payload, such as an authentication cookie issued to an anonymous session.
The practical impact is direct impersonation of privileged users. By forging Data Protection payloads with a specific HMAC structure, an attacker can craft authentication cookies, antiforgery tokens, or other protected artifacts that the application will treat as valid.
If the attacker uses a forged identity during the vulnerable window to trigger the application to issue additional credentials, such as API keys, session refresh tokens, or password reset links, those artifacts remain legitimately signed and continue to work after the host is patched unless the Data Protection key ring is rotated.
A secondary consequence is disclosure. The same defect that enables forgery also permits a padding-oracle style attack against stored protected payloads, which can decrypt data that the application placed inside IDataProtector.Protect output.
What assets are affected by CVE-2026-40372?
The vulnerability lives in Microsoft.AspNetCore.DataProtection NuGet package versions 10.0.0 through 10.0.6, fixed in 10.0.7. Two configurations are in scope. The primary affected population runs ASP.NET Core 10 applications on Linux, macOS, or any non-Windows operating system where the NuGet binary is actually loaded at runtime rather than the shared framework copy.
The secondary and smaller population consists of .NET Framework 4.6.2+ or netstandard2.0 consumers of the affected package, regardless of operating system.
In practice, an affected asset looks like any ASP.NET Core 10 web application or API hosted on a Linux container, Kubernetes pod, or managed Linux VM, particularly where the application was built as framework-dependent but pulls the Microsoft.AspNetCore.DataProtection NuGet package directly or transitively via common integrations such as StackExchangeRedis, EntityFrameworkCore, AzureKeyVault, or AzureStorage.
Many teams reach for these extensions to persist Data Protection keys across containers, which is exactly the deployment pattern where the vulnerable code path is loaded. Windows deployments, applications still on 8.0.x or 9.0.x, and framework-dependent net10.0 applications running with a shared framework version at or above the PackageReference are not affected.
The assets that tend to be internet-facing here are the application ingress endpoints themselves. Authentication cookies, antiforgery tokens, and state parameters are by definition reachable from the internet wherever the application is, which is why exposure tracks directly with the public attack surface rather than with any specific port or protocol.
What does our data show about exposure patterns?
Exposure in this set is led by Industrials at 26.2% of observed assets, with Energy contributing 17.4% and Information Technology another 12.8%.
Industrials leading the distribution is consistent with how .NET web applications land inside operational environments. Large industrial organizations run sprawling portfolios of internal tools, partner portals, contractor access points, and supervisory web applications, many of which are built on ASP.NET Core and deployed on Linux to sit alongside container platforms.
Turnover in contractors, mergers, and facility-level autonomy all push web application ownership outside central IT, which is the precise condition that leaves individual packages pinned to older versions while the vulnerable code path stays loaded in production.
The broader cross-sector pattern points to a Data Protection dependency that almost no team inventories. Applications reference the NuGet package indirectly through Redis, EF Core, or Azure integrations, which means the affected version can end up loaded at runtime without anyone explicitly choosing it. Exposure shows up in sectors that run many small Linux-hosted .NET services rather than those with a large single .NET footprint.
Are fixes available?
Yes. Microsoft published an out-of-band update on April 21, 2026 that ships the corrected validation routine. The fix is Microsoft.AspNetCore.DataProtection 10.0.7, and defenders should upgrade the NuGet package directly or ensure their shared ASP.NET Core framework version is at or above 10.0.7.
Patching the binary is necessary but not sufficient. Microsoft specifically recommends rotating the Data Protection key ring after upgrading. Any tokens an attacker induced the application to issue during the vulnerable window are legitimately signed and will survive the patch. RevokeAllKeys on the IKeyManager forces all users to reauthenticate and invalidates any antiforgery tokens in circulation.
For applications that issued long-lived artifacts such as API keys, refresh tokens, or password reset links via authenticated endpoints during the window, those artifacts must be rotated at the application layer. Key rotation alone does not invalidate them.
Teams should verify directly with their vendor or release notes, especially where the Data Protection package is consumed transitively through another library that has not yet cut a new release.
Are there any other recommended actions to take?
Audit any plaintext stored inside protected payloads and rotate those underlying secrets if long-lived data was placed inside IDataProtector.Protect output.
Review web server logs for anomalous request volume against endpoints that accept protected payloads: the padding-oracle component of this attack produces orders of magnitude more traffic per byte recovered than legitimate use.
Restrict anonymous issuance of Data Protection payloads where possible, and confirm that framework-dependent deployments are resolving the shared framework copy rather than the NuGet binary.
How can CyCognito help your organization?
CyCognito published an Emerging Threat Advisory for CVE-2026-40372 in the CyCognito platform and is actively researching enhanced detection capabilities for this vulnerability.
To learn how CyCognito can help your organization reduce external exposure and manage emerging threats more effectively, contact us to request a demo.
