How a routine security update disabled the integrity check protecting every login in a web framework used by hundreds of millions of apps

The Context

ASP.NET Core is Microsoft's open-source web framework, used to build everything from internal business tools to public-facing APIs and e-commerce platforms. The Data Protection library is the component responsible for one specific job: protecting sensitive data in transit between the server and the browser. Every time an ASP.NET Core application issues an authentication cookie, an antiforgery token, or a password reset link, the Data Protection library signs and encrypts it. When the browser sends that data back, the library verifies the signature before trusting the contents.

The Microsoft.AspNetCore.DataProtection package has approximately 976 million downloads on NuGet, Microsoft's package registry for .NET software. It is also a hidden dependency of dozens of other widely used packages, meaning many applications rely on it without a direct reference in their code.

The Attack, Phase by Phase

Phase 1: The Regression

On April 14, 2026, Microsoft released .NET 10.0.6 as part of its regular monthly Patch Tuesday cycle. A code change in the ManagedAuthenticatedEncryptor class introduced a subtle error: the method responsible for computing and validating the HMAC integrity tag was now computing it over the wrong bytes, then discarding the result instead of comparing it to the tag the sender provided.

The effect was total. The integrity check gating every decryption operation was no longer running. The server would accept any payload—forged or legitimate—as long as it was structurally well-formed.

Within hours, developers reported decryption errors after upgrading to 10.0.6 and filed reports on GitHub issue #66335. At this stage, the problem looked like a bug, not a security incident.

Phase 2: How the Vulnerability Worked

Once the HMAC check was broken, two distinct attacks became possible.

The first is cookie forgery. An attacker captures any authentication cookie, decodes the Base64-encoded blob, changes embedded identity claims (for example, "Role: User" to "Role: Administrator"), and overwrites the final 32 bytes—where the HMAC tag lives—with null bytes. The broken server runs its non-functional validation routine, gets no error, and grants full administrative access.

The second attack is a padding-oracle. By sending thousands of slightly modified encrypted payloads and observing how the server responds differently to each one, an attacker can reverse-engineer the original plaintext one byte at a time. This works on any DataProtection-protected value: authentication cookies, antiforgery tokens, OpenID Connect state parameters, and any application data protected with the library.

Phase 3: Escalation and Persistence

Once logged in as an administrator via a forged cookie, the application behaves normally—issuing the attacker real tokens: session refresh tokens, API keys, password reset links. These are signed with the application's actual DataProtection key ring and are cryptographically identical to tokens issued to legitimate users.

When Microsoft ships the fix on April 21, 2026, those tokens do not expire. The patch restores the HMAC check, so new forged cookies are rejected. But tokens the attacker already holds were issued legitimately by the application and remain valid until they expire naturally or the key ring is explicitly rotated.

Phase 4: Remediation and the Key Rotation Requirement

Upgrading to .NET 10.0.7 restores the correct HMAC comparison. Forged all-zero payloads now trigger a CryptographicException and are rejected. But patching alone does not close the window.

To fully remediate, defenders must rotate the DataProtection key ring by calling RevokeAllKeys on the IKeyManager interface. This invalidates every token the application has ever issued—including any the attacker obtained during the vulnerable window—and forces all users to log in again. For applications running in Docker containers, the vulnerable package may be compiled into the image itself; updating the host runtime is not enough. Long-lived artifacts such as API keys and password reset links stored in databases must also be rotated at the application layer.

What Made This Possible

1. A security update was itself the attack surface. The vulnerability did not exist before April 14, 2026. The regression came from Microsoft's own release—no external attacker planted the code.

2. The failure was silent. The broken HMAC check produced no errors when accepting forged payloads. The only observable symptom was decryption failures on legitimate payloads, which looked like a bug. No alert, no log entry flagged the integrity check as non-functional.

3. Patching and remediation are not the same thing in cryptographic systems. Most patch management workflows treat "update the binary" as the end state. In systems that issue signed tokens, the binary is only one part of the trust chain. The key ring, issued tokens, and container images are separate artifacts that must be addressed independently.

What Should Have Stopped This

No single defense here depends on the DataProtection library's own integrity to function—every control operates outside the compromised component.

• Anomaly detection on authentication patterns. A padding-oracle attack requires thousands of requests per byte recovered. Rate-limiting or log analysis on authentication endpoints would have flagged the attack in progress.
• Short token lifetimes. Tokens expiring in minutes rather than hours limit how long an attacker's legitimately issued tokens remain useful after key rotation.
• Automated key rotation policies. Organizations rotating their key rings on a regular schedule reduce the persistence window without needing to know about the vulnerability first.
• Container image scanning tied to the patch cycle. Scanning deployed images for known-vulnerable package versions surfaces exposure in containerized environments where host-level patching is insufficient.

The Takeaway

This attack belongs to the same failure class as the Stryker Intune wipe: a trusted system component turned against the organization it was built to protect. In the Stryker case, the weapon was a legitimate device management tool. Here, it is a legitimate security library. The meta-pattern is identical: the attacker does not need to break in when the trusted component has already been broken for them.

The comparison Microsoft draws to MS10-070—a 2010 emergency patch for a padding-oracle vulnerability in ASP.NET's legacy cryptographic infrastructure—is worth sitting with. The same class of failure, an integrity check that can be silently bypassed, has recurred across 16 years and multiple generations of the same framework.

Pattern to remember: A security update that disables an integrity check is indistinguishable from an attack until someone reads the code.

What changed: The patch cycle is now a confirmed delivery mechanism for cryptographic regressions, meaning defenders must verify that a security update preserved the integrity guarantees it was meant to strengthen—not just that it shipped.

The Technical Mechanism

The vulnerability is a regression in the ManagedAuthenticatedEncryptor class within the Microsoft.AspNetCore.DataProtection.Managed namespace. This class implements authenticated encryption using AES-256-CBC for confidentiality and HMACSHA256 for integrity. It is the default encryptor on Linux and macOS, and on Windows when UseCustomCryptographicAlgorithms is explicitly configured to use managed (non-CNG) algorithms.

The defect lives in the CalculateAndValidateMac method. In versions 10.0.0 through 10.0.6, the method computes the HMAC tag over an incorrect byte offset within the payload buffer. It then discards the computed hash rather than performing a comparison against the tag embedded in the incoming payload. The result is that the method returns without raising a CryptographicException regardless of what the payload's HMAC section contains.

Cookie forgery exploit path:

1. Attacker obtains any DataProtection-protected payload (authentication cookie, antiforgery token, OIDC state parameter).
2. Attacker Base64-decodes the blob and locates the embedded claims (e.g., NameIdentifier, Role).
3. Attacker modifies the claims to elevate privilege.
4. Attacker overwrites the final 32 bytes of the payload (the HMAC section) with 0x00 null bytes.
5. Attacker resubmits the modified payload.
6. The broken CalculateAndValidateMac routine encounters the null-byte HMAC and returns success.
7. The server decrypts the modified claims, instantiates a new ClaimsPrincipal, and grants elevated access.

Padding-oracle exploit path:

1. Attacker captures any DataProtection-protected ciphertext.
2. Attacker submits crafted variants with single-byte modifications to the ciphertext.
3. Attacker observes differential server responses: distinct error messages or measurable timing differences indicate whether the modified block decrypted to valid padding.
4. Attacker iterates byte-by-byte to recover the full plaintext without the key.
5. The advisory notes this requires orders of magnitude more requests than normal traffic, making it detectable via log volume analysis.

The fix in 10.0.7 replaces the broken comparison with a strict, unconditional constant-time comparison between the computed HMAC and the provided HMAC. Any deviation, including an all-zero sequence, now raises a CryptographicException and halts decryption.

Post-patch persistence: Tokens issued to an attacker during the vulnerable window (April 14 to April 21) are signed with the real key ring and remain valid after upgrading to 10.0.7. Full remediation requires calling RevokeAllKeys on IKeyManager to rotate the key ring. For containerized deployments, the vulnerable NuGet binary may be embedded in the application image; host runtime patching is insufficient without a full image rebuild.

CWE classification: CWE-347 (Improper Verification of Cryptographic Signature).

CVE and Advisories

• CVE-2026-40372: ASP.NET Core Elevation of Privilege Vulnerability. CVSS score: 9.1 (Critical). NVD status: awaiting enrichment as of research date.
• GHSA-9mv3-2cwr-p262: GitHub Security Advisory, published April 22, 2026.
• Microsoft Security Advisory (dotnet/announcements #395): Primary vendor advisory, published April 21, 2026.
• Microsoft .NET Blog: .NET 10.0.7 Out-of-Band Security Update: Patch release announcement, published April 21, 2026.

Affected versions: Microsoft.AspNetCore.DataProtection 10.0.0 through 10.0.6.

Fixed version: Microsoft.AspNetCore.DataProtection 10.0.7.

Not affected: .NET 8.x and 9.x servicing branches (the regression was never backported). Windows applications using the default shared framework CNG implementation (unless UseCustomCryptographicAlgorithms is configured).

Transitive dependency exposure: Microsoft.AspNetCore.DataProtection.StackExchangeRedis, .EntityFrameworkCore, .AzureKeyVault, .AzureStorage, .Redis. Use dotnet nuget why Microsoft.AspNetCore.DataProtection to identify direct and transitive references.

MITRE ATT&CK Mapping

Indicators of Compromise

Log indicators (legitimate regression symptoms, not attack-specific):

• Repeated The payload was invalid errors in ASP.NET Core application logs following upgrade to 10.0.6. These indicate the vulnerable binary is loaded and the decryption regression is active.
• Sudden mass user logouts or session invalidation errors after April 14, 2026.

Behavioral indicators (potential exploitation):

• Anomalous authentication request volume: padding-oracle attacks require orders of magnitude more requests per byte than normal traffic. Spikes in POST requests to authentication endpoints with high error rates are a detectable signal.
• Privilege escalation events in application audit logs: accounts accessing administrative functions without a corresponding login event from a privileged credential.
• Session tokens or API keys issued during the April 14 to April 21 window that remain active after patching, particularly for accounts that did not exist or were not privileged before that window.

Detection limitation: Cookie forgery attacks that do not trigger the padding-oracle path may generate no anomalous log volume. A single forged cookie submitted once produces no detectable signal beyond the resulting privileged session activity.

Attribution

The vulnerability is a regression introduced by Microsoft's own engineering team during the .NET 10.0.6 Patch Tuesday release cycle. It is not the result of a supply chain compromise or external code injection. An anonymous researcher discovered the security implication of the regression and reported it to Microsoft via the MSRC Researcher Portal under the Microsoft .NET Bounty Program. Microsoft credited the researcher on April 21, 2026. No threat intelligence firm has attributed active exploitation to any known threat actor or nation-state as of the research date. No confirmed in-the-wild exploitation has been reported, though at least three public proof-of-concept repositories linked to the CVE were available on GitHub as of April 26, 2026.

Primary Sources