CVE-2026-42945 - Análise e Reprodução da Vulnerabilidade NGINX Rift

Visão Geral

A CVE-2026-42945 (codinome "NGINX Rift") é uma vulnerabilidade de estouro de buffer no heap existente no ngx_http_rewrite_module do NGINX, com pontuação CVSS v4 9.2 (Crítica).

A vulnerabilidade foi descoberta pela equipe de pesquisa de segurança depthfirst em abril de 2026, permanecendo latente por 18 anos desde sua introdução no NGINX 0.6.27 em 2008.

Escopo Afetado

• NGINX Open Source 0.6.27 ~ 1.30.0
• NGINX Plus R32 ~ R36
• NGINX Instance Manager 2.16.0 ~ 2.21.1
• F5 WAF for NGINX 5.9.0 ~ 5.12.1
• NGINX App Protect WAF 4.9.0 ~ 4.16.0 e 5.1.0 ~ 5.8.0
• NGINX Gateway Fabric 1.3.0 ~ 1.6.2 e 2.0.0 ~ 2.5.1
• NGINX Ingress Controller 3.5.0 ~ 3.7.2, 4.0.0 ~ 4.0.1, 5.0.0 ~ 5.4.1

Versões Corrigidas

• NGINX 1.31.0 (publicado em 13 de maio de 2026)

Condições de Gatilho

A vulnerabilidade exige o seguinte padrão de configuração do NGINX para ser acionada:

location ~ ^/api/(.*)$ {
    rewrite ^/api/(.*)$ /internal?migrated=true;
    set $original_endpoint $1;
}

Condições principais:

1. A string de substituição da diretiva rewrite contém ? (ponto de interrogação)
2. Uma diretiva set subsequente referencia um grupo de captura de expressão regular (como $1)
3. O URI da requisição contém caracteres escapáveis (como +, &, %, etc.)

Análise da Causa Raiz

Processamento em Duas Fases do Mecanismo de Scripts

O mecanismo de scripts do NGINX usa processamento em duas fases para executar as diretivas rewrite/set:

1. Fase 1 (Cálculo de comprimento): calcula o tamanho de memória necessário para a string final
2. Fase 2 (Cópia de dados): grava os dados reais no buffer alocado

Inconsistência de Estado que Causa o Estouro

O núcleo da vulnerabilidade está na inconsistência de estado do mecanismo entre as duas fases:

Fase 1: rewrite define o sinalizador is_args

Quando a string de substituição da diretiva rewrite contém ?, a função ngx_http_script_start_args_code define:

void ngx_http_script_start_args_code(ngx_http_script_engine_t *e)
{
    e->is_args = 1;  // Definido permanentemente, nunca é redefinido!
    e->args = e->pos;
    e->ip += sizeof(uintptr_t);
}

Fase 2: O cálculo de comprimento da diretiva set usa um novo sub-mecanismo

Quando a diretiva set subsequente referencia um grupo de captura, ngx_http_script_complex_value_code cria um sub-mecanismo totalmente zerado:

void ngx_http_script_complex_value_code(ngx_http_script_engine_t *e)
{
    ngx_http_script_engine_t le;
    // ...
    ngx_memzero(&le, sizeof(ngx_http_script_engine_t)); // le.is_args = 0
    le.ip = code->lengths->elts;

Fase 3: Divergência entre o cálculo de comprimento e a cópia real

Cálculo de comprimento (usando o sub-mecanismo le, is_args=0):

// ngx_http_script_copy_capture_len_code
if ((e->is_args || e->quote) && (e->request->quoted_uri || e->request->plus_in_uri))
{
    // is_args=0, condição falsa, executa o ramo else
    return cap[n + 1] - cap[n];  // Retorna o comprimento original (sem escape)
}

Cópia real (usando o mecanismo principal e, is_args=1):

// ngx_http_script_copy_capture_code
if ((e->is_args || e->quote) && (e->request->quoted_uri || e->request->plus_in_uri))
{
    // is_args=1, condição verdadeira, executa o ramo if
    e->pos = (u_char *) ngx_escape_uri(pos, &p[cap[n]],
                                        cap[n + 1] - cap[n],
                                        NGX_ESCAPE_ARGS);
    // Cada caractere escapável é expandido de 1 byte para 3 bytes!
}

Tamanho do Estouro

• Tamanho do buffer alocado: raw_size (comprimento original da captura)
• Tamanho realmente gravado: raw_size + 2 * N (N = número de caracteres escapáveis)
• Quantidade de estouro = 2 * N bytes

Por exemplo, se o URI contém 100 sinais de +, a quantidade de estouro é de 200 bytes.

Formas de Exploração

1. DoS (Negação de Serviço)

A forma mais simples de exploração - enviar uma requisição contendo muitos caracteres escapáveis pode causar a queda do processo worker:

GET /api/+++++++++++++++++++++++++++++++++++ HTTP/1.1
Host: target.com

2. RCE (Execução Remota de Código)

Cadeia de exploração RCE completa (requer ASLR desativado ou já contornado):

1. Controle do layout do heap: controla o layout do heap de ngx_pool_t por meio da ordem das conexões
2. Estouro sobrescreve o ponteiro cleanup: estende o estouro para sobrescrever a estrutura do pool de memória adjacente
3. Spray de estrutura cleanup falsa: injeta uma estrutura falsa contendo o endereço de system() por meio do corpo de uma requisição POST
4. Gatilho de execução: fecha a conexão da vítima, acionando a travessia da lista encadeada cleanup por ngx_destroy_pool

A arquitetura multiprocesso do NGINX torna a exploração mais confiável - após a queda do worker, o master gera um novo worker com exatamente o mesmo layout de memória.

Descrição dos Arquivos

• README.md - Este arquivo, documento de análise da vulnerabilidade
• Dockerfile - Constrói o ambiente NGINX vulnerável
• nginx.conf - Configuração do NGINX que aciona a vulnerabilidade
• poc_crash.py - PoC de DoS (aciona a queda do worker)
• docker-compose.yml - Inicia o ambiente de teste com um comando

Reprodução Rápida

# 1. Construir e iniciar o NGINX vulnerável
docker-compose up -d

# 2. Executar o PoC de DoS
python3 poc_crash.py

# 3. Verificar os logs de erro do NGINX para confirmar a queda
docker-compose logs nginx

Referências

• CHANGES oficial do NGINX - Aviso de correção
• Relatório de pesquisa da depthfirst - Análise técnica do descobridor original da vulnerabilidade
• Aviso de segurança F5 K000160932 - Aviso de segurança oficial

Aviso Legal

Este material é destinado exclusivamente a fins de pesquisa em segurança e educação. Não utilize estas informações para ataques não autorizados.