Notifications
Clear all
Topic starter
19/08/2026 3:59 pm
TL;DR: CVE-2026-40372 in ASP.NET Core lets unauthenticated attackers forge Data Protection payloads and impersonate privileged users, with Microsoft assigning it CVSS 8.1; CYCOGNITO notes the flaw also leaves issued tokens valid unless the Data Protection key ring is rotated. The issue turns signing trust into an access-control failure, so patching alone is not enough.
NHIMG editorial — based on content published by CYCOGNITO: Sample of assets impacted by ASP.NET privilege escalation vulnerability identified by the CyCognito Platform
By the numbers:
- Exposure in CYCOGNITO's sample is led by Industrials at 26.2% of observed assets.
- Energy contributes 17.4% of observed assets in the exposed sample.
Questions worth separating out
Q: What breaks when an application signs cookies or tokens incorrectly?
A: The application stops being a reliable authority for identity state.
Q: Why do signature-verification flaws create lasting access risk?
A: Because anything the application issues during the vulnerable window can remain legitimately signed after the code is patched.
Q: How can security teams tell whether a patch really closes this kind of issue?
A: They should verify the deployed runtime lineage, not just the source dependency declaration.
Practitioner guidance
- Rotate the affected Data Protection key ring Rotate the Data Protection key ring after upgrading so tokens minted during the vulnerable window cannot continue to validate.
- Revoke application-issued credentials created during exposure Identify refresh tokens, API keys, and password reset links issued while the vulnerable package was active, then revoke and reissue them through the application layer.
- Inventory transitive Data Protection dependencies Check whether Microsoft.AspNetCore.DataProtection is loaded directly or transitively through Redis, EF Core, Azure Key Vault, or Azure Storage integrations.
What's in the full article
CYCOGNITO's full analysis covers the operational detail this post intentionally leaves for the source:
- Affected package and deployment combinations, including Linux-hosted ASP.NET Core 10 runtime scenarios
- Patch and remediation notes for Microsoft.AspNetCore.DataProtection 10.0.7, including key-ring rotation guidance
- Log-review signals that help detect anomalous protected-payload probing before credential abuse persists
- The sample asset distribution across Industrials, Energy, and IT for teams prioritising exposure review
👉 Read CYCOGNITO's analysis of CVE-2026-40372 and ASP.NET Core privilege escalation →
ASP.NET Core signature verification flaw: what teams need to check?
Explore further
19/08/2026 4:36 pm
Signed-state trust is a governance boundary, not a formatting detail. Applications often treat cookies, antiforgery tokens, and reset links as if the cryptographic wrapper guarantees identity integrity. CVE-2026-40372 shows that when verification fails, the application itself becomes the issuer of attacker-controlled identity artefacts. That is an IAM problem because trust in signed state is part of authentication governance, not just application hygiene. Practitioners should classify signed artifacts as identity assets with explicit lifecycle control.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why hidden runtime trust paths are so hard to govern.
A question worth separating out:
Q: Who is accountable when an application-issued token can be forged?
A: Application owners, IAM teams, and platform security teams share accountability because the failure crosses cryptography, authentication, and lifecycle control. The relevant governance question is whether signed artifacts have revocation, ownership, and expiry controls that still work when the signing layer is compromised.
👉 Read our full editorial: ASP.NET Core signature verification flaw exposes privilege escalation risk
