Uma vulnerabilidade antiga escondida no fluxo de rewrite do NGINX
A CVE-2026-42945, apelidada de NGINX Rift, trouxe atenção para uma superfície extremamente sensível dentro do ecossistema NGINX: o ngx_http_rewrite_module. A vulnerabilidade é um heap buffer overflow presente há anos no mecanismo responsável pelo processamento de regras rewrite, if e set.
O problema afeta ambientes amplamente expostos à internet, incluindo NGINX Open Source, NGINX Plus, Ingress Controllers Kubernetes, appliances de segurança e diversos produtos embarcados que utilizam NGINX como reverse proxy.
Na prática, basta uma única requisição HTTP cuidadosamente construída para provocar corrupção de heap dentro do worker process do NGINX.
O que realmente acontece durante a exploração
O gatilho da vulnerabilidade depende de uma combinação específica de regras rewrite usando capturas PCRE não nomeadas, como $1 e $2, associadas a strings de substituição contendo o caractere ?.
O fluxo vulnerável ocorre em duas etapas internas do motor de scripting do NGINX:
- Length pass: cálculo do tamanho necessário para o buffer de destino
- Copy pass: escrita efetiva da string processada no heap
O problema surge porque ambas as etapas interpretam o escaping de maneira inconsistente.
Durante o cálculo inicial, o mecanismo subestima a quantidade real de bytes necessários após expansão de escapes relacionados ao parsing de argumentos HTTP. O resultado é uma alocação menor do que a escrita efetiva exige.
Na etapa de cópia, os dados controlados pelo atacante passam por expansão adicional, ultrapassando os limites do heap previamente alocado.
Isso produz corrupção determinística de memória dentro do worker process.
Por que isso é relevante operacionalmente
O NGINX normalmente ocupa posições estratégicas dentro da infraestrutura:
- Reverse proxy principal
- Load balancer
- API gateway
- Ingress Controller Kubernetes
- Camada TLS exposta à internet
- Proxy interno entre microserviços
Quando uma vulnerabilidade desse tipo aparece no pipeline HTTP antes mesmo da aplicação processar a requisição, o risco operacional aumenta significativamente.
Em ambientes Kubernetes, por exemplo, o comprometimento de um Ingress Controller pode permitir movimentação lateral entre namespaces, exposição de serviços internos e acesso privilegiado a workloads sensíveis.
Em appliances corporativos, o cenário costuma ser ainda pior. Muitos vendors embarcam versões customizadas do NGINX com ciclos lentos de atualização e superfícies adicionais habilitadas.
RCE não significa exploração universal
A exploração pública mostrou cenários de execução remota de código em ambientes vulneráveis, principalmente quando proteções como ASLR e heap hardening estavam reduzidas ou desabilitadas.
Isso não significa que qualquer servidor NGINX possa ser comprometido automaticamente via RCE confiável.
Na prática ofensiva, confiabilidade depende de fatores como:
- Allocator utilizado
- Versão da glibc
- Flags de compilação
- ASLR
- Layout do heap
- Módulos carregados
- Regras rewrite existentes
Mesmo assim, crashes repetitivos de workers já são suficientes para gerar indisponibilidade operacional relevante em ambientes expostos.
O detalhe que transforma uma regra rewrite em superfície de ataque
Muitas equipes tratam regras rewrite como simples lógica de roteamento HTTP.
Esse caso mostra exatamente o contrário.
Quando expressões PCRE controladas externamente passam a interagir com mecanismos internos de escaping, pequenas diferenças de parsing podem se transformar em corrupção de memória nativa.
Em ambientes auditados pela Antisec, é relativamente comum encontrar:
- Regex complexas sem validação defensiva
- Capturas reutilizadas em múltiplos rewrites
- Regras herdadas sem revisão
- Ingress Controllers replicando configurações inseguras entre clusters
- Appliances executando builds antigas sem inventory adequado
Esse tipo de combinação normalmente passa despercebido até que uma vulnerabilidade como essa apareça.
Indicadores técnicos observáveis
Equipes defensivas devem monitorar:
- Segfaults recorrentes em workers NGINX
- Core dumps inesperados
- Picos anormais de HTTP 500
- Requisições contendo padrões específicos de rewrite e caracteres escapados
- Spawn incomum de processos iniciados pelo usuário do NGINX
- Crash loops em Ingress Controllers Kubernetes
Em ambientes Linux, logs de kernel e dumps de memória do worker podem preservar evidências importantes sobre o overflow.
Mitigação imediata
A correção definitiva exige aplicação dos patches oficiais disponibilizados para:
- NGINX Open Source
- NGINX Plus
- NGINX Ingress Controller
- Produtos derivados que embarcam NGINX
Enquanto a atualização não ocorre, algumas medidas reduzem exposição:
- Revisar regras rewrite usando capturas PCRE não nomeadas
- Desabilitar regras desnecessárias
- Aplicar filtros temporários em WAF
- Isolar serviços críticos
- Reduzir privilégios do worker process
- Inventariar appliances e proxies embarcados
O maior problema operacional normalmente não é aplicar patch no NGINX principal. É descobrir quantas dependências ocultas utilizam NGINX internamente.
O que esse caso mostra na prática
A CVE-2026-42945 reforça um padrão recorrente observado em avaliações ofensivas modernas: componentes considerados estáveis há mais de uma década continuam acumulando lógica complexa capaz de introduzir corrupção de memória em caminhos críticos.
O risco raramente está apenas no software principal.
Ele aparece nas integrações, regras herdadas, pipelines HTTP antigos e configurações que nunca passaram por revisão de segurança profunda.
É exatamente nesse ponto que exercícios de Red Team, Pentest avançado e revisão de arquitetura defensiva deixam de ser apenas compliance e passam a ser mecanismos reais de redução de risco operacional.
A Antisec realiza avaliações ofensivas focadas em infraestrutura exposta, reverse proxies, Kubernetes, aplicações críticas e cadeias modernas de exploração envolvendo HTTP parsing, gateways e componentes nativos de infraestrutura.
