Atualização emergencial do .NET: a correção precisa chegar ao artefato implantado

A Microsoft publicou correções extraordinárias para .NET 8, 9 e 10, com as versões 8.0.33, 9.0.22 e 10.0.14, além do .NET 11 Release Candidate 3.[5] O pacote inclui problemas novos e complementos para correções de 13 de outubro que não haviam resolvido integralmente os casos tratados.[5]

O impacto para engenharia não se resume a instalar uma atualização no servidor. A unidade que precisa receber a correção é o runtime efetivamente utilizado pela aplicação. O plano de implantação deve seguir essa unidade, não a conveniência do inventário de máquinas.

O que muda para quem desenvolve

A CVE-2026-111497 envolve estouro de buffer na descompressão Brotli, com possibilidade de leitura ou corrupção da memória por um atacante não autenticado.[5] Os caminhos citados incluem descompressão de requisições ASP.NET Core, respostas automáticas do HttpClient e APIs de System.IO.Compression; as duas formas automáticas não são habilitadas por padrão, e o .NET Framework não é afetado.[5]

A CVE-2026-114148 é outro problema: metadados inseguros de propriedade em tarballs Linux.[5] Para .NET 10 e 11, o escopo informado é source-build; em .NET 8 e 9, inclui também tarballs do ASP.NET Core, mesmo sem compilação local.[5] Logo, uma revisão de exposição precisa separar processamento de conteúdo comprimido de origem e instalação dos artefatos.

Como aplicar

Organize o inventário por modalidade de distribuição. Segundo o comunicado, aplicações dependentes do framework precisam de runtime atualizado e reinício; aplicações autossuficientes precisam ser reconstruídas e republicadas.[5] Containers exigem reconstrução e implantação com imagens atualizadas, enquanto consumidores de source-build e tarballs devem substituir os artefatos correspondentes.[5]

Minha proposta prática é produzir uma tabela por aplicação com modalidade, runtime esperado, imagem ou pacote implantado e evidência da substituição. Inclua também quem mantém a aplicação: uma entrega de terceiro precisa entrar no mesmo acompanhamento, mesmo quando a equipe não controla seu código.

Como experimento, escolha uma aplicação autossuficiente em homologação. Registre sua versão de runtime, atualize apenas o host e observe novamente o artefato. Depois reconstrua e implante a aplicação com a correção, documentando a diferença. O objetivo é comprovar o procedimento local, sem processar cargas maliciosas nem presumir resultados antes da observação.

Cuidados e limites

Não confunda recurso desabilitado por padrão com comprovação de ausência de exposição. Revise a configuração realmente utilizada e os caminhos explícitos de descompressão. Também não transforme o anúncio em afirmação de que toda aplicação .NET está igualmente vulnerável.

O comunicado inclui ainda complementos para corrupção de memória em SocketAsyncEventArgs e no depurador Blazor WebAssembly.[5] A revisão não deve parar no primeiro componente mencionado. Atualizar com rastreabilidade custa mais que marcar uma máquina como corrigida, mas fornece uma evidência muito mais útil de que a implantação recebeu a mudança.

Fonte

[5] Fonte: Microsoft .NET Blog