Alerta CVE-2026-42945 no NGINX: o excesso de memória que pode causar DoS e execução remota de código

Um erro crítico de memória no NGINX, identificado como CVE-2026-42945, volta a colocar em evidência que até mesmo projetos de software em massa implantados podem arrastar defeitos históricos com impacto atual. A vulnerabilidade é um excesso de búfer no módulo ngx_http_rewrite_module que permanece no código há quase 18 anos e, segundo a classificação CVSS, recebeu uma pontuação alta (9.2) por seu potencial para provocar recusa de serviço e, em condições concretas, execução remota de código.

A pesquisa que tirou à luz esta falha foi publicada por DepthFirst AI, que durante uma sessão automatizada de análise de código encontrou ainda três problemas de corrupção de memória adicionais. O vetor central de CVE-2026-42945 é uma inconsistência no motor interno de scripts do NGINX: uma primeira última calcula a memória necessária usando comprimentos de URI sem escape, e uma segunda última escreve a versão escapada (mais longa), provocando um heap buffer overflow Quando convivem diretrizes ‘rewrite’ e ‘set’ em configurações típicas de gateways de API e proxies inversos.

DepthFirst demonstrou um cenário de exploração que, em ambientes com ASLR desativado, permite corromper estruturas da memória do pool de NGINX, sobrepor ponteiros de manejadores de limpeza e forçar a execução de system () durante o processo de limpeza — isto é, uma via para execução remota de comandos. No entanto, a comunidade matizou esse achado: pesquisadores como Kevin Beaumont e equipamentos de distribuição como AlmaLinux têm apontado que converter esse transbordamento em um exploit confiável contra sistemas com proteções modernas habilitadas não é trivial. Ainda assim, todos concordam que o componente de recusa de serviço é fácil de reproduzir e deve ser tratado como urgente.

A magnitude do risco não é menor se tivermos em conta que NGINX potência cerca de um terço dos sítios principais e é usado extensivamente em provedores de nuvem, plataformas SaaS, bancos, e-commerce e clusters Kubernetes. A arquitetura multi-processo de NGINX também facilita a exploração: os processos worker herdam projetos de memória quase idênticos desde o processo mestre, o que permite tentativas repetidas de manipulação do heap mesmo quando um worker é bloqueado e substituído.

F5, responsável pela manutenção do projeto, publicou um aviso com as versões afetadas e adesivos. As correções estão disponíveis no NGINX Open Source 1.31.0 e 1.30.1, bem como em adesivos específicos para NGINX Plus e outras distribuições do ecossistema. Para detalhes oficiais consulte o aviso de F5 e a descrição do NVD: F5 Security Advisory e NVD · CVE-2026-42945. O relatório técnico do DepthFirst com a pesquisa será publicado como referência detalhada na sua página: DepthFirst · NGINX Rift.

Além de CVE-2026-42945, as digitalizaçãos detectaram outras falhas no mesmo período: uma alocação excessiva de memória em módulos SCGI/UWSGI que pode provocar workers ocupando ~1 TB (CVE-2026-42946), um use-after-free em resolução OCSP assimncrona (CVE-2026-40701) e um erro off-by-one em parseo UTF-8 (CVE-2026-42934). Embora estas últimas tenham recebido classificações médias ou altas, juntas reforçam a ideia de que é necessário auditar exaustivamente implantações em produção.

Se você administra ambientes que usam NGINX, as ações prioritárias que eu recomendo são claras: atualiza as versões alteradas O mais rapidamente possível após os testes pré-produção; se você não puder corrigir imediatamente, aplica mitigações temporárias propostas pelo fornecedor, como substituir grupos de captura PCRE não nomeados ($1, $2, etc.) em regras ‘rewrite’ por capturas nomeadas, o que elimina a principal condição de exploração assinalada. Rever as regras de rewrite e set, limitar a superfície exposta de endpoints que aceitam cadeias de consulta complexas e endurecer as políticas de limites de tamanho e tempo para pedidos HTTP reduz a probabilidade de exploração.

Complementariamente, verifica que as protecções do sistema estão ativas: ASLR deve permanecer habilitado e os contentores ou imagens de VM não devem desativar mitigações por razões de desempenho em produção. Reforça o isolamento de processos, executa o NGINX com privilégios mínimos, mantenha registros e alertas centrados em falhas de workers e reinícios frequentes, e aplica detecção de anomalias em tráfego HTTP que possa tentar explorar. Para ambientes Kubernetes, você rapidamente atualiza os drivers de Rendimento e as imagens de base usadas nos pods.

Por último, considera que a evidência disponível mostra uma ameaça dupla: um vetor de DoS reproduzível e um vetor RCE que requer condições específicas. Não subestime o impacto operacional dos bloqueios repetidos de workers ou a possibilidade de um atacante especializado poder adaptar técnicas para sortear mitigações em certos ambientes. Planeja o adesivo em janelas controladas, submete as mudanças a testes de carga e segurança, e mantenha comunicação com seus fornecedores e equipamentos de resposta a incidentes para acelerar a contenção se detectar atividade suspeita relacionada a essas vulnerabilidades.