Brief Summary: ASP.NET Core Identity Scaffolding Flaw CVE-2026-118741 Sends Password Reset Links to Client-Supplied Addresses

Introduction

Password recovery is often the weakest point in an otherwise sound authentication design, and CVE-2026-118741 shows how a framework's own code generators can ship that weakness. Microsoft's ASP.NET Core Identity scaffolders and project templates produced password reset and email confirmation handlers that delivered token-bearing links to whatever address the client submitted. Because that code lives in each application's source tree, updating the .NET runtime alone does not remove it.

Microsoft scores the issue 8.1 (High) under CVSS 3.1 and describes it as improper authentication that allows an unauthorized attacker to elevate privileges over a network. NVD published the record on November 10, 2026, and lists it as awaiting its own enrichment. The fix shipped the same day in the .NET servicing release, and it requires action at two separate layers: the generation tooling, and every application already generated with that tooling.

Technical Information

Root cause: one form field, two jobs

Microsoft's advisory places the bug in generated application code, not in the ASP.NET Core runtime. The Identity templates use the email supplied in the request, instead of the email stored on the account, as the destination for password reset and confirmation messages.

In the generated ForgotPassword and ResendEmailConfirmation handlers, including their Blazor equivalents, Input.Email is bound from the HTTP form and used for two different purposes:

1. Finding the user account.
2. Choosing who receives the email containing the reset or confirmation link.

The first use is legitimate. The second is the defect, because the value that decides where a security token is delivered comes from the client rather than from the account record Identity already holds. The patch restores a simple principle: a security token should go only to an address the server trusts, never to one the client chose.

The assigned weakness is CWE 640, Weak Password Recovery Mechanism for Forgotten Password. MITRE describes this class as a recovery or password change mechanism that operates without knowledge of the original password, and notes that a weak recovery path can undermine otherwise strong password authentication. MITRE's broader examples describe the weakness class in general and are not evidence that every such example applies here.

Scoring

The published vector is:

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

• Attack vector: Network. Exploitation is described as occurring over a network.
• Attack complexity: High. Success depends on conditions outside the attacker's control, and Microsoft does not say what those conditions are.
• Privileges required: None. The attacker does not need an existing account, so high complexity should not be read as a requirement for authentication.
• User interaction: None.
• Scope: Unchanged.
• Confidentiality, Integrity, Availability: High potential impact for each.

Per the FIRST CVSS 3.1 specification, a base score expresses intrinsic severity under scoring assumptions. It is not evidence that attacks have occurred.

Attack flow, as far as the sources support it

The advisory describes the defective relationship between lookup and delivery rather than an exploit. Based on that description, the logical flow in an affected application is:

1. An unauthenticated client reaches the generated forgot password or resend confirmation endpoint over the network.
2. The client submits an email value in the form, which populates Input.Email.
3. The handler uses that value to locate a user, runs its existing checks, and generates a reset or confirmation token and callback URL for the located account.
4. The handler sends the token-bearing link to Input.Email, the client-supplied value, rather than to the address stored on that account.

Whenever the submitted value can locate an account while differing from that account's stored address, the token for that account goes to an address the client chose. That is consistent with Microsoft's description of unauthorized privilege elevation and with the CWE 640 classification.

The sources stop there. Microsoft does not explain the conditions responsible for the high complexity rating, and it publishes no malicious request, no demonstrated email manipulation sequence and no account takeover walkthrough. We are deliberately not speculating about normalization tricks, mailbox control requirements, token forgery or specific payloads, because any such claim would go beyond what has been disclosed. The high C/I/A ratings support high potential impact, but no complete exploit chain or demonstrated server compromise has been published.

Exposure is about generated code, not the installed runtime

Microsoft lists supported operating systems and all architectures, but the affected components are particular templates and generation tools. Having a given .NET runtime installed does not by itself mean an application contains these handlers. Conversely, an environment can run fully updated tooling while still serving vulnerable generated source. What determines exposure is the combination of generator versions and the code they produced.

Exploitation status

No verified exploitation campaign or named threat actor was identified in the reviewed sources, and Microsoft's advisories contain no active exploitation statement. VulDB reports the KEV status as no, which is a third-party catalog status rather than proof that exploitation has never occurred. No verified public working exploit was found. Microsoft credits Leonardo Souza with Delfia and Attila.Cs with zerodaybugs.com for the report. These are disclosure acknowledgments, not threat actor identifications.

Patch Information

Microsoft shipped the fix on November 10, 2026, as part of the .NET servicing release, under advisory GHSA-jxmf-523q-f7r7 and dotnet/announcements#525. We found no public commit diff. The repair code below is exactly what Microsoft published.

What the fix changes

The patch separates the two jobs Input.Email was doing. It is still used for the account lookup. After a user has been found, the handler asks Identity for the email stored on that account and sends the token-bearing link only there. If the account has no stored email, the handler refuses to send anything.

Insert the following after the existing user lookup and checks:

var storedEmail = await UserManager.GetEmailAsync(user);
if (string.IsNullOrEmpty(storedEmail))
{
    throw new InvalidOperationException("Users must have an email.");
}

In the Razor Pages versions, use _userManager instead of UserManager. Then change only the recipient argument from Input.Email to storedEmail in whichever of these calls the handler uses:

• _emailSender.SendEmailAsync
• EmailSender.SendPasswordResetLinkAsync
• EmailSender.SendConfirmationLinkAsync

Leave everything else in the handler as it is: the user lookup, the responses for unknown users, the password reset confirmation checks, token generation and callback URL encoding. Make the change in both ForgotPassword and ResendEmailConfirmation, and in their Blazor equivalents.

Why updating packages alone is not enough

Scaffolded code becomes part of your source tree. An updated generator produces correct code from then on, but it does not rewrite files it generated earlier. Microsoft's release notes for 8.0.34 and 10.0.15 state that updating the runtime alone does not repair generated code. The fix therefore has two parts:

1. Fix the generators so that new code is safe.
2. Fix and redeploy each existing app. Edit the generated handlers as shown above, rebuild and redeploy. If the handlers are regenerated later with an affected template, apply the edit again.

Some affected versions have no fixed release of their own. In the GitHub advisory record, the CodeGenerators.Mvc and Design 11.0.0-preview.1 builds and every listed dotnet-scaffold-aspnet version show no patched version. For those, the remedy is to edit the generated code by hand and use dotnet scaffold 20.3.0 for any new scaffolding.

For .NET 10, the 10.0.15 release notes show the fixed Microsoft.DotNet.Web.ProjectTemplates.10.0 10.0.15 shipping alongside SDKs 10.0.404 and 10.0.115. SDK 10.0.404 is included in Visual Studio 18.11.4. Microsoft notes that Visual Studio automatically uses the updated scaffolding tool, while command-line installations need separate updates.

Updating the scaffolding tool

To update an existing global install of the scaffolding tool:

dotnet tool update --global Microsoft.dotnet-scaffold --version 20.3.0

To replace the retired dotnet-scaffold-aspnet tool:

dotnet tool uninstall --global Microsoft.dotnet-scaffold-aspnet
dotnet tool install --global Microsoft.dotnet-scaffold --version 20.3.0

Things to watch for:

• Local tools: use the local flag instead of the global flag, and run the commands from the directory containing the tool manifest.
• 20.3.0 is a .NET tool, not a project package. The MVC and Design packages referenced by your project have their own fixed versions (8.0.24, 9.0.13 and 10.0.3).
• dotnet-aspnet-codegenerator uses your project's packages. It loads generators from the project's dependencies, so those package references must be updated too.
• SDK-bundled templates: install the new SDK and confirm it is the one actually selected in the application's working directory. A global.json file can pin an older SDK.
• Separately installed template packs must be updated on their own. Installing a new SDK does not necessarily replace them.
• Migration is not repair: moving to the consolidated 20.3.0 tool does not update project references or fix existing code.

Affected Systems and Versions

The following mapping comes from Microsoft's detailed advisory and patch notes. These are distinct package release tracks, not interchangeable runtime versions. MVC and Design refer to Microsoft.VisualStudio.Web.CodeGenerators.Mvc and Microsoft.VisualStudio.Web.CodeGeneration.Design. Design applicability depends on the resolved MVC generator.

MVC and Design generator packages

• 8.0 series: 8.0.0 through 8.0.23, fixed in 8.0.24
• 9.0 series: 9.0.0 through 9.0.12, fixed in 9.0.13
• 10.0 series: 10.0.0 through 10.0.2, fixed in 10.0.3
• Affected prereleases include 8.0.0-preview.1.23117.2, 9.0.0-preview.1.24112.3 and 10.0.0-rc.1.25458.5, fixed in the corresponding stable versions above
• Legacy 11.0.0-preview.1.26156.3 and 11.0.0-preview.1.26230.3: no fixed release, so repair application code by hand

SDK project templates

• Microsoft.DotNet.Web.ProjectTemplates.8.0: 8.0.0 through 8.0.33, fixed in 8.0.34
• Microsoft.DotNet.Web.ProjectTemplates.9.0: 9.0.0 through 9.0.22, fixed in 9.0.23
• Microsoft.DotNet.Web.ProjectTemplates.10.0: 10.0.0 through 10.0.14, fixed in 10.0.15
• Microsoft.DotNet.Web.ProjectTemplates.11.0: specific previews and release candidates, including 11.0.0-preview.1.26104.118 and 11.0.0-rc.3.26522.148, fixed in 11.0.0
• Affected template prereleases also include 8.0.0-rc.2.23480.2, 9.0.0-preview.1.24081.5 and 10.0.0-preview.1.25120.3

Scaffolding tools

• Microsoft.dotnet-scaffold: 10.0.0 through 10.0.2, and 20.x tooling from 20.0.0-preview.1.26156.3 through 20.1.0, fixed in 20.3.0
• Microsoft.dotnet-scaffold-aspnet: 9.0.0 through 9.0.12 and some 10.0 release candidates, with no fixed version, so migrate to Microsoft.dotnet-scaffold 20.3.0
• Some older scaffolding tool prereleases are also affected, and the advisory lists them individually

An inventory restricted to stable releases will be incomplete. The records also disagree in places. NVD lists narrower starting versions for the three project template packages and represents the older ASP.NET scaffolding tool differently than Microsoft's detailed advisory. Similarly, Microsoft's general servicing announcement names .NET 8, 9 and 10, while the detailed advisory also covers 11.0 prerelease templates and legacy generation packages. We recommend treating Microsoft's detailed advisory as the authoritative mapping when interpreting automated inventory results.

Vendor Security History

The Cyber Safety Review Board's review of the summer 2023 Microsoft Exchange Online intrusion concluded that the intrusion was preventable and found Microsoft's security culture inadequate and in need of an overhaul, citing organizational and governance failures. That review concerns a different service and does not establish any causal link to this scaffolding defect.

Microsoft's July 2026 Secure Future Initiative report describes subsequent work across culture, governance and engineering, reporting 99.97% user and device coverage for phishing-resistant MFA enforcement, 98.7% cross-boundary credential isolation, and removal of public access from 732,000 resources. These are Microsoft's own program metrics and say nothing about whether applications containing the vulnerable handlers have been repaired. For this CVE, what matters is whether the handlers in each affected application have been repaired.

References

1. NVD vulnerability detail for CVE-2026-118741
2. CVE.org record for CVE-2026-118741
3. Microsoft Security Response Center update guide entry
4. Microsoft Security Advisory, dotnet/announcements issue 525
5. Microsoft Security Advisory, dotnet/Scaffolding issue 3959
6. dotnet/announcements issue 525 (GitHub API)
7. dotnet/Scaffolding issue 3959 (GitHub API)
8. GitHub security advisory GHSA jxmf 523q f7r7
9. .NET and .NET Framework November 2026 servicing updates, .NET Blog
10. .NET 10.0.15 release notes
11. .NET November 2026 ASP.NET Core security updates discussion
12. Overview of ASP.NET Core, Microsoft Learn
13. CWE 640: Weak Password Recovery Mechanism for Forgotten Password
14. CVSS v3.1 Specification Document, FIRST
15. VulDB entry for CVE-2026-118741
16. CISA Known Exploited Vulnerabilities Catalog
17. CSRB Review of the Summer 2023 Microsoft Exchange Online Intrusion
18. Microsoft SFI Progress Report, July 2026
19. Zero Day Initiative, The November 2026 Security Update Review
20. Ivanti, November 2026 Patch Tuesday
21. SecurityWeek coverage of the November 2026 Microsoft patch release