Zero-Day & Exploits
Os invasores estão explorando a vulnerabilidade crítica do NGINX
Uma vulnerabilidade crítica do NGINX (CVE-2026-42945) divulgada na semana passada está sendo explorada por invasores, revelou o pesquisador de segurança do VulnCheck, Patrick Garrity, no sábado.
A vulnerabilidade, chamada NGINX Rift, pode ser explorada de forma confiável para acionar uma condição de negação de serviço e pode potencialmente permitir a execução remota de código não autenticado, tudo isso possível enviando uma solicitação HTTP especialmente criada para uma instância NGINX vulnerável.
O que é o NGINX?
O NGINX é o servidor web mais amplamente implantado e, como tal, é uma das peças fundamentais da infraestrutura web moderna. Ele também pode desempenhar outras funções: balanceador de carga, proxy reverso e cache HTTP.
Seu desenvolvimento é supervisionado pela empresa de rede e entrega de aplicativos F5, que mantém e lança a versão de código aberto (NGINX Open Source), oferece a versão comercial NGINX Plus e integrou o NGINX em suas diversas soluções de entrega de aplicativos e segurança.
Sobre CVE-2026-42945
CVE-2026-42945 é uma vulnerabilidade de corrupção de memória que afeta NGINX Open Source (versões 0.6.27 a 1.30.0) e NGINX Plus (vR32 a R36). Ele também afeta alguns dos produtos F5’s que incorporam o software, como o NGINX Ingress Controller, o F5 WAF para NGINX e outros.
“Um bug no ngx_http_rewrite_module permite que um invasor remoto e não autenticado corrompa o heap de um processo de trabalho NGINX enviando URI criado. O gatilho é um padrão de configuração comum: a reescrever diretiva com captura regex sem nome ($ 1, $ 2) e uma sequência de substituição que contém um ponto de interrogação, seguido de outro reescrever, se, ou definir diretiva,” os pesquisadores que descobriram a vulnerabilidade explicado.
“Quando esse padrão está presente, o NGINX calcula o buffer de destino usando um conjunto de suposições de escape e depois grava nele usando outro. A gravação passa pelo buffer alocado, produzindo corrupção determinística da memória. Os bytes gravados após a alocação são derivados do URI do invasor, portanto a corrupção é moldada pelo invasor e não aleatória. Solicitações repetidas também podem ser usadas para manter os trabalhadores em um loop de falha e degradar a disponibilidade para cada site atendido pela instância.”
PoC e exploração
O CVE-2026-42945, juntamente com outros quatro problemas de segurança, foi descoberto por pesquisadores da Depthfirst com a ajuda da plataforma de detecção de vulnerabilidades nativa de IA da empresa. Dos cinco, o CVE-2026-42945 foi o mais crítico.
Depois que o F5 lançou as correções e o aviso de segurança, os pesquisadores do Depthfirst publicaram detalhes técnicos e um exploração de prova de conceito (PoC).
De acordo com Garrity, os sistemas canários do VulnCheck começaram a sinalizar tentativas de exploração em 16 de maio, três dias após a vulnerabilidade e o PoC terem sido tornados públicos.
A eficácia destas tentativas depende do sistema visado.
Embora o DoS possa ser alcançado em configurações padrão do NGINX, tanto o VulnCheck quanto o pesquisador de segurança Kevin Beaumont destacou que os invasores podem obter execução de código se conseguirem desabilitar a randomização do layout do espaço de endereço (ASLR) no servidor de destino.
“Outra ressalva é que o servidor de destino precisa executar uma configuração de reescrita específica para ficar vulnerável, portanto, nem toda instância do NGINX é explorável. Nossa consulta Censys mostra cerca de 5,7 milhões de servidores NGINX expostos à Internet executando uma versão potencialmente vulnerável, embora a população verdadeiramente explorável provavelmente seja um subconjunto muito menor deles”, a equipe de acesso inicial do VulnCheck observado.
Correções
Até agora, o F5 corrigiu a vulnerabilidade em:
NGINX Open Source – versões 1.31.0 e 1.30.1
NGINX Plus – versões R36 P4 e R32 P6
F5 WAF para NGINX v5.13.0
F5 DoS para NGINX v4.9.0
Também forneceu uma mitigação: usar capturas nomeadas em vez de capturas sem nome em reescrever definições.
AlmaLinux, Ubuntu e Debian Os desenvolvedores começaram a lançar pacotes nginx corrigidos.
- POC:
- Como a falha funciona (O Bug)
- O NGINX processa diretivas de reescrita de URL (como rewrite e set) em duas etapas ("passagens"):
Passagem de Cálculo: O sistema calcula quantos bytes o novo endereço de URL vai precisar para criar um espaço de memória (buffer) sob medida.
Passagem de Cópia: O sistema realmente copia as informações para dentro do buffer alocado.
O erro acontece na comunicação entre o motor principal do NGINX e o submotor que lida com essas regras:
O Desalinhamento: Se a URL de substituição contém uma interrogação (?), o motor principal marca uma flag chamada is_args = 1. No entanto, na hora de calcular o tamanho do buffer, o submotor é iniciado do zero e não enxerga essa flag (is_args = 0). Ele calcula o tamanho da URL de forma "crua", sem prever nenhuma expansão.
O Estouro: Na hora de copiar os dados, o NGINX percebe a flag is_args = 1 e decide codificar a URL usando a função ngx_escape_uri. Essa função transforma caracteres especiais em sequências de escape (como transformar um espaço em %20). Isso faz com que cada caractere escapado passe de 1 byte para 3 bytes.
O Resultado: Como o buffer foi reservado com o tamanho menor (calculado na primeira passagem) e os dados inseridos ficaram muito maiores (devido à expansão na segunda passagem), os dados "transbordam" a memória reservada, invadindo o espaço de outras estruturas do programa.
A Estratégia de Exploração (Como vira RCE)
A descrição da PoC menciona duas técnicas avançadas de exploração de binários:
Heap Feng Shui: O atacante envia várias requisições web específicas (geralmente com corpos POST grandes) para organizar a memória do servidor (o heap) de uma forma muito precisa. O objetivo é garantir que, quando o buffer estourar, ele morda exatamente uma estrutura crítica do NGINX chamada ngx_pool_t (que gerencia a memória daquela conexão).
Sequestro de Fluxo (Control Flow Hijack): Ao estourar o buffer, o atacante substitui um ponteiro de função legítimo (chamado cleanup) por um ponteiro que aponta para a função system() do Linux, passando como argumento o comando que ele deseja executar. Quando a requisição termina e o NGINX tenta "limpar" a memória daquela conexão, em vez de executar a rotina de limpeza padrão, ele executa o comando do atacante (como abrir um terminal/shell).
Análise do Contexto da PoC
Severidade: Crítica. Permite que um atacante totalmente anônimo (não autenticado) ganhe controle do servidor de forma remota se o NGINX utilizar as diretivas afetadas (rewrite ou set).
Idade do Bug: O texto menciona que o erro foi introduzido em 2008, o que significa que o código vulnerável persistiu por quase 18 anos antes de ser descoberto por essa ferramenta de análise estática/IA da empresa Depth First.
Ambiente de Teste: O script final (python3 poc.py --shell) automatiza todo o processo descrito acima: ele organiza a memória do alvo via rede, engatilha o estouro de buffer através de uma requisição maliciosa com caracteres que vão expandir, e abre um terminal interativo (shell) diretamente no servidor vulnerável.
Mitigação imediata: Atualizar o NGINX para as versões corrigidas indicadas na tabela do aviso (1.31.0, 1.30.1 ou os patches do NGINX Plus).
