.NET 9.0.21 corrige falhas de segurança: como atualizar

Resposta rápida

Se uma aplicação ou servidor ainda usa .NET 9 anterior ao 9.0.21, atualize o runtime e, quando houver desenvolvimento no host, o SDK para uma versão que inclua o runtime corrigido. A Microsoft publicou o .NET 9.0.21 e os SDKs 9.0.319 e 9.0.122 em 13 de outubro de 2026 e orienta usuários de patches anteriores a instalar a correção.

Não basta atualizar a máquina de desenvolvimento. Confirme o runtime realmente carregado pelo processo em cada servidor, imagem de contêiner e artefato self-contained. O .NET 9 está em manutenção e encerra suporte em 10 de novembro de 2026; portanto, aplique o patch agora e programe a migração para uma versão suportada, preferencialmente o .NET 10 LTS, como trabalho separado.

Por que esta atualização é urgente

As notas oficiais classificam o 9.0.21 como uma atualização com correções de segurança e não relacionadas à segurança. A relação inclui vulnerabilidades de execução remota de código, elevação de privilégio, contorno de recurso de segurança, divulgação de informações e negação de serviço em .NET, ASP.NET Core, SDK, Visual Studio e Microsoft QUIC.

Essa lista não significa que toda aplicação .NET 9 seja explorável da mesma forma. A exposição depende do componente, do sistema operacional, da arquitetura e do caminho de entrada usado pela aplicação. A decisão segura é inventariar primeiro, aplicar o patch suportado e usar os avisos do Microsoft Security Response Center para avaliar cada CVE relevante, sem adivinhar impacto a partir do título.

Descubra o que está instalado e o que o processo usa

Execute dotnet --info para identificar arquitetura, caminho base, SDK selecionado e runtimes visíveis ao comando. Depois use dotnet --list-sdks e dotnet --list-runtimes. Em servidores web, procure Microsoft.AspNetCore.App e Microsoft.NETCore.App; em estações de build, confirme também o SDK 9.0.319 ou 9.0.122.

Faça a verificação no mesmo usuário, contêiner e arquitetura do processo de produção. Um terminal x64 não lista instalações x86 e um shell no host não prova a versão dentro do contêiner. Compare também o caminho do executável usado pelo serviço, porque instalações paralelas em Program Files, /usr/share/dotnet, /usr/lib/dotnet ou no diretório da aplicação podem produzir resultados diferentes.

• Registre dotnet --info, dotnet --list-runtimes e dotnet --list-sdks em cada ambiente.
• Confirme a arquitetura do processo e o caminho do executável dotnet usado pelo serviço.
• Revise global.json, arquivos de projeto, perfil de publicação e imagem base do contêiner.
• Separe aplicações framework-dependent, self-contained e containers em listas diferentes.
• Associe cada serviço a um responsável, janela de mudança e plano de reversão.

Atualize Windows, IIS, Linux e macOS pelo método correto

Em Windows com IIS, use o Hosting Bundle correspondente quando a aplicação depende do ASP.NET Core Module. Reinicie os serviços ou o servidor conforme a política operacional e confirme depois a versão carregada. Em máquinas de desenvolvimento, o SDK atualizado já inclui um runtime correspondente; não é necessário instalar o runtime separadamente apenas para satisfazer o mesmo SDK.

No Linux, prefira o mesmo gerenciador e repositório usados na instalação original. apt, dnf, yum e zypper tratam pacotes e dependências de formas diferentes. Instalações feitas por dotnet-install ou extração de tarball exigem atualização manual no mesmo caminho. No macOS e em ambientes mistos, valide arm64 e x64 separadamente para não corrigir uma arquitetura e deixar outra antiga.

• Faça backup da configuração e registre a versão atual antes da mudança.
• Instale o runtime 9.0.21 ou o Hosting Bundle e o SDK 9.0.319 ou 9.0.122 quando necessário.
• Reinicie o serviço, pool ou host que mantém o processo antigo em memória.
• Execute novamente os comandos de inventário no contexto do serviço.
• Remova versões antigas somente depois de validar dependências e o mecanismo de reversão.

Contêiner não atualiza sozinho

As imagens oficiais do .NET foram atualizadas para esta versão, mas uma imagem já construída continua contendo as camadas antigas. Refaça o pull da imagem base, reconstrua sem reutilizar uma camada desatualizada, publique um novo digest e substitua os pods ou tarefas. Apenas reiniciar o contêiner existente não troca o runtime empacotado.

Confira separadamente as etapas de build e runtime do Dockerfile. A imagem sdk usada para compilar e a imagem aspnet ou runtime usada para executar podem estar em patches distintos. Tags amplas como 9.0 são convenientes, mas o registro do digest efetivamente implantado é o que permite provar qual conteúdo chegou à produção.

• Atualize ou baixe novamente as imagens mcr.microsoft.com/dotnet/sdk:9.0 e aspnet:9.0 usadas no projeto.
• Reconstrua a imagem e confira dotnet --info dentro do estágio final.
• Publique uma tag imutável e registre o digest da imagem.
• Substitua as instâncias antigas e aguarde readiness antes de encerrar as anteriores.
• Confirme que nenhum nó continua executando o digest vulnerável.

Aplicações self-contained precisam ser publicadas novamente

Uma aplicação framework-dependent usa o runtime compartilhado instalado no host. Já uma publicação self-contained leva o runtime dentro do próprio artefato. Nesse segundo caso, instalar 9.0.21 no sistema não corrige o binário já publicado; é preciso recompilar e republicar para cada combinação de sistema operacional e arquitetura usada.

Arquivos únicos também podem ser framework-dependent ou self-contained. Não use apenas a extensão ou o tamanho do executável para decidir. Revise SelfContained, RuntimeIdentifier, PublishSingleFile e o comando de publish, gere novamente o artefato e valide a versão no ambiente de execução.

Evite que global.json e CI mantenham o SDK antigo

global.json pode fixar um SDK anterior mesmo depois de a máquina receber o novo pacote. Verifique version e rollForward, atualize a versão intencionalmente e confirme com dotnet --version no job de CI. A versão do SDK e a versão do runtime não têm numeração idêntica: para este patch, as notas oficiais listam SDK 9.0.319 e 9.0.122 com runtime 9.0.21.

Caches de ferramentas e imagens próprias de runners também podem preservar cópias antigas. Limpe apenas os caches relacionados, registre a saída dos comandos de versão no job e fixe a imagem de build por digest quando a rastreabilidade for mais importante que receber patches automaticamente.

Valide o serviço depois da atualização

A atualização não termina quando o instalador conclui. Teste health checks, autenticação, uploads, serialização, acesso a banco, filas, chamadas HTTP, TLS e os caminhos que recebem dados não confiáveis. Em IIS, confira o Application Pool e o ASP.NET Core Module; em Linux, revise journalctl ou os logs do orquestrador; em contêineres, compare o digest planejado ao digest em execução.

Monitore taxa de erro, latência, reinícios e consumo de memória durante uma janela suficiente para o tráfego real. Se houver regressão, não volte silenciosamente para um runtime vulnerável. Isole o serviço, confirme se o erro pertence ao patch, use o plano de reversão apenas com avaliação de risco e abra a correção da aplicação ou da dependência incompatível.

• Confirme que o endpoint de saúde responde e que o processo foi realmente reiniciado.
• Teste login, autorização e uma operação de leitura e escrita representativa.
• Valide DNS, TLS e resposta HTTP dos endpoints externos usados pelo serviço.
• Compare erros e latência com a linha de base anterior.
• Registre versão, arquitetura, digest, horário e resultado da validação.

Limitações e próxima ação útil

Este guia foi verificado em 19 de outubro de 2026. Ele resume a atualização oficial do .NET 9.0.21, mas não substitui os avisos individuais do MSRC, o inventário do fornecedor de nuvem nem testes específicos da aplicação. Serviços gerenciados podem aplicar patches em cronogramas próprios, e uma ferramenta local pode não enxergar runtimes empacotados em imagens ou artefatos self-contained.

Comece agora pelo serviço público com maior exposição: registre runtime, SDK, modelo de implantação e digest; atualize uma instância de teste; execute o checklist funcional; depois faça rollout gradual. Em paralelo, abra uma tarefa com data e responsável para sair do .NET 9 antes de 10 de novembro de 2026, em vez de tratar o 9.0.21 como solução permanente.

Fontes consultadas

Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.

• .NET 9.0.21 release notes.NET / Microsoft
• Download .NET 9.0Microsoft
• .NET and .NET Core support policyMicrosoft
• Check installed .NET versionsMicrosoft Learn
• Remove the .NET runtime and SDKMicrosoft Learn
• .NET container imagesMicrosoft Learn
• .NET application publishing overviewMicrosoft Learn
• Microsoft Service HealthMicrosoft