.NET 8 end of life: November 10, 2026 and what to do

TL;DR

• .NET 8 reaches end of life on November 10, 2026, seven days from today, according to endoflife.date.
• It is a long term support release: the record marks the line as LTS, and it lists no separate extended support date.
• The latest release in the line is 8.0.32, published on October 13, 2026. Update to it now.
• After the end of life date, new vulnerabilities in the runtime and libraries will not be fixed in this line, so plan the move to a supported release.
• Stackurity matches end-of-life data against your inventory every day, and flags .NET installed from Linux distribution packages.

What reaches end of life, in plain English

.NET is the runtime and class library that applications written in C# and other .NET languages run on. Each release line is supported for a limited time. While it is supported, Microsoft ships patch releases that fix bugs and security flaws. When it reaches end of life, that stops, even if a serious flaw is reported the following week.

The endoflife.date record for .NET shows that .NET 8 was released on November 14, 2023, and reaches end of life on November 10, 2026. It is marked as a long term support release. The record has no value for a separate end of active support date and none for extended support, so November 10, 2026 is the date to plan around.

Why it matters now

Nothing stops working on the day. Your applications keep running. What changes is the next time a flaw is found in the runtime: a supported line gets a patch and you update, while an unsupported line gets nothing, and you must move to a newer release under pressure. .NET flaws are real and sometimes exploited; our note on the Ubuntu advisory for three .NET flaws shows how that looks in practice.

There is also an audit cost. Customers and auditors ask which components are still supported, and an application on an unsupported runtime needs an exception, a compensating control or a dated upgrade plan. It is far easier to have the plan before the date than to explain the gap afterwards.

Runtime upgrades take time too. Applications may depend on libraries, container base images or hosting settings that tie them to one release line. Seven days is not enough to finish a careful upgrade of everything, but it is enough to find every machine, image and pipeline on .NET 8, patch to the latest release and put a date on each remaining move.

Am I affected?

You are affected if any server, container image, build agent or application you run uses the .NET 8 release line, in production, staging or a scheduled job. Any release whose version starts with the line number 8 belongs to it, up to the latest, 8.0.32.

To check one Linux machine by hand, run:

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

The first two list the installed runtimes and SDKs with their versions, and the third prints the full environment. To see whether .NET came from a distribution package, run one of these:

dpkg -l 'dotnet*'
rpm -qa 'dotnet*'

For a container image, run the same commands inside the container, and also read the base image named in each Dockerfile, since the runtime may come from the image rather than from your own packages. Also search repositories for project files that name the .NET 8 target framework.

One caveat applies to distribution packages. Linux distributions backport fixes, so a package version can look older than the upstream release while still containing a fix. The end of life date, however, is the upstream line's date: when the line ends, the distribution and Microsoft decide separately what they will keep supporting, so read your distribution's notice rather than relying on the upstream date alone.

How to upgrade away from .NET 8

1. Find every use of .NET 8. List servers, container images, build agents and repositories, and note the owner and environment of each.
2. Update each one to 8.0.32, the latest release in the line, run the tests and deploy. This keeps you on the newest patched code while you plan the larger move.
3. Choose the supported .NET release you will move to. Check Microsoft's .NET support policy for the current list, because it is not part of the data we cite here, and pick one your libraries and hosting platform support.
4. Change the target framework in your project files, rebuild, fix any warnings about removed or changed behaviour, and update base images and CI images to match.
5. Check again after deploying. Confirm that no host or image still reports the .NET 8 runtime, and record the machines you could not move before the date.

How to check with Stackurity

Stackurity keeps one live inventory of your servers, applications, repositories, container images, Kubernetes workloads and AWS managed services, and matches it against end-of-life dates every day. For .NET on Linux, it checks end of life from the distribution packages that install the runtime. Hosts that run it appear in a short list, most urgent first.

Be aware of the limits. .NET installed by script or tarball, and .NET on Windows, is not checked. Stackurity covers .NET on Linux from distribution packages only. After you upgrade, check again asks the agent for a fresh report and records whether the issue is really gone. See how Stackurity handles fixes in the docs. The core is open source, and Stackurity Cloud has a 14-day free trial without a card: start a free trial.

FAQ

When does .NET 8 reach end of life?

According to endoflife.date, .NET 8 reaches end of life on November 10, 2026. After that date the release line gets no further fixes.

Is .NET 8 still getting security updates?

Yes, until its end of life date. The latest release in the line is 8.0.32. After November 10, 2026 new vulnerabilities will be fixed only in newer release lines.

What should I upgrade .NET 8 to?

Move to a .NET release that Microsoft still supports. Check Microsoft's .NET support policy for the current list, then pick the supported release with the longest remaining support that your libraries and hosting platform accept.

Does Stackurity find .NET 8 on my servers?

On Linux servers, yes, when .NET came from a distribution package. Stackurity checks it for end of life from those packages. .NET installed by script or tarball, and .NET on Windows, is not checked.

Sources: endoflife.date record for .NET, Stackurity product facts.