Programação Por Equipe DevBras

Capa do artigo: Atualização do .NET fora do ciclo: o que corrigir agora

Atualização do .NET fora do ciclo: o que corrigir agora

.NET 8.0.33, 9.0.22 e 10.0.14 corrigem o Brotli e refazem dois patches de 13/10. Veja se você está exposto e como atualizar host, app e container.

No domingo, 25 de outubro de 2026, entre 15h e 16h10 (horário de Brasília), a Microsoft publicou uma atualização de segurança do .NET fora do calendário mensal. As versões novas são .NET 8.0.33, 9.0.22 e 10.0.14, além do .NET 11 RC3. Elas corrigem uma falha nova no decodificador Brotli, corrigem a forma como alguns tarballs do Linux registram o dono dos arquivos e trazem de novo duas correções de 13 de outubro que, segundo a própria Microsoft, não resolveram o problema por completo.

Na prática: se você atualizou o .NET no dia 13 e parou por aí, ainda falta atualizar. Este guia mostra, nesta ordem, como descobrir quais runtimes estão instalados, como saber se o seu código usa os trechos afetados, como atualizar cada tipo de deploy (host, app self-contained, container e CI) e como conferir no fim. Rodamos os comandos num Linux com o SDK 10.0.403. As saídas mostradas abaixo vêm desse teste.

As quatro falhas, em uma frase cada

  • CVE-2026-111497 (Brotli, CVSS 8,1, todas as plataformas): escrita fora dos limites no decodificador Brotli que o .NET usa. Um atacante sem login pode ler ou corromper memória do processo. O app só fica exposto se descompactar Brotli que veio de fora. Detalhes no anúncio #494 e no MSRC. O .NET Framework não é afetado.
  • CVE-2026-70197 (System.Net.Sockets, CVSS 8,1, só Windows): reaproveitar um SocketAsyncEventArgs entre sockets UDP IPv4 e IPv6 pode deixar um buffer pequeno demais em cache e permitir escrita fora dos limites em ReceiveFromAsync. A falha foi divulgada em 13/10, mas a correção não entrou nos pacotes daquele dia (anúncio #493).
  • CVE-2026-102870 (debugger do Blazor WebAssembly, CVSS 8,8, .NET 10 e 11): um valor controlado pelo atacante pode executar código na máquina do desenvolvedor quando ele avalia uma expressão durante a depuração. A correção de 13/10 estava incompleta (anúncio #492).
  • CVE-2026-114148 (tarballs Linux, CVSS 7,8, local): arquivos com dono errado nos tarballs do ASP.NET Core 8 e 9 e em todos os tarballs de source-build. Se a extração preservou o dono, uma conta local pode alterar arquivos usados por um processo com mais privilégio (anúncio #495).

O resumo oficial está no anúncio #496 e no blog do .NET. As versões de SDK que já trazem o runtime corrigido são 8.0.427 e 8.0.133, 9.0.320 e 9.0.123, 10.0.403 e 10.0.114. Os advisories não citam exploração ativa.

Passo 1: veja quais runtimes estão na máquina

O comando que a Microsoft indica é o dotnet --list-runtimes. Para não comparar versão de cabeça, passe a saída por um filtro que marca o que está abaixo do mínimo de cada linha (patch 33 no 8, 22 no 9, 14 no 10):

dotnet --list-runtimes | awk '
BEGIN { min["8"]=33; min["9"]=22; min["10"]=14 }
{
  split($2, v, ".")
  if (!(v[1] in min)) { print "CONFERIR", $1, $2; next }
  print ((v[3]+0 >= min[v[1]]) ? "OK      " : "ATUALIZAR"), $1, $2
}'

No nosso teste, com o runtime 10.0.13 instalado ao lado do 10.0.14, a saída foi esta:

ATUALIZAR Microsoft.AspNetCore.App 10.0.13
OK       Microsoft.AspNetCore.App 10.0.14
ATUALIZAR Microsoft.NETCore.App 10.0.13
OK       Microsoft.NETCore.App 10.0.14

Ter o 10.0.14 instalado não basta. É preciso saber qual runtime cada app carrega. Um app framework-dependent compilado para net10.0 pede a versão 10.0.0 no runtimeconfig.json. Pela regra padrão de seleção, ele sobe no patch mais novo instalado. No nosso teste, o app imprimiu .NET 10.0.14. Mas a regra muda se alguém configurou rollForward ou fixou a versão, e o anúncio #495 pede que você confira o runtime que cada aplicação usa de fato, não só o dotnet que aparece no PATH. Uma forma simples é expor ou registrar RuntimeInformation.FrameworkDescription na subida do serviço.

Apps self-contained e containers levam o próprio runtime, e o --list-runtimes do host não enxerga nenhum dos dois. Na pasta publicada de um app self-contained, a versão aparece no .deps.json:

grep -oE 'runtimepack\.[A-Za-z.]+\.Runtime\.[a-z0-9-]+/[0-9.]+' *.deps.json | sort -u
runtimepack.Microsoft.AspNetCore.App.Runtime.linux-x64/10.0.14
runtimepack.Microsoft.NETCore.App.Runtime.linux-x64/10.0.14

Passo 2: descubra se o seu código descompacta Brotli

A falha do Brotli é a mais grave do pacote, mas o advisory é claro: ter o pacote instalado não deixa o app exposto. A exposição vem de três caminhos, e nenhum deles vem ligado por padrão:

  1. descompressão de requisição do ASP.NET Core (AddRequestDecompression) com suporte a br;
  2. HttpClient com AutomaticDecompression incluindo DecompressionMethods.Brotli ou DecompressionMethods.All;
  3. uso direto de BrotliStream ou BrotliDecoder em dados que vêm de fora.

Para varrer um repositório, um grep resolve. Testamos num projeto de exemplo que usa os três caminhos:

grep -rnE --include='*.cs' \
  'AddRequestDecompression|AutomaticDecompression|DecompressionMethods\.(Brotli|All)|BrotliStream|BrotliDecoder' .

./LojaApi/Program.cs:8:builder.Services.AddRequestDecompression();
./LojaApi/Program.cs:14:        AutomaticDecompression = DecompressionMethods.All
./LojaApi/Program.cs:25:    await using var br = new BrotliStream(req.Body, CompressionMode.Decompress);

Um detalhe que muita gente esquece: AddRequestDecompression() sem opções já aceita br. No teste, um corpo de 13 bytes enviado com Content-Encoding: br chegou ao endpoint como 100.000 bytes descompactados. Se a busca encontrar qualquer um desses trechos em código que recebe dados da internet (API pública, webhook, integração com parceiro, importação de arquivo), esse serviço vai para o topo da fila. Se não encontrar nada, atualize do mesmo jeito, mas sem a urgência de parar o resto. Para ver quais outros softwares usam a mesma biblioteca (Python, curl, Node, Envoy), leia o nosso guia anterior sobre a falha no Brotli CVE-2026-111497.

Passo 3: atualize do jeito certo para cada deploy

App framework-dependent no servidor

Instale o runtime novo e reinicie a aplicação. Um processo que já estava rodando continua com o runtime antigo carregado na memória. Os pacotes do repositório da Microsoft já estavam no ar quando conferimos, na manhã de 26/10: no packages.microsoft.com para Debian 12 havia 8.0.33, 9.0.22 e 10.0.14 (runtime, ASP.NET Core e SDK 8.0.427/9.0.320/10.0.403), e no de Ubuntu 22.04 havia o 8.0.33. Com esse repositório configurado, a atualização é a de sempre:

sudo apt update
sudo apt install --only-upgrade aspnetcore-runtime-8.0 dotnet-runtime-8.0
sudo systemctl restart minha-api

Atenção a quem usa os pacotes da própria Canonical (dotnet8, dotnet10) no Ubuntu. Até cerca de 9h15 de 26/10, o Launchpad ainda mostrava 8.0.32 e 10.0.13 como as versões mais novas publicadas, de 19/10. A página do Ubuntu para a CVE-2026-111497 não listava pacotes do .NET, só brotli (em avaliação) e nodejs. No Debian, o security tracker mostra a libbrotli do sistema já corrigida em bookworm e trixie, mas o advisory da Microsoft lista o decodificador afetado dentro dos pacotes do runtime do .NET. Atualizar a biblioteca do sistema não substitui o runtime 8.0.33/9.0.22/10.0.14. Se a distro ainda não publicou, use o repositório da Microsoft ou a instalação manual.

App self-contained e NativeAOT

Aqui instalar runtime no host não muda nada. É preciso gerar o app de novo com o SDK corrigido e publicar. No NativeAOT, o anúncio #494 avisa que o decodificador fica embutido no executável, então também é preciso atualizar referências explícitas ao compilador ou aos runtime packs. Depois do publish, confira o .deps.json com o comando do passo 1.

Containers

Conferimos o registry da Microsoft (MCR) pela API, em 26/10. As tags aspnet:8.0.33, aspnet:9.0.22 e aspnet:10.0.14 existem (as mesmas para runtime), e as do SDK seguem a versão do SDK: sdk:8.0.427, sdk:9.0.320, sdk:10.0.403. As tags curtas 8.0, 9.0 e 10.0 já apontam para o mesmo digest das versões corrigidas. Você mesmo pode conferir sem Docker instalado:

curl -s https://mcr.microsoft.com/v2/dotnet/aspnet/tags/list | grep -o '"10.0.14"'
"10.0.14"

O que não atualiza sozinho é a imagem que você já gerou. Refaça o build forçando o download da base e suba de novo:

docker build --pull --no-cache -t minha-api:2026-10-26 .
docker compose up -d
docker exec minha-api dotnet --list-runtimes

Se o Dockerfile fixa a versão completa (FROM mcr.microsoft.com/dotnet/aspnet:10.0.13), troque para a nova. Uma imagem com o runtime antigo continua vulnerável mesmo com o host atualizado. Quem gerencia vários servidores pelo Dockyard ou outro painel Docker pode usar a lista de stacks para não esquecer nenhum serviço antigo na hora do redeploy.

Pipelines de CI

No domingo à tarde, durante cerca de uma hora, os links aka.ms do canal mais recente respondiam com erro 409, e o dotnet-install.sh --channel e o actions/setup-dotnet falhavam. A Microsoft confirmou o problema e avisou que estava resolvido por volta de 17h30 de 25/10 no issue de feedback da versão. Se algum pipeline quebrou nesse horário, rode de novo. Se o pipeline fixa a versão do SDK num global.json, suba para 8.0.427, 9.0.320 ou 10.0.403. Para travar as versões de pacotes no CI, veja o nosso guia de versão de pacote NuGet.

Passo 4: ASP.NET Core instalado por tarball no Linux

A CVE-2026-114148 vale para quem instalou o ASP.NET Core 8 ou 9 a partir de aspnetcore-runtime-*.tar.gz, aspnetcore-runtime-composite-*.tar.gz ou aspnetcore-targeting-pack-*.tar.gz. No .NET 10 e 11, só os tarballs de source-build são afetados. Restaurar pacotes NuGet não traz o problema. Baixamos os dois tarballs de linux-x64 e listamos o dono numérico de cada arquivo:

tar --numeric-owner -tvzf aspnetcore-runtime-8.0.32-linux-x64.tar.gz | head -2
drwxr-xr-x 1000/1000         0 2026-10-04 18:07 ./
-rwxr-xr-x 1000/1000     68360 2026-10-04 17:57 ./dotnet

tar --numeric-owner -tvzf aspnetcore-runtime-8.0.33-linux-x64.tar.gz | head -1
drwxr-xr-x 2001/2001         0 2026-10-22 17:32 ./

No 8.0.32, todos os 340 itens vinham com UID e GID 1000. Em muitas distros, esse é o número do primeiro usuário comum criado na máquina. Se um administrador extraiu esse arquivo como root preservando o dono, esse usuário passou a ser dono do runtime que serviços privilegiados executam. No 8.0.33 os itens vêm com 2001/2001, o mesmo número que vimos no tarball do runtime base. Mesmo assim, a orientação oficial é não confiar no dono que vem no arquivo.

Por isso, não extraia o tarball novo por cima do antigo: o anúncio diz que isso não corrige a instalação existente. O roteiro oficial é parar os serviços, baixar o tarball corrigido, conferir o checksum, extrair numa pasta nova e vazia sem restaurar dono, apontar os serviços para ela, reiniciar e só depois aposentar a pasta antiga. Se você suspeitar de comprometimento, guarde a pasta antiga como evidência antes. Testamos assim:

curl -s https://builds.dotnet.microsoft.com/dotnet/checksums/8.0.33-sha.txt \
  | grep aspnetcore-runtime-8.0.33-linux-x64.tar.gz
sha512sum aspnetcore-runtime-8.0.33-linux-x64.tar.gz   # os dois hashes têm que bater

sudo mkdir /opt/dotnet-8.0.33
( umask 022
  sudo tar -xzf aspnetcore-runtime-8.0.33-linux-x64.tar.gz -C /opt/dotnet-8.0.33 \
      --no-same-owner --no-same-permissions )

# nada gravável por grupo/outros e nada fora do root:
find /opt/dotnet-8.0.33 \( -perm -g+w -o -perm -o+w \) -print
find /opt/dotnet-8.0.33 ! -user root -print

Os dois find no fim devem voltar vazios. Os mesmos cuidados com dono e permissão de arquivo aparecem quando se tira o root de um container. O passo a passo está no post sobre container Docker sem root. Se uma imagem própria foi montada a partir desse tarball, refaça a imagem com a extração controlada. Alterar só o container que está rodando não corrige a imagem.

Passo 5: Blazor WebAssembly standalone (.NET 10 e 11)

Esse caso é diferente dos outros: atualizar o runtime não corrige. Quem precisa agir é quem depura apps Blazor WebAssembly com os pacotes Microsoft.AspNetCore.Components.WebAssembly.Server ou Microsoft.AspNetCore.Components.WebAssembly.DevServer, que precisam ir para 10.0.14 (ou 11.0.0-rc.3.26522.148). Num projeto criado com o template e voltado para 10.0.13, o NuGet mostra o que falta:

dotnet list package --outdated
   Top-level Package                                         Requested   Resolved   Latest
   > Microsoft.AspNetCore.Components.WebAssembly             10.0.13     10.0.13    10.0.14
   > Microsoft.AspNetCore.Components.WebAssembly.DevServer   10.0.13     10.0.13    10.0.14

dotnet add package Microsoft.AspNetCore.Components.WebAssembly.DevServer --version 10.0.14

Atualize a família Microsoft.AspNetCore.Components.WebAssembly* toda junta. No teste, tentar subir só um pacote para 10.0.14 com outro preso em 10.0.13 gerou erro de downgrade no restore. Depois, feche e abra de novo o debugger e a IDE, como pede o anúncio #492. Projetos criados com o SDK 10.0.403 já saem do template com 10.0.14.

Passo 6: serviços Windows que usam UDP

A CVE-2026-70197 só existe no Windows e exige reaproveitar o mesmo SocketAsyncEventArgs entre sockets UDP IPv4 e IPv6. O advisory lista tanto o runtime CoreCLR quanto o Mono do .NET 8. Para achar candidatos no código:

grep -rnE --include='*.cs' 'SocketAsyncEventArgs|ReceiveFromAsync' .

Atualizar é o mesmo procedimento do passo 3. Quem instalou o SDK pelo Visual Studio recebe o aviso de atualização pela própria IDE. Apps self-contained precisam ser recompilados e publicados de novo.

Se não der para atualizar hoje

A Microsoft publicou mitigações para o Brotli, com um aviso importante: só mexa se você já usa descompressão. Não adicione AddRequestDecompression nem AutomaticDecompression num app que não usa, porque ligar descompressão automática traz risco de negação de serviço mesmo sem Brotli. Se já usa, tire o br:

builder.Services.AddRequestDecompression(options =>
{
    options.DecompressionProviders.Remove("br");
});

Testamos: com essa linha, o mesmo corpo Brotli de 13 bytes chegou ao endpoint como 13 bytes, sem descompactar, e uma requisição gzip continuou funcionando. No HttpClient, troque All ou Brotli por DecompressionMethods.GZip | DecompressionMethods.Deflate no handler que você já tem. Em código que chama BrotliStream ou BrotliDecoder diretamente, pare de passar dados de origem não confiável. Teste antes de publicar e trate isso como medida temporária. A correção é o runtime novo.

Como saber que terminou

O trabalho só termina quando cada serviço em produção estiver rodando 8.0.33, 9.0.22, 10.0.14 ou o RC3, e não apenas quando o pacote estiver instalado. Na prática, isso quer dizer: o filtro do passo 1 sem nenhuma linha "ATUALIZAR" nos hosts que importam (ou com a versão antiga sabidamente sem uso), os processos reiniciados depois da instalação, os apps self-contained e NativeAOT publicados de novo, os containers em produção criados a partir da imagem nova (o docker exec ... dotnet --list-runtimes confirma), as instalações por tarball do ASP.NET Core 8/9 substituídas por uma pasta nova e os pacotes do debugger do Blazor em 10.0.14. Vale registrar onde cada serviço estava e quando foi atualizado. Se outro advisory vier na sequência, a próxima rodada fica mais rápida.

Fontes oficiais


Avalie este artigo