A single miscalculated integrity tag in core web cryptography created a fault line through identity and session security, and the resulting ripple effects demanded more than a routine patch cycle to contain the blast radius across modern application estates. Microsoft assigned CVE-2026-40372 with a CVSS score of 9.1 to a regression in ASP.NET Core’s Data Protection library that let forged cookies and tokens pass authenticity checks and, in some circumstances, enabled decryption of protected payloads. An out-of-band fix landed quickly as version 10.0.7, yet the remedy did not end at the server host. Containerized builds and self-contained deployments commonly embed the vulnerable assembly; closing the gap required rebuilding those apps, expiring issued tokens and cookies, and rotating Data Protection keys. The incident raised urgent questions for engineering leaders: which services linked 10.0.6, which images shipped after April 14, and how quickly could tokens be invalidated without derailing users.
What Changed and Why It Matters
The turning point arrived with the .NET 10.0.6 release on April 14, when a regression altered how the ManagedAuthenticatedEncryptor computed the HMAC validation tag. By using the wrong offset during calculation, the library weakened the authenticity barrier that guards protected data. Because ASP.NET Core Data Protection underpins authentication cookies, anti-forgery tokens, TempData, and OIDC state, any bypass of tag verification strikes at the heart of account integrity and session trust. Microsoft moved fast with 10.0.7, but the patch told only part of the story. Windows systems relying on default platform cryptography were less likely to be at risk, yet environments that explicitly opted into managed algorithms—such as via UseCustomCryptographicAlgorithms—remained in scope. In effect, a small arithmetic error in a critical validator expanded into a platform-wide concern.
Understanding why this mattered required a short detour into how HMAC binds data to an integrity key and prevents undetected tampering. The offset bug meant the library could compute and compare the tag against the wrong slice of bytes, letting some manipulated payloads appear valid. That misstep not only permitted forgeries to pass checks but, in edge cases, also allowed decryption of content that should have stayed opaque. During the vulnerable window, a determined attacker could coax an application into minting brand-new, fully valid artifacts—session refresh tokens, password reset links, even API keys—that would outlive the flaw itself. Moreover, simply updating a host runtime was ineffective for many teams, because container images and self-contained deployments carried their own copy of Microsoft.AspNetCore.DataProtection; only a fresh build actually pulled in 10.0.7.
Who Is Affected and How to Tell
Exposure crossed operating systems. Linux and macOS builds that consumed the flawed package were impacted outright, and Windows workloads faced risk when developers enabled managed algorithms rather than deferring to platform cryptography. Packaging choices widened the footprint: projects consuming the 10.0.x NuGet with netstandard2.0 or net462 assets—often selected to ensure compatibility with older frameworks and OS baselines—brought the vulnerable code into places that might not otherwise run the newest runtime. The effect multiplied inside Docker-based pipelines, where “restore, build, publish” stages pinned dependencies into images. In those scenarios, a VM or node agent patched to 10.0.7 did not inoculate workloads because the application itself shipped the 10.0.6 bits inside its container layer.
There were practical signals to separate theory from impact. Many teams observed users unexpectedly logged out after the upgrade, or saw “The payload was invalid” appearing in application logs as tamper checks rejected cookies and tokens protected under mixed logic during rollouts. Dependency auditing offered a faster path to certainty: scanning project files for Microsoft.AspNetCore.DataProtection, or running “dotnet list package” in solution roots, revealed whether version 10.0.6 had been resolved. Security staff also scrutinized telemetry for unusual token issuance, spikes in successful authentications from atypical networks, repeated integrity errors, and anomalies in OIDC state processing. Builds and image tags dated after April 14 warranted special attention. Even without confirmed exploitation, the combination of silent forgery potential and long-lived tokens justified a thorough, time-bounded review.
Action Plan and Broader Lessons
Remediation started with upgrading to 10.0.7, then immediately rebuilding and redeploying any ASP.NET Core application created or rebuilt since April 14, with a special focus on Docker images and self-contained publishes. Teams expired and invalidated authentication cookies, password reset links, and other artifacts protected under the faulty logic, then rotated Data Protection keys so that new tokens bound to known-good material. Inventory work proved decisive: mapping services that reference the Data Protection library, linking them to CI pipelines, and confirming that base images and locks had advanced ensured full coverage. Program managers paired rebuilds with guardrails—staged canaries, pre-prod integrity tests that verify HMAC behavior, and automated rollbacks—so that future regressions could be caught early without slowing delivery.
This episode also sharpened perspective on platform risk. Cryptographic regressions have history—MS10-070 (CVE-2010-3332) offered an early lesson on how minute validation errors metastasize—and the recent Kestrel flaw (CVE-2025-55315, CVSS 9.9) reinforced that mature stacks still suffer sharp edges. Effective teams treated this event as a lived drill: they mandated forced rebuilds when critical NuGet defects appeared, codified key-rotation SLAs, and established scripts to mass-expire tokens with graceful user messaging. Pipelines gained provenance checks and reproducible builds; monitoring added queries for logout storms and integrity-failure clusters; deployments adopted canaries by default. By the time 10.0.7 propagated, action had shifted from hotfixing to hardening, and the path forward centered on inventory accuracy, rebuild agility, and practiced credential hygiene rather than trust in any single patch.
