NGINX Rift

Prova de conceito de RCE para CVE-2026-42945, um overflow crítico de heap buffer no ngx_http_rewrite_module do NGINX introduzido em 2008. O bug permite execução remota de código não autenticada contra servidores que usam as diretivas rewrite e set.

Este fork estende o PoC original com uma cadeia de bypass de ASLR que combina o overflow do NGINX com uma primitiva comum de LFI/leitura arbitrária de arquivos no mesmo host. A primitiva de leitura de arquivos é usada para recuperar os mapas do worker do nginx, a libc e o /proc/<worker>/mem em tempo real e, em seguida, derivar remotamente o endereço de system() e alvos de heap utilizáveis.

Versões anteriores deste laboratório derrubavam intencionalmente um worker do nginx para fazer o serviço gravar um core dump e, em seguida, obtinham e analisavam esse core dump por meio da primitiva de leitura de arquivos para recuperar o estado do processo sensível a ASLR, incluindo alvos de heap. Neste repositório, coreless é apenas uma abreviação para "sem core dump de crash legível": o caminho padrão atual substitui essa dependência do core de crash por leituras ao vivo da memória via procfs, enquanto o caminho legado preservado core-guided ainda usa o core dump do worker gerado.

Esta vulnerabilidade — juntamente com outros três problemas de corrupção de memória (CVE-2026-42946, CVE-2026-40701, CVE-2026-42934) — foi descoberta autonomamente pelo sistema de análise de segurança da depthfirst após um único clique de integração do código-fonte do NGINX.

Quer encontrar problemas como este no seu próprio código? Experimente o mesmo sistema em https://depthfirst.com/open-defense.

O Bug (TL;DR)

O mecanismo de script do NGINX usa um processo em duas passagens: primeiro calcula o tamanho necessário do buffer e depois copia os dados. O flag is_args é definido no mecanismo principal quando uma substituição de rewrite contém ?, mas a passagem de cálculo de comprimento é executada em um sub-mecanismo recém-zerado. Portanto:

• Passagem de comprimento vê is_args = 0 → retorna o comprimento bruto da captura.
• Passagem de cópia vê is_args = 1 → chama ngx_escape_uri com NGX_ESCAPE_ARGS, expandindo cada byte escapável para 3 bytes.

A cópia transborda o buffer de heap subdimensionado com dados de URI controlados pelo atacante. A exploração usa heap feng shui entre requisições para corromper o ponteiro cleanup de um ngx_pool_t adjacente (pulverizado via corpos de POST, já que bytes de URI não podem conter null bytes), redirecionando-o para um ngx_pool_cleanup_s falso que invoca system() na destruição do pool.

Leia mais sobre este bug em nosso relatório técnico.

Versões Afetadas e Corrigidas

Produto	Afetadas	Corrigidas em
NGINX Open Source	0.6.27 – 1.30.0	1.31.0, 1.30.1
NGINX Plus	R32 – R36	R36 P4, R35 P2, R32 P6

Comunicado completo do fornecedor: https://my.f5.com/manage/s/article/K000160932

Fork de Pesquisa Privado: Cadeia de Laboratório Remoto com ASLR Ativado

Este fork mantém o PoC de divulgação original intacto, mas adiciona uma segunda trilha de pesquisa focada em uma questão mais realista:

O bug pode ser explorado contra uma VM Linux x86_64 real com ASLR ativado, sem depender de offsets fixos do Docker/laboratório?

A resposta neste fork de pesquisa é sim, com restrições importantes. As cadeias funcionais não desativam o ASLR e não usam os endereços fixos originais de heap/libc. Em vez disso, elas derivam o estado em tempo de execução por meio de primitivas acessíveis por HTTP na mesma porta e, em seguida, selecionam o alvo final de heap a partir dos dados de divulgação obtidos remotamente.

Agora existem duas trilhas de exploração com ASLR ativado, sendo o caminho coreless tratado como o melhor PoC atual:

• nginx_rifter.py: o ponto de entrada limpo e autossuficiente de avaliação e exploração integrada. Seu método de exploração padrão agora é a cadeia coreless /proc/<nginx-worker>/mem.
• nginx_rifter_core_v2_1.py: a versão legada preservada de nginx_rifter.py guiada por core. É útil para reproduzir o caminho de pesquisa mais antigo com core de crash testado em VM, mas não é mais o PoC preferido.
• tools/proc_mem_coreless_exploit.py: o harness de pesquisa coreless autônomo anterior. Sua lógica foi incorporada ao nginx_rifter.py; a ferramenta permanece para repetição de experimentos brutos.

A topologia do alvo é intencionalmente na mesma porta:

• rota vulnerável: /api/...
• rota PHP de leitura de arquivos locais: /lfi.php?file=...
• rota de dica phpinfo: /phpinfo.php
• conexão vítima HTTP/2: mesmo listener e worker do nginx
• verificação da prova: arquivo marcador lido de volta pelo endpoint PHP LFI

O caminho atual coreless proc-mem executa as seguintes etapas de alto nível:

1. Usa o LFI do PHP para ler a identidade do PHP, os arquivos de pid do nginx, o /proc/<pid>/maps do worker do nginx e o arquivo da libc mapeada.
2. Analisa a libc do alvo via LFI para calcular o endereço absoluto de system() para esse worker.
3. Envia o tráfego normal de spray/probe do NGINX Rift mantendo o estado do worker vivo.
4. Lê intervalos mapeados de /proc/<worker>/mem por meio da primitiva de leitura de arquivos.
5. Examina a memória viva em busca de estruturas fake-cleanup marcadas com nonce e candidatos a pool de cleanup.
6. Usa candidatos finais limitados derivados da memória viva do worker, não offsets fixos de laboratório ou cores de crash legíveis.
7. Verifica a execução de comandos lendo a saída do marcador por meio da primitiva de leitura de arquivos.

O caminho legado guiado por core faz uma derivação semelhante do endereço base e, em seguida, derruba intencionalmente um worker, lê o arquivo de core gerado via LFI e minera esse core em busca de slots fake-cleanup pulverizados. Isso foi uma ponte de pesquisa útil, mas depende de políticas de core dump e permissões de sistema de arquivos que são menos comuns em implantações padrão.

Isso não é o mesmo que o demo determinístico original em Docker. O caminho de VM x86_64 mantém o ASLR normal do Linux ativado e recalcula endereços específicos do processo a cada execução. O caminho coreless em Docker também mantém o ASLR ativado e remove o requisito incomum de core legível, mas depende do comportamento de permissões do procfs que deve ser verificado para a classe de alvo.

Escopo e Ressalvas

Este fork é um laboratório de pesquisa controlado. As cadeias com ASLR ativado dependem de condições fortes que não são premissas universais de produção:

• O PHP deve expor uma primitiva útil de leitura de arquivos locais.
• Para o caminho padrão coreless proc-mem, o PHP deve ser capaz de ler o /proc/<pid>/maps do worker do nginx com o mesmo UID, a libc mapeada e o /proc/<pid>/mem em grandes offsets mapeados.
• Para o caminho legado guiado por core, o PHP deve ser capaz de ler o /proc/<pid>/maps do worker do nginx com o mesmo UID, a libc mapeada e o core do worker gerado.
• O HTTP/2 está habilitado no mesmo listener do nginx para fornecer o alvo de cleanup do connection pool usado pela cadeia final.