Vulnerabilidade Brotli do Node.js (CVE-2026-111497): usávamos uma versão afetada, aplicamos a correção e não encontramos sinais de exploração

Hoje de manhã escrevemos que o problema de segurança do PHP não afetava o LFW.com, porque nenhum PHP roda nos nossos servidores.

Este nos afetava: nosso servidor usava uma versão afetada. O LFW.com funciona com Node.js, e o projeto Node.js publicou correções de segurança hoje às 6h38 (horário da costa leste dos EUA). Atualizamos nosso servidor às 13h24 do mesmo dia.

O que o Node.js corrigiu

A versão corrige dez vulnerabilidades nas linhas 26.x, 24.x e 22.x. Quatro têm gravidade alta. A que mais importa para nós:

• CVE-2026-111497, o decodificador Brotli. Brotli é uma forma comum de compactar o tráfego da web. Uma falha na maneira como o Node.js o descompacta pode escrever além do fim de um bloco de memória. O projeto Node.js diz que ela permite a execução remota de código: rodar o código de outra pessoa no seu servidor.

Até as 14h (horário da costa leste dos EUA) de 21 de outubro, nem o projeto Node.js nem a imprensa especializada em segurança relatam ataques reais ou um exploit público.

Atualize para 22.23.4, 24.22.1 ou 26.12.1. O Node.js diz que as versões em fim de vida são sempre afetadas e não recebem correção, então migre essas para uma versão com suporte.

Como a falha chegou até nós

Quase todo o LFW.com é feito de páginas geradas com antecedência. Mas o servidor também faz trabalhos que exigem buscar sites de outras pessoas:

• a auditoria gratuita, que carrega qualquer site que um visitante digitar;
• nosso monitoramento, que verifica sites em horários programados.

Quando o Node.js busca uma página, ele descompacta o Brotli automaticamente. Assim, um site mal-intencionado poderia responder a uma dessas requisições com dados compactados feitos para corromper a memória do nosso servidor. No pior caso, isso permite que o atacante rode os próprios comandos no nosso servidor: ler o que ele armazena, instalar uma porta dos fundos ou usá-lo para atacar outros sites. A auditoria gratuita é a parte de maior risco, porque é um estranho quem escolhe o endereço.

O que fizemos, e quando

A sequência, no horário da costa leste dos EUA:

• 6h38: o projeto Node.js publicou as versões corrigidas.
• 13h24: atualizamos o Node.js no nosso servidor para 22.23.4 e reiniciamos o site.
• Logo depois: procuramos no servidor sinais de que alguém tivesse usado a falha enquanto ela estava aberta.

Foram cerca de seis horas e quarenta e cinco minutos entre a divulgação pública e a nossa atualização. Preferíamos que tivesse sido menos.

Como verificamos que não fomos explorados

Começamos pelo que o nosso servidor realmente buscou nessas horas:

• Nenhuma auditoria gratuita foi feita. Ninguém pediu ao servidor que carregasse um site externo de sua escolha.
• Nenhuma verificação de site foi feita.
• O monitoramento verificou apenas os nossos próprios sites.

Os rastros que um ataque costuma deixar

Depois, procuramos esses rastros no servidor:

• Nenhuma falha do programa. Uma tentativa fracassada de corromper a memória costuma derrubar o programa. Os registros do servidor web da última semana não mostram travamentos, erros de memória nem reinícios forçados.
• Nada a mais rodando. A conta de serviço roda apenas o servidor web e o mecanismo de busca, sem nenhum programa estranho iniciado por eles.
• Nada novo no disco. Nenhum script ou programa novo nas pastas temporárias, e nenhuma mudança nas tarefas agendadas ou nas configurações de serviço além da nossa própria publicação.
• Nenhum novo acesso. Os logins no servidor nos últimos 30 dias vieram apenas das nossas duas chaves, e a lista de chaves autorizadas não muda desde setembro.

O próprio tráfego web

Por fim, lemos todas as requisições entre o lançamento da correção e a nossa atualização:

• Mais tranquilo do que no dia anterior, sem nenhum erro de servidor.
• Todas as requisições passaram pela Cloudflare. Nosso firewall só aceita tráfego web vindo da Cloudflare, então nada chegou diretamente ao servidor.
• Cerca de 200 sondagens de rotina, o ruído de fundo que todo site público recebe. A maioria procurava arquivos PHP num servidor sem PHP. Todas receberam como resposta “não encontrado” ou “não permitido”.

Essas verificações encontram os sinais habituais de um ataque. Elas não provam que algo não aconteceu, e não vamos afirmar que provam. Não encontramos nada.

Onde a Cloudflare ajuda, e onde não ajuda

Nosso tráfego passa por um proxy da Cloudflare, que filtra as requisições antes que cheguem ao nosso servidor. É uma proteção real para o que entra.

O caminho principal desta falha, porém, era o inverso: nosso servidor lendo respostas de outros sites. A Cloudflare não fica nesse sentido, então quem resolveu foi a atualização.

Nossas próprias estações de trabalho

Nossas estações de trabalho locais também rodam Node.js. Elas não ficam expostas à internet, então o risco era menor. Por precaução, também demos prioridade a atualizá-las para versões corrigidas.

O restante da versão

Vale conhecer as outras correções se você usa Node.js:

• Duas formas de burlar a verificação do nome do servidor nos certificados TLS (CVE-2026-105483 e CVE-2026-106069), ambas de gravidade alta. A verificação do certificado é como um programa sabe que está falando com o servidor certo.
• Uma falha de truncamento de nomes DNS (CVE-2026-105482), de gravidade alta: nomes que contêm um caractere NUL oculto são cortados.
• Valores aleatórios repetidos em snapshots (CVE-2026-106074), de gravidade média. Aplicações empacotadas como um único executável ou snapshot de inicialização podiam repetir os mesmos IDs “aleatórios” em todos os processos.
• Certificados raiz atualizados. A versão também atualiza os certificados que acompanham o Node.js, depois do comprometimento de uma autoridade certificadora intermediária da eMudhra.

A lista completa está no alerta do Node.js.

O que verificar por conta própria

Se o seu site ou as suas ferramentas rodam com Node.js:

• Atualize para 22.23.4, 24.22.1 ou 26.12.1. As suas ferramentas de build também contam.
• Comece por tudo o que busca conteúdo externo: verificadores de links, proxies de imagens, leitores de feeds, webhooks, raspadores. É isso que a falha do Brotli alcança.
• Gere de novo tudo o que foi empacotado como um único executável ou snapshot. Atualizar o Node.js no servidor não atualiza uma cópia embutida num programa.
• Usa hospedagem gerenciada? Consulte a página de status da sua hospedagem. Muitas atualizam o Node.js para você.

Se quiser uma ajuda

Teremos prazer em ajudar com qualquer parte disso, desde descobrir o que roda Node.js até verificar um servidor depois de uma atualização. Escreva para nós.