Fim do suporte ao .NET 8 e 9: o risco que sua empresa precisa avaliar agora

Um sistema pode estar funcionando perfeitamente, cumprir todas as rotinas da empresa e, ainda assim, carregar um risco que não aparece em nenhum painel operacional: a plataforma sobre a qual ele executa está prestes a deixar de receber atualizações de segurança.

Esse é o cenário de organizações que ainda dependem do .NET 8 ou do .NET 9. A Microsoft definiu 10 de novembro de 2026 como a data de encerramento do suporte para ambas as versões. Depois disso, as aplicações não deixam de funcionar por causa do calendário, mas essas versões deixam de receber novas correções de segurança e suporte técnico da Microsoft.

Em 25 de outubro de 2026, a situação ganhou urgência adicional: a Microsoft publicou atualizações extraordinárias de segurança para o .NET 8, 9 e 10, incluindo uma vulnerabilidade relacionada ao processamento de dados comprimidos com Brotli.

A combinação dessas notícias merece atenção da direção de tecnologia. Mas a resposta responsável não é autorizar uma reescrita imediata nem determinar que todos mudem para o .NET 10 sem avaliação.

A pergunta mais importante é: quais sistemas estão realmente expostos, quais precisam de correção imediata e como atualizar o ambiente sem interromper aquilo de que a empresa depende?

O que termina em 10 de novembro de 2026 — e o que não termina

A Microsoft mantém políticas distintas para versões de suporte de longo prazo (LTS) e de suporte padrão (STS). Apesar de pertencerem a categorias diferentes, .NET 8 e .NET 9 encerram o suporte na mesma data.

A política oficial pode ser consultada na página de ciclo de vida do .NET. A Microsoft também publicou um comunicado específico sobre o encerramento do suporte ao .NET 8 e 9.

Fim do suporte não significa desligamento automático. Significa que a Microsoft deixará de fornecer novas atualizações de segurança, correções de manutenção e suporte técnico para essas linhas após a data anunciada. O risco pode crescer conforme novas vulnerabilidades forem descobertas.

Isso não implica que toda aplicação se tornará vulnerável no dia seguinte, nem que uma aplicação em .NET 10 estará automaticamente protegida. A exposição depende do código, das bibliotecas, do ambiente, dos recursos utilizados e das correções efetivamente implantadas.

Também é importante não confundir .NET 8/9 com .NET Framework 4.x, que possui um ciclo de vida e regras de suporte próprios. Inventários que classificam ambos apenas como “.NET” podem levar a decisões equivocadas.

O alerta de segurança de 25 de outubro muda a ordem das prioridades

O comunicado de atualizações extraordinárias (out-of-band) de outubro de 2026 anunciou os seguintes patches:

O aviso cita, entre outras correções:

• CVE-2026-111497: vulnerabilidade de corrupção de memória ligada à descompressão Brotli. Dependendo da forma de uso e das condições de exploração, pode permitir leitura ou corrupção de memória, indisponibilidade ou elevação de privilégios. A análise deve considerar componentes como APIs de compressão, descompressão de requisições ASP.NET Core e respostas HTTP automaticamente descomprimidas.
• CVE-2026-114148: problema de permissões e propriedade em determinados artefatos tarball para Linux. O impacto depende da origem e do tipo de distribuição; não se aplica indistintamente a qualquer aplicação executada em Linux.

A Microsoft esclarece que determinados mecanismos de descompressão de requisições e respostas não são habilitados por padrão. Portanto, o aviso não autoriza afirmar que todo serviço .NET está explorável. Autoriza, sim, verificar os cenários afetados e aplicar os patches oficiais com prioridade compatível com a exposição.

O comunicado também informa correções adicionais para problemas cujos avisos anteriores precisaram ser republicados. Por isso, uma organização que já aplicou as atualizações regulares de 13 de outubro não deve presumir que está coberta pelas atualizações extraordinárias de 25 de outubro.

A lição é simples: fim de suporte e resposta a vulnerabilidade são dois trabalhos diferentes, com prazos diferentes.

O primeiro exige uma estratégia de evolução. O segundo pode exigir ação imediatamente, mesmo para aplicações que já utilizam o .NET 10.

Sua empresa utiliza .NET 8 ou 9? O código-fonte não responde sozinho

Um inventário de repositórios é útil, mas não revela necessariamente o que está em execução. É possível encontrar um projeto configurado para net10.0 enquanto um serviço antigo, publicado meses antes, ainda está ativo em outro servidor.

Também é possível encontrar um host com runtime .NET 10 instalado e concluir, incorretamente, que todos os aplicativos foram atualizados.

Para determinar a exposição real, precisamos cruzar o que foi construído, o que foi publicado e o que está executando.

1. Identifique o portfólio que está em operação

Comece pelas aplicações e serviços efetivamente utilizados: APIs, sites ASP.NET Core, aplicações desktop, tarefas agendadas, serviços Windows, consumidores de filas, executáveis distribuídos e componentes mantidos por fornecedores.

Inclua ambientes de homologação e contingência quando eles armazenarem dados reais, permanecerem acessíveis ou forem promovidos para produção. Não esqueça instâncias antigas que continuam atendendo uma integração específica.

Para cada sistema, registre proprietário de negócio, responsável técnico, finalidade, criticidade, local de hospedagem e forma de distribuição.

2. Diferencie SDK, framework de destino e runtime

São informações relacionadas, mas não equivalentes.

• SDK: ferramentas utilizadas para compilar, testar e publicar.
• Framework de destino: indicado no projeto, normalmente por TargetFramework ou TargetFrameworks, define as APIs contra as quais ele é construído.
• Runtime efetivo: componentes usados para executar a aplicação no ambiente em que ela está implantada.

Dois comandos ajudam em servidores que possuem a CLI instalada:

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

O primeiro informa os runtimes instalados naquele ambiente; o segundo, os SDKs. Nenhum dos dois, isoladamente, prova qual runtime atende cada aplicação em produção. É necessário relacionar processos, configurações, pacotes publicados e infraestrutura.

A documentação da Microsoft sobre seleção de versões explica, inclusive, por que possuir um SDK novo não significa que a aplicação será executada automaticamente em uma versão principal nova.

3. Descubra como cada aplicação foi publicada

Aqui está uma das distinções mais importantes do diagnóstico.

Aplicação dependente do framework (framework-dependent): utiliza, normalmente, um runtime instalado ou fornecido pelo ambiente. A atualização correta desse runtime, acompanhada da reinicialização necessária, pode aplicar uma correção de segurança sem exigir recompilar o aplicativo — desde que as condições de compatibilidade e implantação sejam atendidas.

Publicação autossuficiente (self-contained): leva seu próprio runtime junto com a aplicação. Instalar uma versão nova no servidor não corrige automaticamente o runtime que foi empacotado. É necessário reconstruir e republicar o artefato com a versão corrigida.

Containers: o que importa é a imagem realmente em execução, não apenas a tag declarada no repositório. É preciso verificar imagem base, digest, data da construção e mecanismo de implantação. Depois, reconstruir e redeployar com as imagens corrigidas.

O mesmo raciocínio vale para executáveis distribuídos a clientes: instalar o SDK novo na máquina do desenvolvedor não atualiza versões antigas já entregues.

4. Inspecione dependências e sistemas administrados por terceiros

A exposição pode envolver pacotes NuGet, componentes ASP.NET Core, bibliotecas nativas, workloads, serviços gerenciados, imagens base e soluções fornecidas por parceiros.

Solicite ao fornecedor uma declaração verificável: qual versão está implantada, quais vulnerabilidades foram avaliadas, qual patch será aplicado e qual é o plano de suporte após 10 de novembro.

Não confunda contrato de suporte do fornecedor com atualizações oficiais do runtime. Um fornecedor pode continuar atendendo chamados, mas isso não significa que a Microsoft continuará corrigindo versões fora de suporte.

O inventário mínimo que a diretoria deveria receber

Antes de anunciar que “a empresa utiliza .NET 10”, eu esperaria ver um relatório orientado a sistemas e ambientes, não apenas uma lista de repositórios.

Cada linha precisa ter uma evidência verificável: manifesto de build, versão do artefato, inventário de imagem, configuração de hospedagem ou registro do deployment. Ausência de evidência deve aparecer como “não verificado”, nunca como “seguro”.

Esse relatório também revela um problema de governança: quantas aplicações existem, quantas a empresa realmente controla e quantas permanecem sem responsável?

Como priorizar: nem todo sistema apresenta o mesmo risco

Não recomendo tratar o assunto como uma campanha para alterar todos os arquivos de projeto ao mesmo tempo. Essa estratégia ignora consequências operacionais e tende a competir por recursos sem critério.

Uma priorização útil considera pelo menos cinco dimensões:

1. Exposição técnica: acesso pela internet, processamento de dados não confiáveis, funcionalidades afetadas pelos CVEs e controles de segurança existentes.
2. Impacto de negócio: risco para faturamento, atendimento, dados pessoais, obrigações contratuais e continuidade.
3. Defasagem comprovada: versão efetiva e patch realmente em produção, considerando a modalidade de publicação.
4. Dependências: fornecedores, componentes sem manutenção, sistemas integrados e restrições da infraestrutura.
5. Capacidade de resposta: testes disponíveis, automatização de deploy, mecanismos de reversão e conhecimento do sistema.

O resultado pode ser apresentado em faixas de ação:

A gravidade de um CVE é um insumo, não uma fórmula automática de prioridade. Uma aplicação sem acesso externo pode ainda processar arquivos fornecidos por terceiros; uma API pública pode ter controles que reduzam sua exposição. A classificação depende do caminho de ataque real e das consequências para o negócio.

Dois planos simultâneos: corrigir agora e modernizar com controle

Uma empresa que enfrenta esse cenário precisa operar em duas frentes coordenadas.

Frente A: aplicar as correções de segurança

A primeira frente responde ao que já foi divulgado e corrigido oficialmente.

• Confirmar quais versões e mecanismos estão em uso e se os avisos se aplicam.
• Para aplicações dependentes do framework, atualizar o runtime no ambiente correto e reiniciar os processos quando necessário.
• Para distribuições self-contained, reconstruir e republicar os aplicativos com runtime corrigido.
• Para containers, atualizar a imagem base, reconstruir o artefato e implantar a imagem corrigida, verificando o digest efetivo.
• Testar os fluxos mais críticos, acompanhar logs, métricas, erros e comportamento após a implantação.
• Registrar evidências de versão e patch na aplicação efetivamente em operação.

Esse plano inclui aplicações .NET 10, porque as atualizações extraordinárias também atingiram essa linha.

Aplicar o patch é necessário, mas não equivale a resolver o encerramento futuro do suporte para .NET 8/9. Da mesma forma, retargetar um projeto para net10.0 não substitui verificar se o patch correto foi implantado.

Frente B: preparar a migração para .NET 10 LTS

A segunda frente busca retirar a organização da dependência de versões que perderão suporte.

Ela começa pela revisão das mudanças potencialmente incompatíveis do .NET 10 e das dependências específicas de cada aplicação. A análise precisa cobrir ASP.NET Core, Entity Framework Core, pacotes NuGet, serialização, autenticação, bibliotecas nativas, workloads e comportamento operacional.

Mudar TargetFramework de net8.0 ou net9.0 para net10.0 é uma parte do trabalho, não uma evidência de migração concluída.

A decisão deve incluir a atualização dos ambientes de build, ferramentas e pipelines, testes e homologação, requisitos de sistema operacional, infraestrutura de hospedagem e novas imagens de distribuição.

É nesse ponto que o diagnóstico de arquitetura agrega valor: ele distingue aplicações com atualização simples daquelas que exigem correção de dependências, adaptação de integrações ou tratamento de dívida técnica.

O que uma migração controlada precisa testar

O fato de o aplicativo compilar não garante que seus processos de negócio continuam corretos. Em sistemas críticos, testes de unidade são necessários, mas insuficientes.

Contratos de integração: APIs, mensagens, filas, callbacks, arquivos, autenticação e sistemas externos precisam manter comportamento compatível com seus consumidores.

Persistência e dados: confirme consultas, mapeamentos, serialização, conversões, transações, migrações de schema e compatibilidade com versões anteriores dos serviços.

Segurança: valide configuração de TLS, autenticação, autorização, segredos, permissões e tratamento de dados. Uma atualização não deve reintroduzir acessos excessivos ou desativar controles para “fazer funcionar”.

Carga e resiliência: compare tempos de resposta, uso de memória, consumo de CPU, filas, timeouts, reinicialização e comportamento diante de falhas.

Experiência operacional: valide os percursos completos que sustentam o negócio: pedido até faturamento, agendamento até atendimento, emissão de documentos, fechamento financeiro, processamento noturno e recuperação de incidentes.

Use uma linha de base anterior à migração. Caso contrário, uma degradação moderada pode ser percebida apenas quando o volume de produção aumentar.

Rollback precisa ser uma capacidade comprovada, não uma promessa

É comum ler em projetos de migração: “se acontecer algum problema, voltamos a versão.” Esse plano só é válido quando alguém já demonstrou que a versão anterior pode voltar a operar com os dados e as integrações existentes.

Um rollback de código pode falhar se a atualização alterou o banco de dados de forma incompatível. Uma imagem anterior pode referenciar bibliotecas não disponíveis. Dois serviços implantados em momentos diferentes podem usar contratos que deixaram de ser compatíveis.

Para um plano de reversão confiável, eu exigiria:

• Artefatos anteriores identificáveis e recuperáveis, com dependências e imagens preservadas.
• Estratégia de mudanças de banco compatíveis entre versões, ou plano explícito de recuperação de dados.
• Testes de convivência entre componentes antigos e novos durante a implantação.
• Critérios objetivos para interromper a liberação: taxas de erro, falhas de transação, latência, integridade de dados e indicadores de negócio.
• Responsáveis, canais de comunicação e autoridade para decidir a reversão.
• Ensaio em ambiente representativo, com evidências registradas.

Existe ainda uma tensão importante: voltar para um artefato vulnerável pode restaurar a disponibilidade, mas reabrir o risco de segurança. Por isso, a contingência preferencial pode ser um artefato anterior já corrigido, uma liberação de correção adicional (roll-forward) ou uma medida temporária de contenção. A escolha exige avaliação explícita de risco.

Para ambientes com muitos serviços, liberação progressiva, observabilidade e compatibilidade entre versões são mais importantes do que simplesmente declarar que o deploy será “sem downtime”.

O prazo é curto: o que fazer antes de 10 de novembro?

A proximidade da data não autoriza improviso. Ela exige que a liderança separe decisões urgentes das que dependem de validação cuidadosa.

Imediatamente: verificar o boletim de 25 de outubro, identificar os sistemas potencialmente afetados, aplicar os patches apropriados e documentar eventuais exceções com proprietário e medidas de contenção.

Na sequência: concluir o inventário das aplicações .NET 8/9 implantadas, priorizar processos críticos e identificar obstáculos reais à migração.

Antes do encerramento do suporte, onde viável: migrar e homologar as aplicações prioritárias, com teste de reversão, monitoramento e aprovação do responsável pelo negócio.

Quando a migração não couber no prazo: registrar formalmente a exposição residual, definir restrições temporárias, responsabilidades, orçamento e um cronograma verificável de saída. Uma exceção documentada não prolonga o suporte da Microsoft, nem substitui uma correção indisponível.

O erro seria prometer que todos os sistemas serão migrados em poucos dias sem conhecer o portfólio. O outro erro seria ignorar a data porque “sempre funcionou assim”.

Quem responde por essa decisão — e qual investimento faz sentido?

A área de segurança pode identificar vulnerabilidades; a engenharia pode estimar o trabalho; a infraestrutura pode comprovar a versão implantada. Mas a aceitação de risco de um sistema crítico precisa envolver quem responde pelo negócio.

Ao CTO e ao CIO cabe consolidar uma visão que mostre quais aplicações exigem atualização, qual esforço de correção é necessário, quais dependências impedem mudanças e qual é a estratégia para preservar a operação.

O orçamento precisa considerar não apenas o código alterado, mas também testes, ambientes, atualização de bibliotecas, execução controlada, suporte, documentação e eventual convivência entre versões.

Ao mesmo tempo, evite transformar o prazo em uma justificativa automática para substituir plataformas inteiras. Às vezes a correção é simples; às vezes ela expõe uma dependência estrutural. Uma avaliação técnica bem feita impede tanto o subinvestimento perigoso quanto a modernização desproporcional.

O resultado desejado é um roteiro de decisões priorizadas: corrigir, migrar, reduzir exposição, substituir componentes inviáveis ou aposentar aplicações sem justificativa de continuidade.

Perguntas frequentes

O .NET 8 vai parar de funcionar em 10 de novembro de 2026?

Não. O encerramento do suporte não desliga aplicações existentes. O que termina é o fornecimento normal de novas correções de segurança, manutenção e suporte técnico para .NET 8 e .NET 9. Isso aumenta o risco de manter essas versões em produção.

Se eu instalar o SDK do .NET 10, meus sistemas .NET 8 e 9 estarão atualizados?

Não. SDK de desenvolvimento, framework de destino e runtime utilizado pela aplicação são componentes distintos. A verificação precisa ser feita sobre o aplicativo realmente implantado e seu modelo de publicação.

Aplicar o patch de 25 de outubro elimina a necessidade de migrar?

Não. Os patches corrigem vulnerabilidades específicas dentro do período de suporte. Eles não alteram a data de encerramento de suporte do .NET 8 e 9.

Uma aplicação self-contained recebe o patch quando atualizo o servidor?

Não necessariamente. Nessa modalidade, o runtime acompanha o aplicativo e deve ser corrigido por meio de nova publicação. Em containers, é necessário reconstruir e implantar as imagens atualizadas.

Isso também significa o fim do .NET Framework 4.8?

Não. O .NET Framework 4.x é um produto com política de ciclo de vida própria. Ele exige avaliação específica, mas não deve ser incluído automaticamente no mesmo prazo do .NET 8/9.

Toda aplicação precisa migrar diretamente para .NET 10?

O .NET 10 é o destino estável LTS recomendado pela Microsoft para essas aplicações. A estratégia concreta depende de compatibilidade, fornecedores, sistemas operacionais, custos de transição e requisitos de negócio. O prazo de suporte precisa orientar a decisão, mas não elimina a necessidade de testes e planejamento.

Conclusão: o problema não é somente a versão, é a falta de visibilidade

O encerramento do suporte ao .NET 8 e 9 tem data definida. As atualizações extraordinárias de outubro mostram que vulnerabilidades podem exigir resposta mesmo antes de uma migração de versão principal.

O desafio empresarial não é descobrir quantos repositórios contêm net8.0. É saber quais aplicações executam versões afetadas, onde estão, que dados processam, de quais dependências precisam e como podem ser corrigidas sem interromper o negócio.

Uma organização madura não escolhe entre segurança e continuidade. Ela constrói condições para preservar ambas: inventário confiável, priorização por risco, atualização de segurança, testes, estratégia de migração e um plano de recuperação realista.

Sua empresa precisa avaliar aplicações .NET antes de uma atualização? Podemos ajudar a identificar riscos e definir um plano de modernização.

A consultoria em arquitetura e engenharia de software oferece apoio para diagnóstico de arquitetura, identificação de dependências e elaboração de um roadmap de modernização. Os projetos comerciais são conduzidos pela IVATEC.

Fontes oficiais e leitura complementar

• Microsoft — .NET 8 and .NET 9 will reach End of Support on November 10, 2026
• Microsoft — .NET October 2026 Out-of-Band Security Updates
• Microsoft — Política oficial de suporte do .NET
• Microsoft Learn — Seleção de versões do .NET
• Microsoft Learn — Mudanças incompatíveis no .NET 10

Informações de versões e patches verificadas com base nos comunicados disponíveis em 26 de outubro de 2026. Confirme sempre os boletins oficiais mais recentes antes de executar mudanças em produção.