ASP.NET Core signature verification flaw exposes privilege escalation risk

At a glance

What this is: This is an ASP.NET Core elevation-of-privilege flaw that lets attackers forge protected payloads and impersonate users through broken HMAC verification.

Why it matters: It matters because application-layer signing defects can bypass IAM assumptions, create fraudulent sessions, and leave privileged artifacts valid after patching.

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.

👉 Read CYCOGNITO's analysis of CVE-2026-40372 and ASP.NET Core privilege escalation

Context

CVE-2026-40372 is a signature-verification failure in ASP.NET Core that turns protected data into a trust problem. When an application accepts forged authentication cookies, antiforgery tokens, or other signed artifacts, the control plane for identity effectively collapses into the application’s own parsing logic.

That matters to IAM and application-security teams because the weakness sits at the boundary between authentication, session handling, and token issuance. It can also affect machine or service workflows when applications mint API keys or refresh tokens during the vulnerable window, which is a familiar failure mode in modern identity and workload architectures.

The asset profile described by CYCOGNITO is not unusual for Linux-hosted .NET services that rely on shared Data Protection components and transitive package loading. That pattern makes the bug most relevant wherever application runtime identity is assumed to be trustworthy by default.

Key questions

Q: What breaks when an application signs cookies or tokens incorrectly?

A: The application stops being a reliable authority for identity state. Attackers can forge cookies, antiforgery tokens, or other protected artifacts that the app accepts as valid, which turns a cryptographic defect into session impersonation and downstream credential abuse. Treat the signed artifact as compromised and revoke what it enabled.

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. If that output includes refresh tokens, API keys, or password reset links, the attacker may keep using them until the artefacts are explicitly revoked or rotated.

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. In framework-driven stacks, the vulnerable component may be bundled through a meta-framework, so the effective fix is the version that pulls in the patched parser. Build artefacts and production images are the evidence that matters.

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.

Technical breakdown

How broken HMAC verification turns signing into forgery

ASP.NET Core Data Protection is designed to encrypt and authenticate state so the application can later confirm that a payload was both unmodified and legitimately issued. In CVE-2026-40372, the HMAC comparison in the authenticated encryptor fails to validate the signature correctly, which means a forged payload can pass as authentic. That shifts the attacker’s problem from key theft to structure matching. Once the crafted blob is accepted, the application treats attacker-supplied identity material as genuine.

Practical implication: treat this as a token authenticity failure and rotate the affected key ring, not just the package version.

Why forged cookies and reset links survive a patch

The most dangerous consequence is persistence of artifacts issued while the application was vulnerable. If the attacker uses a forged identity to trigger issuance of refresh tokens, API keys, or password reset links, those outputs are legitimately signed by the application itself. Patching the runtime fixes future validation, but it does not invalidate artifacts already minted under compromised trust. That makes the vulnerability closer to a signing compromise than a simple code defect.

Practical implication: invalidate and reissue any credentials or recovery artifacts created during the exposure window.

How the padding-oracle path can disclose protected data

The same defect also enables a padding-oracle style attack against stored Data Protection payloads. In practice, the attacker can probe the application with crafted requests and infer information from the response patterns until they recover plaintext contained inside IDataProtector.Protect output. This is a confidentiality failure layered on top of the identity failure. The impact depends on what developers stored inside protected payloads, which is why application design choices matter as much as patch status.

Practical implication: review what data was stored in protected payloads and rotate any underlying secrets that were embedded there.

Threat narrative

Attacker objective: The attacker wants to impersonate trusted users, mint durable credentials, and recover protected application data without needing prior authentication.

1. Entry occurs when an unauthenticated attacker sends HTTP requests to an affected ASP.NET Core endpoint with a sample protected payload, such as an anonymous-session cookie.
2. Escalation happens when the forged HMAC structure is accepted as valid, allowing impersonation of privileged users and the minting of legitimate application-issued artifacts.
3. Impact follows when the attacker uses those artifacts to preserve access, trigger downstream token issuance, or decrypt protected payloads that should have remained confidential.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Token authenticity failures create a standing-privilege window even after patching. The attack is not limited to the moment of exploitation. Anything legitimately issued during the vulnerable period can continue to work until it is revoked or rotated, which is the same governance failure pattern seen in compromised non-human identities and long-lived service credentials. The broader lesson is that patching, revocation, and key rotation are separate controls. Teams should design for revocability as part of identity control.

Application-issued credentials now behave like non-human identities and deserve the same lifecycle discipline. If an application can mint API keys, refresh tokens, or reset links, those objects should be governed as NHI assets with ownership, expiry, and revocation paths. This is the named concept here: signed-artifact persistence, meaning attacker-induced outputs remain trustworthy because the application itself signed them. Practitioners should map these artefacts into identity inventory and offboarding processes.

Linux-hosted .NET estates expose an identity inventory gap as much as a patching gap. CYCOGNITO's asset pattern shows how transitive package loading through Redis, EF Core, or Azure integrations can hide the vulnerable code path from teams that think in terms of applications rather than dependencies. That weakens control assurance across cloud and application estates. Practitioners should re-evaluate dependency discovery and runtime validation as part of identity security governance.

Confidentiality loss here is a by-product of broken authentication, not a separate bug class. The padding-oracle path matters because many teams still store sensitive values inside protected payloads, assuming Data Protection makes the data safe. When the protection layer itself is compromised, the boundary between token security and data protection disappears. Practitioners should stop treating application protection libraries as passive utilities and manage them as part of the trust stack.

From our research:

• 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.
• Next: Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs shows how to tie rotation, revocation, and offboarding to identity governance.

What this signals

Signed-artifact persistence is the operational risk most teams miss. When an application can mint credentials or recovery links, those outputs need the same lifecycle controls as service accounts because they can outlive the patch that fixed the bug. The governance response is to connect application signing trust to identity inventory and revocation processes, not to treat it as a one-off vulnerability response.

The practical signal for IAM and appsec teams is that key rotation, session invalidation, and application-layer credential revocation must be designed together. Guidance from NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls aligns with that view: authentication assurance is only durable when validation, monitoring, and revocation are all present.

Teams should expect more defects where dependency loading, containerised .NET deployments, and transitive packages hide the actual trust boundary. The right programme response is to inventory where signed application state is created, where it is stored, and who can revoke it before attackers turn it into a durable access path.

For practitioners

• 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. Use forced reauthentication where practical to collapse any existing session trust.
• 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. Key rotation alone does not invalidate these artefacts.
• 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. Confirm the runtime is resolving the fixed shared framework or package version.
• Audit protected payload contents Review whether plaintext secrets or long-lived sensitive values were placed inside IDataProtector.Protect output. Rotate any underlying secrets if protected payloads contained data that should no longer be trusted.

Key takeaways

• CVE-2026-40372 turns ASP.NET Core token validation into an identity trust failure because forged signed artifacts can impersonate users.
• Patching alone is incomplete because credentials and recovery links issued during the vulnerable window may remain valid until they are revoked or rotated.
• Teams need to govern signed application outputs like identity assets, with inventory, key rotation, revocation, and payload-content review.

Key terms

• Data Protection key ring: A Data Protection key ring is the set of cryptographic keys an application uses to encrypt and authenticate protected state such as cookies or tokens. If the ring is not rotated after compromise, attacker-induced artifacts can remain valid even after the software defect is patched.
• Signed artifact persistence: Signed artifact persistence is the condition where credentials or recovery links created during a compromise remain trusted after the original flaw is fixed. The application itself issued the artifact, so downstream systems continue to accept it unless revocation, rotation, or invalidation is explicitly performed.
• Padding oracle attack: An attack that uses differences in how a system responds to malformed encrypted data to recover plaintext or forge valid ciphertext. The key weakness is not the encryption algorithm alone, but the error handling or timing behaviour that leaks enough information for an attacker to reconstruct trusted messages.
• Authenticated encryptor: An authenticated encryptor is a cryptographic component that encrypts data and adds integrity protection so the receiver can verify the payload was not altered. When the integrity check fails, the application can no longer trust that the payload was issued by a legitimate source.

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

👉 CYCOGNITO's full post covers the vulnerable package scope, token persistence, and remediation steps in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management. It helps practitioners connect application-issued credentials to the controls that keep identity programmes defensible.