Uma vulnerabilidade presente há 18 anos no NGINX, um dos servidores web de código aberto mais utilizados no mundo, foi identificada por pesquisadores da empresa DepthFirst AI e pode expor milhares de infraestruturas digitais a ataques graves. Registrada como CVE-2026-42945, com pontuação crítica de 9.2 no sistema CVSS, a falha possibilita ataques de negação de serviço (DoS) e, em cenários específicos, execução remota de código (RCE) sem necessidade de autenticação.
A brecha afeta as versões 0.6.27 até 1.30.0 do NGINX Open Source, além de produtos comerciais como o NGINX Plus e o F5 WAF para NGINX, conforme comunicado oficial publicado pela fabricante F5.
O problema ocorre quando as diretivas rewrite e set são utilizadas simultaneamente nas configurações do servidor, um padrão frequente em gateways de API e configurações de proxy reverso.
A origem do erro está no tratamento inconsistente de estado no motor de script interno do NGINX, que processa reescritas em duas etapas: uma para calcular o espaço de memória necessário e outra para copiar os dados. Uma flag interna (is_args) permanece ativa após uma reescrita com o caractere ?, fazendo com que o sistema calcule o buffer com base em dados não escapados, mas escreva dados escapados maiores, como + e &, causando o estouro de memória.
Os pesquisadores da DepthFirst AI demonstraram a execução de código não autenticada por meio de requisições HTTP especialmente criadas, capazes de corromper estruturas adjacentes no pool de memória do NGINX. No entanto, o feito foi realizado em um ambiente com a proteção ASLR (Address Space Layout Randomization) desativada, uma salvaguarda presente por padrão na maioria dos sistemas, mas que pode ser removida em ambientes de alto desempenho, como sistemas embarcados e máquinas virtuais.
Os próprios pesquisadores destacam que a arquitetura multi-processo do NGINX facilita tentativas de exploração: quando um processo worker trava após uma tentativa frustrada, o processo mestre simplesmente reinicia um novo com layout de memória idêntico. “Se nossa exploração falhar e travar um worker, o processo mestre simplesmente gera um novo com o exato mesmo layout de memória”, explicam.
A comunidade de segurança, porém, debate o nível real de risco. O pesquisador Kevin Beaumont ponderou que a exploração exige uma configuração vulnerável específica, conhecimento prévio do endpoint afetado e foi testada com ASLR desativado. A distribuição Linux AlmaLinux, após reproduzir a falha de forma independente, confirmou que derrubar processos worker do NGINX via requisição maliciosa é trivial e confiável, tornando os ataques DoS uma ameaça concreta. Já a transformação do estouro em RCE com ASLR ativo “não é trivial”, segundo os mantenedores, que ressaltaram: “não é fácil” não significa impossível.
