.NET 8 and 9 End Support Amid Record Patch Tuesday

DEV Community

.NET 8 and .NET 9 lost support on the day of the biggest Patch Tuesday ever

This post was originally published in Portuguese on my blog: .NET 8 e .NET 9 saíram de suporte no dia do maior Patch Tuesday da história. On Tuesday, November 10, two things happened that look like separate news items and that, in my opinion, are the same story. .NET 8 and .NET 9 went out of support. And on the same day Microsoft shipped the largest Patch Tuesday I've ever seen: close to 1,100 security fixes, depending on who is counting. What happened The schedule had been announced since June. On November 10, 2026, .NET 8 (LTS) and .NET 9 (STS) stopped receiving security fixes and technical support. .NET 9 ended together with 8 because the support window for STS releases was stretched from 18 to 24 months, and the math landed on the same date. The official recommendation is to move to .NET 10, which is LTS and supported until November 2028. Your application keeps running, nobody is going to switch anything off, but whatever gets discovered from now on won't be fixed for those versions. As for Patch Tuesday, according to Krebs on Security it fixed 1,093 vulnerabilities, 63 of them critical and one actively exploited: a spoofing flaw in Outlook (CVE-2026-124194). Other outlets counted 1,094, 1,095 or even 1,235, because each one decides differently what goes into the tally (first-party products, third-party components, cloud service flaws). What matters is the order of magnitude. A year ago the monthly average was around 100 fixes. October had more than 1,400, and the 2026 total is already past 5,100. Microsoft itself attributes the jump to the evolution of artificial intelligence in the search for flaws. Why this matters if you work in tech For years, "upgrade the framework version" sat in the backlog with a tech-debt label and low priority. The argument was reasonable: if it works, don't touch it. But that argument assumes the pace of flaw discovery is slow and predictable. When the volume of published vulnerabilities grows tenfold in a year, running an unsupported version stops being an abstract risk and becomes a window that stays open and visible to anyone who reads the bulletins. There's also the less glamorous side: many people don't get to choose the version. Anyone who works with enterprise systems knows that one .NET 8 application running on a server managed by another team, under a contract with a vendor who "will still evaluate the migration". For that scenario, Microsoft's guidance is direct: ask the vendor for an updated version. And if you use Visual Studio 2022, an upcoming update will flag the .NET 8 and 9 components as out of support, so it's worth checking your installer settings before being surprised. A number from Chris Goettl, at Ivanti, helps put it in perspective: of roughly 95,000 CVEs assigned in 2026, only 217 made it onto CISA's list of known exploited vulnerabilities. In other words, the vast majority of flaws never turn into attacks. But nobody knows in advance which one will be the next of those 217, and that's where a framework without fixes weighs more than an up-to-date operating system. My take I think we're entering a phase where the software lifecycle becomes an architecture decision, not a footnote. When flaws were discovered slowly, you could live one version behind without much anxiety. With accelerated discovery, the time between "known flaw" and "exploited flaw" shrinks, and the advantage of being on a maintained version grows in the same proportion. No need to panic either. Moving from .NET 8 to 10 is usually, in most projects, a change of the TargetFramework, a round of tests and a careful read of the breaking changes. What really takes work are the old dependencies, the pipelines pinned to specific container images and the hosting environments nobody has updated in two years. If you haven't yet inventoried which services run on which version, this week is a good time to start. A simple spreadsheet with service name, version and owner already solves half the problem. And one car...

Powered by Readybot.io