.NET November 2026 Updates: .NET 8 and 9 Reach End of Support as .NET 11 Launches

There is also an important boundary around the Framework portion of the announcement. Microsoft’s.NET Framework release index inspected for this report still lists October 13, 2026 as its newest cumulative update. That establishes an October servicing baseline, but it does not establish November Framework KB numbers, fixes, or known-issue status. Those details should not be inferred from the headline of the combined announcement.

What changed: the November versions​

Microsoft’s servicing announcement and download matrix identify the following runtime releases. SDK versions are shown separately because a runtime patch number is not an SDK version.

These versions and lifecycle dates appear in Microsoft’s Visual Studio SDK download matrix. That page also lists SDK 10.0.404 for.NET 10 and SDK 11.0.100 for.NET 11.

The distinction matters when reviewing inventory. A machine reporting SDK 11.0.100 and runtime 11.0.0 is not reporting inconsistent versions: the SDK and runtime use different numbering schemes. Microsoft Learn explains that SDK releases have feature bands, reflecting changes in build tooling and associated components. Comparing the two numbers digit for digit is therefore the wrong compliance test.

Why some Microsoft pages show older patches​

Microsoft’s support-policy page is stamped October 25, 2026 and still lists 10.0.14, 9.0.22, and 8.0.33. The November announcement and updated download matrix list the newer releases above. The dated policy table is useful for lifecycle information, but its October patch entries should not be mistaken for November’s release numbers.

This is a practical release-day lesson: record both the version and the date of the evidence used to approve an update. “Latest” without a timestamp makes a surprisingly poor audit trail.

The security scope extends beyond the runtime​

Microsoft’s November announcement lists vulnerabilities involving.NET, ASP.NET Core, and associated Visual Studio tooling. Its categories include denial of service, elevation of privilege, information disclosure, security-feature bypass, and remote code execution. The affected-version columns vary; they do not establish that every issue affects every release.

For example, the announcement associates CVE-2026-109478, an ASP.NET Core denial-of-service issue, with.NET 8. It associates CVE-2026-114155, a.NET elevation-of-privilege issue, with.NET 10 and 11. Several remote-code-execution entries are explicitly labeled as Visual Studio vulnerabilities rather than generic runtime flaws.

Those distinctions are enough to justify reviewing developer workstations and build systems alongside application servers. They are not enough to assign severity scores, declare active exploitation, or conclude that one runtime installer resolves every tooling issue. The announcement’s summary table does not supply those particulars; vulnerability-specific affected-build and remediation details remain necessary before making such claims.

The operational recommendation is to keep separate checks for application runtimes, application dependencies, and development tooling. A single green “updated” indicator should not stand in for all three.

.NET 8 and 9: patching does not extend support​

Microsoft’s published lifecycle dates place both.NET 8 and.NET 9 at end of support on November 10, 2026. The updated download matrix already groups those lines under out-of-support versions. Their November patches do not announce an extension to those dates.

.NET 10 remains an LTS option with a published endpoint of November 14, 2028. Microsoft describes LTS and STS as different support durations, not different quality tiers. Choosing between them should therefore be a maintenance and compatibility decision, rather than an assumption that one label means inherently safer code.

There is another trap: installing a newer major runtime does not automatically migrate an older application. Microsoft Learn documents that major versions install side by side and that applications ordinarily continue targeting their existing runtime family. Patch roll-forward is the default within that family; major-version migration is a different operation.

For an application owner, the resulting plan is straightforward:

• Apply the appropriate November servicing release to existing installations.
• Treat migration from.NET 8 or 9 as a separate, urgent work item.
• Test the application against its intended supported target.
• Retain evidence of both the deployed runtime and successful application validation.

This is a recommended workflow, not a claim that Microsoft has supplied a universal migration procedure for every application.

.NET 11 is no longer just the RC listing​

Microsoft’s.NET 11 download page now lists 11.0.0, dated November 10, 2026, with SDK 11.0.100. The earlier 11.0.0-rc.3 entry remains farther down the page as an October 25 release. Readers should distinguish those entries rather than treating the release candidate as the newest available build.

The SDK listing names Visual Studio 2026 version 18.12 support and says it is included in Visual Studio 18.12.0. It also identifies C# 15.0, F# 11.0, and Visual Basic 17.13 language support. Those are relevant compatibility details for teams updating development environments, not reasons to move every production application to.NET 11 during the same maintenance window.

The practical distinction is between servicing an existing deployment and adopting a new major platform. Keeping those changes separately testable makes troubleshooting considerably less adventurous.

A Windows update workflow that checks the right things​

1. Inventory before installing​

On a machine where the.NET command-line host is available, open PowerShell or Command Prompt and run:

dotnet --info
dotnet --list-runtimes
dotnet --list-sdks

Microsoft documents these commands for inspecting the environment, installed runtimes, and installed SDKs. Save the output before making changes so that the post-update comparison has a baseline.

Do not substitute dotnet --version for the whole inventory. That command reports the SDK selected for commands, and its result can be influenced by a global.json file. It is not a list of all installed runtime versions.

Architecture matters too: Microsoft documents that an x86 dotnet host lists x86 runtimes, while an x64 host lists x64 runtimes. An apparently clean result from one architecture does not prove that another architecture has been serviced.

2. Choose the component the application needs​

Microsoft’s Windows installation documentation distinguishes three runtime categories:

• .NET Runtime: the base runtime.
• .NET Desktop Runtime: support for Windows desktop applications, including WPF and Windows Forms; it also includes the base runtime.
• ASP.NET Core Runtime: support for web applications.

The SDK includes all three Windows runtimes, but it is intended for building applications. Installing a development kit should not be the default answer to every application-runtime requirement.

For IIS-hosted ASP.NET Core applications, Microsoft’s download page recommends the Hosting Bundle, which includes the.NET Runtime and IIS support. Select the bundle for the application’s intended release family rather than assuming that the newest major version replaces all older requirements.

3. Install through the appropriate management route​

For a manually managed Windows installation, Microsoft documents downloading the appropriate installer and running it. System-wide installation requires administrative privileges. In a managed estate, use the organization’s approved deployment route instead of bypassing its controls with an ad hoc installer.

Microsoft also cautions that some software manages its own.NET installation, which may not be available system-wide. That makes ownership important: identify whether the runtime belongs to the machine, a development tool, or an individual application before deciding how to update it.

4. Verify installation and application behavior​

Repeat the inventory commands and compare the output with the relevant November runtime and SDK numbers. Then perform application-specific checks—such as starting the desktop program, exercising a web endpoint, or running a representative build. The commands establish installation state; the recommended functional checks establish whether the workload still behaves as expected.

Self-contained applications need their own attention​

A shared-runtime update is not the whole story for applications that ship their own runtime. Microsoft Learn explains that a self-contained deployment bundles.NET and its libraries with the application, selecting the runtime at publication time rather than relying on the machine’s shared runtime during execution.

Consequently, updating the machine-wide runtime does not replace that bundled copy. Application owners need to republish and redeploy with the intended patched runtime; users of third-party software may need an updated application package from its vendor. Microsoft’s compatibility documentation explicitly warns that applications carrying their own runtime do not receive runtime security updates through the shared installation.

Publication settings deserve inspection as well. Microsoft documents that RuntimeFrameworkVersion can select an exact runtime version for self-contained deployments. A pinned value can therefore be relevant when a rebuilt application still carries an unexpected runtime. Check the project and publication configuration rather than assuming a newer SDK alone proves the output is patched.

The same review should include containerized workloads. Microsoft’s publishing documentation treats container images as deployable application artifacts. As an operational recommendation, verify the rebuilt image and redeploy it; do not use the host’s runtime inventory as evidence about software packaged inside the image.

.NET Framework: keep the November boundary clear​

The combined announcement directs readers to.NET Framework release notes, but the inspected index stops at October 13. Its documented acquisition routes remain Windows Update and Microsoft Update Catalog. There is no basis here for inventing November Framework KBs or carrying October’s known-issue statement forward into November.

Microsoft Learn’s October cumulative-update notes provide useful historical context. They identify KB5127690 for.NET Framework 3.5 and 4.8.1 on Windows 11 versions 24H2 and 25H2 and Windows Server 2025. They list KB5127691 for Framework 4.8.1 on Windows 11 version 26H1. These are October identifiers, not November recommendations.

Those October notes also explain why update-history checks can be confusing: an operating-system-level offering KB can select Framework-specific updates according to the installed Framework version. The offering identifier is not necessarily the identifier subsequently recorded as an installed update.

A further October distinction concerns Framework 3.5 on Windows 11 version 26H1, build 28000, and newer. Microsoft describes KB5127696 as a complete standalone Framework 3.5 product update replacing the previously installed version, rather than a conventional component-level cumulative patch. Administrators should preserve that version boundary when reconciling inventory.

The maintenance decision​

November’s work is best divided into three tracks: service existing.NET deployments, migrate workloads whose support ends, and assess.NET Framework updates separately. The first two intersect on November 10 for.NET 8 and 9; neither establishes a November Framework release.

The recommended completion test is more demanding than “the installer finished”: record the installed versions, account for application-bundled runtimes, validate the workload, and assign an owner to any remaining migration. That produces something more useful than a successful patch notification—a defensible picture of what is actually running.