NGINX CVE-2026-42945 sob exploração ativa: heap buffer overflow afeta dezenas de milhões de servidores

Uma falha crítica recém-divulgada no NGINX, identificada como CVE-2026-42945 (CVSS 9.2), está sob exploração ativa em todo o mundo. O bug é um heap buffer overflow no módulo ngx_http_rewrite_module, afeta as versões 0.6.27 a 1.30.0 do NGINX Plus e NGINX Open, e foi introduzido no código-fonte em 2008 — permanecendo invisível por quase duas décadas. A VulnCheck já detectou tentativas de exploração contra suas redes de honeypot e a F5 liberou correções urgentes.

O que aconteceu

Poucos dias após a divulgação pública da vulnerabilidade, pesquisadores da VulnCheck registraram tentativas de exploração ativa em honeypots distribuídos. A falha está no módulo de reescrita de URLs do NGINX, um componente amplamente utilizado por proxies reversos, balanceadores de carga e gateways de aplicação em todo o ecossistema corporativo. A AI-native security company depthfirst confirmou que a regressão foi introduzida ainda em 2008, ilustrando como bugs em código maduro continuam sendo um vetor de risco crítico mesmo em projetos com décadas de revisão.

O NGINX é a base de uma fatia expressiva da infraestrutura web global: estima-se que rode em mais de um terço dos sites públicos do planeta, somando dezenas de milhões de instâncias entre servidores hospedados, edge proxies e appliances embarcados. Esse alcance massivo transforma qualquer CVE crítico no servidor em um problema sistêmico, com janela de exploração curta e superfície de ataque potencialmente global.

A natureza exata das atividades observadas pela VulnCheck e os objetivos finais dos atacantes ainda não foram divulgados. A recomendação imediata é aplicar os patches publicados pela F5 — fabricante mantenedora do NGINX Plus — e revisar configurações expostas a partir da internet pública.

Detalhes técnicos da vulnerabilidade

A CVE-2026-42945 é um heap buffer overflow disparado por requisições HTTP especialmente formatadas processadas pelo ngx_http_rewrite_module. Quando explorada com sucesso, a falha pode derrubar processos worker do NGINX — caracterizando um ataque de negação de serviço (DoS) — ou, em cenários mais críticos, permitir execução remota de código sem autenticação prévia.

O caminho para RCE, entretanto, não é trivial. Depende da existência de configurações específicas do NGINX que utilizem diretivas vulneráveis do módulo de reescrita, do conhecimento dessa configuração por parte do atacante e da ausência de ASLR (Address Space Layout Randomization) — proteção padrão habilitada em distribuições Linux modernas. Quando essas três condições se alinham, o impacto é máximo: comprometimento integral do servidor sem credenciais.

“A falha depende de uma configuração específica do NGINX para ser explorável e de o atacante conhecer ou descobrir essa configuração. Para chegar a RCE, o ASLR também precisa estar desabilitado.”

Kevin Beaumont, pesquisador de segurança

Os mantenedores do AlmaLinux reforçaram o alerta: transformar o overflow em execução confiável não é trivial na configuração padrão, mas a falha de DoS por crash do processo worker já é suficiente para classificar a CVE como urgente. Em ambientes onde o NGINX está exposto diretamente à internet, um simples crash recorrente é capaz de paralisar serviços críticos.

Quem é afetado

• Instalações de NGINX Plus e NGINX Open Source nas versões 0.6.27 até 1.30.0
• Proxies reversos, balanceadores de carga e gateways de API que utilizem o módulo ngx_http_rewrite_module com diretivas vulneráveis
• Appliances de fornecedores que embarquem NGINX em versões afetadas (firewalls de aplicação, soluções de CDN privada, edge gateways)
• Ambientes com ASLR desabilitado — tipicamente sistemas legados ou containers configurados de forma agressiva por performance
• Operadores de serviços expostos publicamente que façam uso intensivo de regras de rewrite condicional

Análise

A janela entre divulgação e exploração ativa continua se estreitando. No caso da CVE-2026-42945, bastaram poucos dias para que atacantes começassem a varrer a internet em busca de instâncias vulneráveis — um padrão que se repete com consistência preocupante desde casos recentes envolvendo Citrix NetScaler, Fortinet, Cisco ASA e Ivanti. A diferença é que NGINX não é appliance proprietário: roda em commodity hardware, em containers, em VPS modestos, em raspberry pis de laboratório. Isso multiplica a superfície de ataque por ordens de magnitude e dificulta a aplicação coordenada de patches.

Outro ponto que merece atenção é a longevidade do bug. Um overflow vivendo 18 anos no código produtivo do NGINX é um lembrete incômodo de que auditorias estáticas, fuzzing massivo e ferramentas modernas de SAST continuam encontrando classes inteiras de problemas que escaparam de revisões humanas por décadas. A própria depthfirst, que se descreve como AI-native, sugere que parte dessa descoberta veio de análise assistida por IA — uma tendência que deve acelerar a divulgação de CVEs históricos em projetos amplamente auditados.

O detalhe técnico de que a exploração para RCE depende de configuração específica e ASLR desabilitado oferece uma falsa sensação de segurança. Atacantes oportunistas que automatizem scans com base em fingerprints de versão não precisam de RCE para gerar dano: derrubar workers em loop já é um vetor de impacto operacional severo, especialmente contra alvos que dependem de SLA estrito ou que rodam NGINX como ponto único de entrada.

Recomendações práticas

• Aplique imediatamente as atualizações publicadas pela F5 para NGINX Plus e migre instalações open source para a versão corrigida
• Audite todas as configurações que utilizem o módulo ngx_http_rewrite_module, com atenção a diretivas dinâmicas baseadas em entrada do usuário
• Confirme que o ASLR está habilitado no sistema operacional host (em Linux, verifique /proc/sys/kernel/randomize_va_space igual a 2)
• Implemente WAFs ou regras de mod_security à frente do NGINX para inspecionar requisições HTTP anômalas com payloads incomuns no path ou nos headers
• Monitore logs do NGINX em busca de crashes recorrentes de worker — um indicador potencial de tentativa de exploração
• Inventarie appliances de terceiros que embarquem NGINX e acione os fornecedores para confirmar a entrega de patches
• Considere segmentar o tráfego de gestão e remover a exposição administrativa direta à internet sempre que possível

Fonte: The Hacker News