A correção de um servidor não garante que todas as aplicações instaladas nele tenham recebido a mesma proteção. Esse é um cuidado importante no tratamento da CVE-2026-111497, falha no descompressor Brotli presente em diferentes produtos e dependências de software.
Em orientação publicada em 30 de outubro, a Microsoft reforçou a necessidade de atualizar também componentes instalados ou empacotados pelo próprio cliente. Para o provedor brasileiro, a ação prática é pedir à TI ou ao fornecedor dos sistemas uma conferência por aplicação, incluindo integrações e contêineres, em vez de encerrar a tarefa com a informação de que o sistema operacional foi atualizado.
O alerta não comprova que um sistema específico do ISP está vulnerável ou foi invadido. A exposição depende da versão e de como o programa processa os dados.
O que precisa estar exposto
Segundo o projeto Node.js, a falha permite que uma entrada Brotli malformada provoque escrita fora de um buffer interno. Quando uma aplicação descomprime dados controlados por um atacante, o problema pode causar interrupção do processo, exposição de memória ou execução de código. O boletim de 21 de outubro identifica as linhas 22, 24 e 26 do Node.js.
O NCSC da Nova Zelândia informou, em alerta de 29 de outubro, ter conhecimento de exploração ativa dessa vulnerabilidade. É um sinal para priorizar a avaliação técnica, não uma evidência de comprometimento dos provedores brasileiros.
No .NET, a Microsoft faz uma distinção importante: ASP.NET Core e HttpClient não descomprimem Brotli automaticamente nas configurações padrão. A exposição aparece quando a aplicação habilita esse processamento ou usa diretamente as APIs de descompressão com dados controlados por terceiros. O .NET Framework não é afetado por essa falha, conforme o boletim específico.
Onde conferir as correções
O boletim de 25 de outubro do .NET informa correções nos runtimes 8.0.33, 9.0.22 e 10.0.14. Esses números são referências da correção anunciada, não uma recomendação para deixar de consultar versões posteriores e o canal de suporte utilizado.
No Node.js, as versões de segurança de 21 de outubro incluíram 22.23.4, 24.22.1 e 26.12.1. O projeto Node.js publicou 24.22.2 em 28 de outubro. Portanto, uma lista antiga de versões corrigidas não deve substituir a orientação atual do fornecedor.
Para pacotes de distribuições Linux, consulte o boletim da distribuição e a versão completa do pacote. A Red Hat documenta que componentes Node.js podem usar Brotli do sistema ou uma cópia embarcada. É necessário identificar qual delas a aplicação utiliza antes de concluir que a atualização resolveu sua exposição.
O pacote instalado não é a aplicação corrigida
Aplicações .NET que dependem do runtime compartilhado precisam receber o runtime atualizado e ser reiniciadas. Já as aplicações que levam seu próprio runtime, chamadas self-contained, precisam ser reconstruídas e implantadas novamente. Instalar uma versão nova apenas no host não substitui a cópia que acompanha a aplicação. Aplicações NativeAOT também precisam ser recompiladas e republicadas com o SDK e as referências afetadas corrigidas, seguindo o advisory da Microsoft.
O mesmo cuidado vale para imagens de contêiner: a imagem corrigida precisa chegar à implantação. No AWS Lambda, a atualização do boletim de 4 de novembro informa correção dos runtimes Node.js 22, 24 e 26 usados por pacotes ZIP, nas versões 22.23.4, 24.22.2 e 26.13.0; imagens-base de contêiner atualizadas exigem reconstrução e nova implantação.
Para conferir a função, a AWS indica a versão do runtime na linha INIT_START dos logs de uma inicialização do ambiente. Compare a evidência da função com os valores mínimos do boletim, sem tomar o anúncio como prova de correção individual. Bibliotecas Brotli incluídas pela própria função ou por camadas exigem conferência separada.
Um roteiro para o responsável pelo sistema
Como organização do trabalho no ISP, registre para cada aplicação: responsável, fornecedor, versão em execução, origem do runtime, uso de contêiner e boletim aplicável. Peça que a equipe documente se há descompressão de Brotli de origem não confiável e qual atualização ou mitigação foi adotada.
Depois da mudança, valide os fluxos de negócio atendidos pelo sistema, como atendimento, pedidos e integrações, e guarde a evidência da versão implantada. Essa verificação operacional não substitui investigação de segurança quando houver sinais suspeitos.
Se a correção não puder ser aplicada imediatamente, avalie somente as mitigações compatíveis com a aplicação e descritas por seu fornecedor. Não habilite uma nova configuração de descompressão apenas para reproduzir um exemplo de mitigação. A Microsoft alerta expressamente para esse risco em seu advisory de .NET.
O ponto de controle é simples: a tarefa termina quando a correção alcança o componente usado pelo serviço, não quando apenas um instalador termina sem erro.
