CVE-2026-40372, ASP.NET Core Data Protection Failure and What to Rotate Now

CVE-2026-40372 landed in the public record on April 21, 2026 with a Microsoft CNA CVSS 3.1 score of 9.1, while NVD still lists the entry as awaiting enrichment. Within the same window, Microsoft shipped .NET 10.0.7 as an out-of-band security update after reports that .NET 10.0.6 was already breaking decryption in some applications. That combination matters. This was not a routine “update when convenient” package bump. It was a regression that first showed up as application breakage and then turned out to undermine the trust guarantees behind ASP.NET Core Data Protection. (NVD)

Microsoft’s own advisory is more revealing than the short CVE line. In affected configurations, a bug in Microsoft.AspNetCore.DataProtection 10.0.0 through 10.0.6 can let an attacker forge authentication cookies and decrypt some previously protected payloads. Microsoft also warns that if forged payloads were used to authenticate as a privileged user during the vulnerable window, the application may have issued legitimate long-lived artifacts such as refresh tokens, API keys, or password reset links, and those artifacts do not automatically die just because the package was upgraded. (GitHub)

That is why CVE-2026-40372 deserves more than a “patch now” headline. It sits under a security primitive that ASP.NET Core uses for authentication, antiforgery, TempData, session-related protections, and other stateful trust decisions. If the server stops reliably distinguishing authentic protected data from attacker-controlled ciphertext, the bug stops being a narrow cryptography issue and becomes a trust-boundary failure inside the web stack. (learn.microsoft.com)

What CVE-2026-40372 breaks in ASP.NET Core

ASP.NET Core Data Protection exists to solve a very specific problem: the server needs to hand state to an untrusted client and later accept it back without trusting the client to preserve it honestly. Microsoft’s documentation uses authentication cookies and bearer-style tokens as the canonical example. The platform needs confidentiality, integrity, tamper resistance, and isolation between components that may all use the same protection subsystem. (learn.microsoft.com)

Out of the box, the Data Protection stack uses AES-256-CBC with HMACSHA256 for authenticated encryption, and Microsoft notes that on Windows it tries to use a CNG implementation of AES while non-Windows systems fall back to managed cryptographic classes. The exact implementation path matters in CVE-2026-40372 because Microsoft says the vulnerable behavior lives in the managed authenticated encryptor path. (learn.microsoft.com)

The short version is simple: this bug attacked authenticity before it attacked confidentiality. Microsoft’s release notes say the managed authenticated encryptor could compute its HMAC validation tag over the wrong bytes of the payload and then discard the computed hash in some cases. If the server can be tricked into accepting modified ciphertext as authentic, the attacker is no longer just probing a crypto edge case. The attacker is tampering with objects the application was designed to trust, such as authentication state or CSRF defenses. (Microsoft for Developers)

That is also why the one-line NVD description is technically correct but practically incomplete. “Improper verification of cryptographic signature” sounds abstract. In real ASP.NET Core deployments, it means protected application state may stop being proof of origin. Once that happens, a web application can be induced to make new security decisions on false premises, and those later decisions can outlive the original bug. (NVD)

Why the official CVE description is not enough

The NVD entry gives you the vulnerability class, the vector, and the fact that the record is still awaiting enrichment. That is enough to triage a database row, but not enough to tell an engineering team what to do next. The difference between a noisy patch notice and a useful response plan comes from Microsoft’s GitHub advisory, the .NET 10.0.7 OOB release post, and ecosystem follow-on guidance from maintainers who had to translate the advisory into operational terms. (NVD)

The first missing piece is that Microsoft did not present this as a broad “all ASP.NET Core is broken” event. The advisory is conditional. For the primary affected path, the vulnerable 10.0.6 NuGet binary had to be the one actually loaded at runtime, and the application had to run on Linux, macOS, or another non-Windows OS. For a separate and smaller secondary population, applications or libraries consuming the net462 o netstandard2.0 assets of the package can also be affected across operating systems. Those details are easy to lose in headlines, but they completely change who has an emergency and who only needs verification. (GitHub)

The second missing piece is durability. Microsoft’s patch fixes the validation routine. It does not retroactively invalidate every security artifact that may have been minted while the application was making trust decisions on forged input. That is why the advisory spends so much time on key-ring rotation and application-level token rotation. The upgrade closes the front door. It does not automatically cancel the badges that may have been issued while the front door was confused. (GitHub)

The third missing piece is that Microsoft deliberately did not publish a step-by-step exploit recipe. Duende’s update note says that is common in vulnerability disclosures and explicitly says Microsoft has not documented the direct steps an attacker would use. That absence has led some teams to underestimate the bug. It should do the opposite. If the vendor is telling you the trust boundary failed and long-lived artifacts may need to be rotated, the lack of a public exploit walkthrough is not comforting. It is simply not the axis that matters for remediation. (Duende Software)

Why a Data Protection bug turns into a real web compromise

Microsoft’s own .NET cryptography guidance on CBC padding-oracle vulnerabilities is the right lens here. The company states plainly that decrypting CBC-mode symmetric data with verifiable padding is unsafe if you have not first ensured the integrity of the ciphertext, because a padding oracle can let an attacker decrypt ciphertext without knowing the key. The fix, conceptually, is straightforward: authenticate the ciphertext first, validate the MAC or signature in constant time, and only then attempt decryption. (learn.microsoft.com)

CVE-2026-40372 matters because Microsoft says the integrity side of that design regressed in the managed authenticated encryptor. The HMAC validation tag could be computed over the wrong bytes and the computed hash could then be discarded in some cases. That is exactly the kind of failure mode that turns “encrypted state” into “state an attacker may be able to manipulate and test.” Once the application responds differently to valid and invalid manipulations, or once it accepts a forged payload, the attacker can move from theory into application logic. (Microsoft for Developers)

Microsoft’s advisory is unusually explicit about the practical consequence. It says the bug can allow forged payloads to authenticate as a privileged user during the vulnerable window, after which the application may issue legitimate session refresh artifacts, API keys, password reset links, email confirmation tokens, and similar capabilities. That is the key operational insight. The forged artifact is not necessarily the end state. The forged artifact is the bridge to getting the application to mint a clean, first-party token on the attacker’s behalf. (GitHub)

OpenIddict’s release notes sharpen the point further by calling out chosen-ciphertext and padding-oracle risk in plain language. That is useful because it reminds defenders this is not “just a broken cookie parser.” It is a cryptographic trust failure in a system designed to protect state that later drives authentication, authorization, and capability issuance. (GitHub)

Microsoft also gives defenders one strong clue about the likely attack shape: review web-server logs for anomalous request volume against endpoints that accept protected payloads, because the padding-oracle attack requires many requests per byte recovered and should produce traffic well beyond a normal baseline for those endpoints. That is not a guarantee of visibility, but it is a rare piece of exploitation guidance directly from the vendor. (GitHub)

Which ASP.NET Core deployments are actually exposed

This is the section most teams need to read twice.

Microsoft’s primary affected configuration is narrow but important. You are affected if all of the following are true: your application referenced Microsoft.AspNetCore.DataProtection version 10.0.6 directly or transitively, the vulnerable 10.0.6 NuGet binary was actually loaded at runtime, and the application ran on Linux, macOS, or another non-Windows operating system. Microsoft explicitly names transitive paths such as Microsoft.AspNetCore.DataProtection.StackExchangeRedis, EntityFrameworkCore, AzureKeyVault, AzureStoragey Redis. (GitHub)

There is also a secondary affected population. If an application or library referenced Microsoft.AspNetCore.DataProtection 10.0.0 through 10.0.6 and consumed the net462 o netstandard2.0 target framework asset, it can also be affected. Microsoft says this is expected to be much smaller and will primarily include desktop or server applications on .NET Framework that happen to use the ASP.NET Core Data Protection package, plus libraries targeting netstandard2.0 that reference the 10.0 package. The Windows exception does not apply here because these configurations use the same managed authenticated encryptor path across operating systems. (GitHub)

The official “not affected” cases are just as important. Microsoft says you are not affected if you run on Windows in a framework-dependent net10.0 application and the installed shared framework version is greater than or equal to your PackageReference version, because the correct shared framework copy is loaded and the vulnerable NuGet copy is not. Microsoft also says 8.0.x and 9.0.x NuGet versions are not affected because the defective code path was introduced during 10.0 development and was never backported. (GitHub)

That means version numbers alone are not enough. You need to know what binary was actually resolved and loaded, not just what a manifest mentions. The safest mental model is this: CVE-2026-40372 is not purely a “what version is in my repo” question. It is a “what implementation path did my running process take” question. (GitHub)

Duende adds a useful rule of thumb: applications with a direct Microsoft.NET.Sdk.Web o Microsoft.AspNetCore.App framework reference are likely not affected in the common web-app shape, though you still need to account for edge cases involving net462 o netstandard2.0 assets and unusual dependency graphs. That is a good heuristic, not a replacement for verification. (Duende Software)

The table below summarizes the official Microsoft conditions and the most common engineering interpretation of them. The source of truth for the conditions is Microsoft’s advisory. (GitHub)

Deployment pattern	Risk level	Por qué es importante	Immediate priority
Linux or macOS app that loads Microsoft.AspNetCore.DataProtection 10.0.6 from NuGet	Alta	This is Microsoft’s primary affected configuration	Patch, redeploy, rotate keys, review long-lived artifacts
App or library consuming net462 o netstandard2.0 assets from Microsoft.AspNetCore.DataProtection 10.0.0 through 10.0.6	Alta	Secondary affected configuration, OS exception does not save it	Patch, verify asset path, rotate as needed
Windows framework-dependent net10.0 app loading the shared framework copy at version 10.0.6 or later	Baja	Microsoft says the correct shared framework copy is loaded instead of the vulnerable NuGet binary	Verify actual load path, then stand down if confirmed
App on 8.0.x or 9.0.x Data Protection packages	Baja	Microsoft says the vulnerable code path was not backported	Verify package graph, then focus elsewhere
App with direct Microsoft.NET.Sdk.Web o Microsoft.AspNetCore.App reference and no unusual asset path	Often lower	Duende says this is likely not affected in most common web-app cases	Still confirm transitive graph and runtime resolution

Why Data Protection’s blast radius is bigger than many teams assume

A lot of engineers hear “Data Protection” and think “that must be some optional encryption helper we barely touch.” Microsoft’s documentation says otherwise. In web-farm deployments, authentication depends on Data Protection. So do session cookies, TempData in common configurations, and antiforgery tokens. If nodes do not share the same Data Protection trust context, authentication breaks and POSTs start failing. That is how central this subsystem is even before a vulnerability enters the picture. (learn.microsoft.com)

Microsoft also documents the purpose of Data Protection in terms of authenticity, integrity, and tamper resistance, not just encryption. That distinction matters. A confidentiality bug is already bad. A bug that lets the server stop trusting authenticity correctly is worse in web stacks because so many later decisions assume the state object was produced by the server itself. (learn.microsoft.com)

In practice, the first asset class to worry about is authentication cookies. Those are the easiest way to turn a cryptographic trust failure into a session-level compromise. But Microsoft’s remediation guidance makes clear the risk does not stop at cookies. Anything that was issued by a privileged endpoint during the vulnerable window and carries durable capability has to be reviewed separately. (GitHub)

The second asset class is antiforgery-related state and correlation parameters. Microsoft specifically tells defenders to review endpoints that accept auth cookies, antiforgery tokens, and state parameters, and the ASP.NET Core hosting guidance separately shows how antiforgery and authentication both rely on Data Protection in web-farm scenarios. That makes CSRF-related surfaces and login flows part of the exposure map, not just the final cookie that lands after sign-in. (GitHub)

The third asset class is “whatever your application chose to store inside protected payloads.” Microsoft’s advisory says that if your application stored long-lived secrets such as database connection strings or third-party API keys inside IDataProtector.Protect output, you should treat those secrets as potentially disclosed and rotate them at the source. This is one of the most important sentences in the whole advisory because it widens the incident beyond user sessions into application secrets and downstream systems. (GitHub)

The table below is the shortest useful way to think about post-patch fallout. It is derived from Microsoft’s advisory and ASP.NET Core hosting documentation. (GitHub)

Protected artifact	What can go wrong	Does package upgrade alone fix it	What else to do
Authentication cookie	Forged identity or privileged session	No	Rotate key ring and force reauthentication
Antiforgery token	Tamper-resistant request validation can no longer be assumed during exposure window	No	Reissue tokens after rotation and retest protected flows
State parameter or similar protected flow state	Flow integrity can be undermined	No	Rotate, retest login and callback flows
Refresh token, API key, password reset link, email confirmation token issued during the vulnerable window	Legitimate long-lived capability may persist after patch	No	Rotate or invalidate at the application layer
Secrets stored inside IDataProtector.Protect output	Potential disclosure	No	Rotate at the secret source, not only in the app

Patching is mandatory, but patching is not the finish line

Microsoft’s first remediation step is straightforward: upgrade Microsoft.AspNetCore.DataProtection to 10.0.7 or later and redeploy. The .NET 10.0.7 OOB release post adds the operational part: install the updated runtime or SDK, verify with dotnet --info, and rebuild and redeploy applications using updated images or packages. (GitHub)

That closes the validation bug going forward. Microsoft even notes that forged payloads produced during the vulnerable window necessarily carried all-zero HMAC bytes and will be rejected by corrected code. But that line should not lull teams into complacency, because the next sentence in the advisory is the one that matters for containment: rotate the Data Protection key ring if the application was affected and served internet-exposed endpoints during the vulnerable window. (GitHub)

Why is key rotation necessary if the validator is fixed? Because the server may already have turned a forged request into a genuine signed artifact. Microsoft’s advisory is explicit that long-lived artifacts issued during the vulnerable window survive a package upgrade. Key rotation is how you break trust in the old protected state so the server stops accepting it as valid after the fix. (GitHub)

ASP.NET Core key management behavior explains why normal lifecycle rotation is not enough. Microsoft documents a default key lifetime of 90 days, with automatic key-ring refresh approximately every 24 hours. Those are healthy maintenance defaults, not incident-response controls. In a live exposure, waiting for normal key rollover is the opposite of what you want. You need a deliberate revocation event. (learn.microsoft.com)

Microsoft provides the relevant API surface through IKeyManager. The exact sample in the advisory is short, but the important part is the behavior: revoking all keys forces new protection operations onto a new key, invalidates old protected state, signs users out, and causes antiforgery tokens to be reissued. This is disruptive by design. If you are doing it right, users notice. That disruption is evidence that the old trust boundary is no longer accepted. (GitHub)

A practical example looks like this:

using System;
using Microsoft.AspNetCore.DataProtection;
using Microsoft.AspNetCore.DataProtection.KeyManagement;
using Microsoft.Extensions.DependencyInjection;

var services = new ServiceCollection();

services.AddDataProtection();
// Add your existing key storage configuration here,
// for example PersistKeysToFileSystem, PersistKeysToDbContext,
// or the same external repository used by production.

using var provider = services.BuildServiceProvider();
var keyManager = provider.GetRequiredService<IKeyManager>();

keyManager.RevokeAllKeys(
    revocationDate: DateTimeOffset.UtcNow,
    reason: "Emergency revocation after CVE-2026-40372 remediation");

That code is only the first half of the incident response. The second half is application-layer cleanup. Microsoft’s advisory calls out refresh tokens, access tokens stored in your database, password reset links, email-confirmation tokens, and any other persistent capability that may have been emitted by an authenticated endpoint during the vulnerable window. Those must be invalidated or rotated in the application’s own stores because Data Protection key rotation does not reach into your database and cancel them for you. (GitHub)

The third half, because incidents always have a third half, is secret rotation. If your app ever used Data Protection as a convenient wrapper around long-lived secret material, treat those secrets as exposed. A package fix does not unring that bell. (GitHub)

How to determine whether your app is actually affected

Start with runtime truth, not hope.

First, check what runtime and SDK versions you are operating with. Microsoft’s OOB guidance explicitly recommends dotnet --info after installing the fixed runtime or SDK, and that is still the quickest way to verify what a machine or container image thinks it has. (Microsoft for Developers)

Second, trace how Microsoft.AspNetCore.DataProtection got into your graph. The dotnet nuget why command exists for exactly this problem. Microsoft documents it as a way to show the dependency graph for a particular package in a project or solution, and Duende specifically recommends using it for this CVE so you can see whether the package is direct or transitive and what brought it in. (learn.microsoft.com)

Third, audit vulnerable packages, including transitive ones. Microsoft’s NuGet documentation says dotnet package list --vulnerable can list packages with known vulnerabilities and notes that --include-transitive should be added when you want the full picture. Separate .NET compatibility guidance also says that when projects target .NET 10 or higher, NuGetAuditMode defaults to todos, which means transitive vulnerable packages can now raise warnings by default during restore. (learn.microsoft.com)

A practical first pass looks like this:

dotnet --info

dotnet nuget why Microsoft.AspNetCore.DataProtection

dotnet package list --include-transitive --vulnerable

grep -R "Microsoft.AspNetCore.DataProtection" -n .
grep -R "Microsoft.AspNetCore.DataProtection.StackExchangeRedis" -n .
grep -R "UseCustomCryptographicAlgorithms" -n .
grep -R "<Project Sdk=\"Microsoft.NET.Sdk.Web\">" -n .
grep -R "Microsoft.AspNetCore.App" -n .

The point of that block is not to prove vulnerability by itself. The point is to answer four questions fast: do you have the package, why do you have it, are you relying on transitive inclusion, and is your project in the common web-app shape that Microsoft and Duende think is less likely to be affected. (Duende Software)

If you are running CI on .NET 10, remember that transitive auditing is now more aggressive by default. That is good news for catching the next dependency issue earlier, but it also means teams with TreatWarningsAsErrors may suddenly discover restore failures tied to vulnerable packages. That is not noise. It is your build system telling you the package graph deserves the same urgency as direct code. (learn.microsoft.com)

The last and most important question is what binary actually loaded at runtime. Microsoft’s advisory keeps returning to this point because a PackageReference alone does not define exposure. The runtime resolution path does. In containerized and self-contained workflows, that distinction becomes operationally important: the image or artifact you built yesterday may still carry yesterday’s package even if the host runtime outside the container has moved on. Microsoft’s OOB guidance to rebuild and redeploy using updated images or packages is there for a reason. (GitHub)

Why Linux containers and web farms deserve special attention

The common internet-facing shape for modern ASP.NET Core is not a single IIS host on Windows. It is a Linux container set behind a load balancer, often with shared external storage for keys and distributed state. Microsoft’s own hosting documentation says Data Protection and caching both require configuration in web farms, and it explains that by default each node stores its key ring locally and therefore cannot decrypt data generated by another node. That is why teams externalize the key ring in the first place. (learn.microsoft.com)

Now map that design back to CVE-2026-40372. Microsoft’s advisory explicitly lists transitive paths such as Microsoft.AspNetCore.DataProtection.StackExchangeRedis, AzureKeyVault, AzureStoragey EntityFrameworkCore. Those are not exotic packages. They are exactly the providers and supporting packages teams reach for when they want consistent Data Protection behavior across multiple nodes. (GitHub)

So the dangerous deployment story is not “one weird app manually imported a niche package.” It is “a realistic production topology externalized the trust material correctly for scale, but the trust validation logic on certain runtime paths regressed.” That is what makes the blast radius operationally serious. A load balancer, shared key ring, auth cookies, and refresh token issuance is a normal enterprise deployment, not a special case. (learn.microsoft.com)

Consider a plausible scenario built directly from Microsoft’s affected conditions and hosting guidance. A set of Linux containers runs a cookie-authenticated ASP.NET Core app behind a reverse proxy. The app stores the Data Protection key ring in Redis so every node can decrypt every issued cookie. During the vulnerable window, an attacker targets an internet-exposed endpoint that accepts a protected payload. Once a forged cookie is accepted, the application issues a fresh, genuinely signed refresh artifact. At that point, the attacker no longer depends on the original malformed input. They are holding a token the application created on its own authority. (GitHub)

That is why the remediation order matters in clustered environments. You do not want one node accepting old state while another has moved on. Patch the package everywhere, rebuild and redeploy images everywhere, rotate the shared key ring, invalidate or rotate long-lived artifacts in the backing store, and then retest across the fleet. A partial rollout can leave you with the worst of both worlds: inconsistent behavior for users and incomplete containment for the attacker. (GitHub)

What to look for in logs and telemetry

Microsoft does not often give defenders specific exploitation-shape guidance in product advisories. Here it does. The advisory says to review web-server logs for anomalous request volume against endpoints that accept protected payloads, including auth cookies, antiforgery tokens, and state parameters, because the padding-oracle attack requires many requests per byte recovered. Microsoft says sustained high-volume traffic with varying cookie or query-parameter values against a single authenticated endpoint during the vulnerable window is a strong indicator. (GitHub)

That guidance lines up with Microsoft’s general CBC padding-oracle explanation. The .NET crypto documentation describes how attackers repeatedly modify ciphertext and watch the oracle’s response until enough signal exists to recover data block by block. When a vendor tells you the attack may require many requests per byte, that is not colorful language. It is telling you the log signature is likely to be iterative and noisy unless the attacker is exceptionally patient. (learn.microsoft.com)

A good investigation starts with endpoints that consume server-issued protected state: login callbacks, cookie-authenticated APIs, endpoints behind antiforgery validation, and flows that depend on protected correlation or state parameters. Build a time window around when the affected build was first deployed and when the fixed build plus key rotation finished. Then look for request bursts, abnormal repetition from one source or a rotating set of sources, and payload mutation patterns against the same route. (GitHub)

You should also keep a separate bucket for secondary symptoms. Microsoft’s hosting documentation says Data Protection issues in web farms can manifest as authentication breakage, “Correlation failed” on OAuth or OpenID Connect flows, lost identity, failed TempData, and antiforgery check failures. Those are not proof of exploitation in CVE-2026-40372. They are proof that Data Protection is involved in the route you are examining and that the subsystem is relevant to what you are seeing. (learn.microsoft.com)

A few example queries can help structure the hunt.

KQL style example:

let start = datetime(2026-04-15);
let end = datetime(2026-04-23);
AppRequests
| where TimeGenerated between (start .. end)
| where Url has_any ("signin", "callback", "auth", "login", "csrf", "antiforgery", "state")
| summarize req_count = count(), distinct_cookie_values = dcount(CookieHeader), distinct_query_values = dcount(QueryString)
  by bin(TimeGenerated, 5m), Url, ClientIP
| where req_count > 100 or distinct_cookie_values > 50 or distinct_query_values > 50
| order by req_count desc

Splunk style example:

index=web earliest=04/15/2026:00:00:00 latest=04/23/2026:23:59:59
(uri_path="*signin*" OR uri_path="*callback*" OR uri_path="*auth*" OR uri_path="*csrf*" OR uri_path="*state*")
| stats count dc(cookie) as dc_cookie dc(uri_query) as dc_query by _time span=5m uri_path src_ip status
| where count > 100 OR dc_cookie > 50 OR dc_query > 50
| sort - count

The numbers there are placeholders. The real value is in the shape: repeated hits, same endpoint, lots of mutated protected inputs, abnormal volume relative to baseline.

One more caution matters. The absence of noisy traffic does not prove you are safe. Microsoft’s advisory warns about long-lived artifacts issued during the vulnerable window, and those may still be in use after the original probing phase ended. Your log hunt should therefore have two tracks: one for potential oracle-style probing, and one for unexpected successful use of refresh tokens, password reset flows, or capability-bearing endpoints whose issuance history overlaps the vulnerable period. (GitHub)

Why CVE-2026-40372 echoes MS10-070

Microsoft itself draws the analogy to MS10-070, and that is not nostalgia. It is a warning label.

MS10-070, which addressed CVE-2010-3332, was the classic ASP.NET padding-oracle bug. Microsoft’s old security bulletin says it allowed an attacker to read encrypted data such as view state and to tamper with encrypted data. On .NET Framework 3.5 SP1 and above, Microsoft also said the bug could be used to retrieve the contents of files inside the ASP.NET application, including web.config. (learn.microsoft.com)

The company’s modern CBC guidance makes the shared cryptographic lesson explicit. Padding-oracle attacks exploit the interaction between CBC-mode ciphertext tampering and an implementation detail that leaks whether the tampering was “close” to valid. Historically, practical attacks were often tied to different server-side error behavior, and Microsoft specifically calls MS10-070 the canonical old example. Later guidance expands the concern to timing differences as well. (learn.microsoft.com)

The similarity to CVE-2026-40372 is not that both bugs are literally the same implementation flaw. They are not. The similarity is that both bugs show what happens when a server stops treating integrity verification as the first hard gate on encrypted state. Once authenticity checks are bypassed or made unreliable, confidentiality and application trust collapse together. (learn.microsoft.com)

The difference is just as important. Microsoft’s MS10-070 bulletin framed the old bug primarily as information disclosure plus data tampering that could enable further compromise; it did not present it as direct privilege escalation. The 2026 advisory, by contrast, frames CVE-2026-40372 as remote elevation of privilege because the broken trust path can directly feed forged authentication artifacts into an application that then issues new, legitimate capabilities. That is a more modern and more application-centric compromise story. (learn.microsoft.com)

For defenders, the practical takeaway is blunt: never file a cryptographic regression under “stability bug” just because the first visible symptom is decryption failure. CVE-2026-40372 was found because things broke. It matters because trust broke. (GitHub)

Common mistakes that will leave teams exposed

The first mistake is treating runtime patching and package patching as the same thing. Microsoft’s OOB guidance tells customers to install the fixed runtime or SDK, but the advisory itself is about the Microsoft.AspNetCore.DataProtection package and repeatedly focuses on whether the vulnerable NuGet binary was what actually loaded at runtime. If your deployment process bakes packages into containers or self-contained artifacts, patching the host outside the artifact is not enough. (Microsoft for Developers)

The second mistake is checking only direct dependencies. Microsoft’s own tooling and compatibility notes now emphasize transitive vulnerability auditing, and the advisory itself calls out several transitive package paths that can bring Data Protection into your graph. If you only inspect the top-level PackageReference lines you can miss the exact path that matters. (learn.microsoft.com)

The third mistake is thinking a patch invalidates all prior trust decisions. Microsoft says the opposite. Key rotation is a separate required step for affected internet-exposed apps, and application-layer capabilities issued during the vulnerable window must be audited and rotated separately. If your incident ticket closed at “upgraded to 10.0.7,” the ticket closed too early. (GitHub)

The fourth mistake is misunderstanding the Windows exception. Microsoft’s “not affected” language applies to a specific Windows framework-dependent net10.0 scenario where the shared framework copy at a sufficient version is the one that loads. That is not the same as “Windows can ignore this CVE.” Secondary affected configurations involving net462 y netstandard2.0 assets prove that. (GitHub)

The fifth mistake is stopping at package auditing instead of moving into proof. This is where many remediation workflows still fail. The thing you actually need after a vulnerability like CVE-2026-40372 is not only a dependency bill of health. You need evidence that old protected inputs are rejected, old sessions are invalidated, application-layer artifacts are rotated, and critical endpoints behave correctly after the response. That evidence requirement is exactly why a vulnerability ticket and a finished incident response are not the same deliverable. (GitHub)

Retest, evidence capture, and the value of a controlled validation workflow

The hardest part of remediating a trust-boundary bug is not installing the patch. It is proving that the trust boundary was actually restored.

That means replaying critical login and session flows, checking whether pre-rotation cookies are now rejected, verifying that password reset and email-confirmation links issued inside the vulnerable window no longer work, and confirming that fresh artifacts issued after the fix behave normally. It also means preserving enough request and response evidence that another engineer can audit what changed. Penligent’s public article on AI pentest reporting gets this point exactly right: a pentest report is only useful if it can survive retest, and polished prose is not evidence. (Penligente)

That same evidence-first logic is the useful place for automation in a CVE-2026-40372 response. A governed agentic workflow can help turn an advisory into repeatable probing, evidence capture, retest logic, and a clean handoff to the team that owns remediation. Penligent’s own writing on CVE prioritization describes this kind of workflow as translating advisories and public signals into repeatable validation and retest steps, which is exactly what teams need when a package fix must be followed by session invalidation, token rotation, and proof that legacy artifacts no longer pass. (Penligente)

Used correctly, that kind of workflow does not replace engineering judgment. It compresses the gap between advisory, verification, and evidence-backed closure. For a vulnerability like CVE-2026-40372, that is the only kind of closure worth trusting. (GitHub)

A practical remediation sequence for this week

If your environment could plausibly be affected, a disciplined sequence looks like this.

First, identify whether the vulnerable package is present and why. Use dotnet nuget why, dotnet package list --include-transitive --vulnerable, and source inspection to find both direct and transitive paths. Confirm whether your deployment shape matches Microsoft’s affected conditions. (learn.microsoft.com)

Second, patch to 10.0.7 or later, rebuild artifacts, and redeploy everywhere the vulnerable binary could have loaded. Verify runtime state with dotnet --info and verify package state in the deployed build. Do not stop at the developer workstation or one container tag. (Microsoft for Developers)

Third, if the application was affected and internet-exposed during the vulnerable window, revoke the Data Protection key ring. Expect user sign-outs and antiforgery token reissuance. This is the intended blast radius of containment, not a regrettable side effect. (GitHub)

Fourth, rotate or invalidate long-lived artifacts issued by authenticated endpoints during the vulnerable window. That includes refresh tokens, stored API keys, password reset links, email confirmation links, and any equivalent capability your application creates. If you know the issuance times precisely, scope the response precisely. If you do not, bias toward safety. (GitHub)

Fifth, rotate secrets that were stored inside protected payloads. Database credentials, third-party API keys, or other long-lived secret material should be treated as disclosed if they ever rode inside Data Protection output. (GitHub)

Sixth, review logs around affected endpoints for abnormal high-volume probing with varying protected inputs. Hunt both the probing phase and the post-issuance phase. The former looks like traffic anomalies. The latter looks like suspicious but valid use of durable artifacts. (GitHub)

Seventh, retest the flows that mattered most in your deployment: sign-in, refresh, CSRF-protected actions, external auth callbacks, TempData-heavy flows, and any endpoint that accepts or issues protected state. Keep the evidence. A “fixed” label without retest proof is just optimism with a timestamp. (learn.microsoft.com)

Eighth, tighten the supply-chain side so the next incident is shorter. Microsoft’s modern NuGet tooling is good enough now that teams should be routinely using transitive vulnerability auditing, dependency-graph tracing, and, where it fits, SBOM generation. Duende explicitly recommends an SBOM strategy after this incident class because teams discovered they did not always know how the package got into the graph in the first place. (learn.microsoft.com)

What CVE-2026-40372 should change in engineering habits

The lesson from this bug is not “never trust packages.” It is “do not confuse encryption with trustworthy state.”

Modern web frameworks hand a lot of trusted state to clients because that is how scalable stateless HTTP systems actually work. Cookies, correlation values, antiforgery tokens, TempData, and similar artifacts are normal. The security model only holds if the server treats authenticity verification as sacred. Once that gate weakens, the application can become a signer for attacker-directed outcomes. (learn.microsoft.com)

The second lesson is that deployment topology changes exploitability more than product names do. ASP.NET Core on its own is not the whole story. Whether the vulnerable NuGet binary was actually loaded, whether you run on Linux or a non-Windows target, whether you consume non-net10.0 assets, whether your key ring is externalized, and whether your app issues durable capabilities after authentication all matter more than the headline “ASP.NET Core vulnerability.” (GitHub)

The third lesson is that incident response for trust bugs needs two closure criteria, not one. The first is technical remediation of the faulty component. The second is invalidation of trust decisions that were already made while the component was faulty. CVE-2026-40372 is a perfect example. Package upgrade without key rotation and artifact review is not wrong. It is incomplete. (GitHub)

The fourth lesson is that retest quality matters. This is exactly why evidence-backed validation workflows, whether you do them manually or with tightly governed automation, are more valuable than generic AI summaries or one-click status dashboards. If the output cannot show what was affected, what changed, what old artifact now fails, and what fresh artifact now succeeds, it is not a useful closure record for a vulnerability like this one. (Penligente)

Conclusión

CVE-2026-40372 is a reminder that ASP.NET Core security is not only about input validation bugs, SSRF, or request smuggling. Sometimes the failure is lower in the trust stack. When Data Protection stops verifying authenticity correctly, the application can stop knowing which state came from itself and which state came from an attacker. From there, session trust, flow integrity, and capability issuance can all start drifting in the wrong direction. (GitHub)

If you remember only five things, remember these. Confirm whether the vulnerable package was really loaded. Patch to 10.0.7 or later everywhere it could have been. Rotate the Data Protection key ring for affected internet-exposed apps. Rotate long-lived capabilities and secrets that may have been issued or exposed during the vulnerable window. Then retest and keep the evidence. That is what a finished response looks like for CVE-2026-40372. (GitHub)

Para saber más

• Microsoft GitHub advisory for CVE-2026-40372, affected conditions and remediation steps. (GitHub)
• .NET 10.0.7 out-of-band release post, release context and installation guidance. (Microsoft for Developers)
• NVD record for CVE-2026-40372, publication date, CVSS, and current enrichment status. (NVD)
• ASP.NET Core Data Protection overview, why protected state needs authenticity and integrity. (learn.microsoft.com)
• ASP.NET Core key management, default key lifetime and refresh behavior. (learn.microsoft.com)
• ASP.NET Core hosting in a web farm, where Data Protection sits in authentication, TempData, session, and antiforgery flows. (learn.microsoft.com)
• Microsoft guidance on CBC padding-oracle vulnerabilities, the cryptographic model behind why this class of bug is dangerous. (learn.microsoft.com)
• Microsoft security bulletin MS10-070, the historical ASP.NET padding-oracle parallel. (learn.microsoft.com)
• dotnet nuget why command documentation, for tracing how the vulnerable package entered a project. (learn.microsoft.com)
• NuGet auditing guidance and transitive vulnerability checks in modern .NET. (learn.microsoft.com)
• Penligent, How to Get an AI Pentest Report, for evidence-backed retest and reporting discipline after remediation. (Penligente)
• Penligent, NIST CVE Prioritization as AI Speeds Up Vulnerability Discovery, for turning advisories into repeatable probing, evidence capture, and retest logic. (Penligente)
• Penligent homepage, for the product context behind controlled agentic pentest workflows and evidence-first validation. (Penligente)