Falha de estouro de heap no módulo de reescrita do NGINX permite execução remota de código

A vulnerabilidade CVE-2026-42945 afeta configurações específicas do ngx_http_rewrite_module e pode ser acionada por requisições HTTP sem autenticação, com risco de reinicialização de processos worker e execução de código quando o ASLR está desativado.

Componente	ngx_http_rewrite_module no NGINX Plus e no NGINX Open Source, além de falhas separadas em ngx_http_scgi_module, ngx_http_uwsgi_module, ngx_http_ssl_module e ngx_http_charset_module.
Vetor	Requisições HTTP especialmente construídas contra servidores com diretivas rewrite vulneráveis; a condição crítica envolve captura PCRE sem nome, como $1 ou $2, e uma string de substituição contendo ?.
Impacto	CVE-2026-42945 pode corromper heap no processo worker do NGINX, causar reinicialização do worker, degradar disponibilidade e permitir execução remota de código em sistemas com ASLR desativado.
Prioridade	Atualizar para versões corrigidas e revisar imediatamente regras rewrite que combinam capturas sem nome com substituições contendo ?.
Versões	NGINX Open Source 1.0.0 a 1.30.0 é listado como afetado; as correções foram introduzidas em 1.30.1 e 1.31.0.
Artefatos	CVE-2026-42945, CVE-2026-42946, CVE-2026-40701, CVE-2026-42934, ngx_http_rewrite_module, rewrite, if, set, $1, $2, scgi_pass, uwsgi_pass, ssl_verify_client, ssl_ocsp, charset, source_charset, charset_map e proxy_pass.
Mitigação	Quando a atualização imediata não for possível para CVE-2026-42945, substituir capturas PCRE sem nome por capturas nomeadas nas diretivas rewrite afetadas.

Resumo técnico

O conjunto de correções para NGINX Plus e NGINX Open Source inclui uma falha crítica no ngx_http_rewrite_module, registrada como CVE-2026-42945 e também identificada pelo codinome NGINX Rift. O problema é um estouro de buffer em heap dentro do processo worker do NGINX e depende de uma combinação específica de configuração: uma diretiva rewrite seguida por rewrite, if ou set, uso de captura PCRE sem nome, como $1 ou $2, e uma string de substituição que contém o caractere ?. Quando essas condições existem, uma requisição HTTP criada para atingir a rota vulnerável pode levar o worker a escrever além da área alocada em memória.

A gravidade operacional vem de três propriedades: o caminho pode ser alcançado pela rede, não exige autenticação e atua dentro de um processo worker que normalmente processa tráfego de múltiplas aplicações ou virtual hosts. A consequência confirmada inclui reinicialização do worker e negação de serviço. A execução remota de código é tratada como possível em sistemas nos quais o ASLR está desativado, porque a previsibilidade do layout de memória aumenta a viabilidade de transformar corrupção de heap em controle de fluxo. Em ambientes com ASLR ativo, o risco primário continua sendo estabilidade e disponibilidade, com potencial de ciclos de falha se o endpoint vulnerável permanecer exposto.

Além da falha crítica no módulo de reescrita, o mesmo ciclo de correções cobre outras três vulnerabilidades. CVE-2026-42946 envolve alocação excessiva de memória em ngx_http_scgi_module e ngx_http_uwsgi_module quando scgi_pass ou uwsgi_pass está configurado e um adversário em posição intermediária consegue controlar respostas de um upstream. CVE-2026-40701 é um use-after-free em ngx_http_ssl_module condicionado a ssl_verify_client configurado como on ou optional e ssl_ocsp como on. CVE-2026-42934 é uma leitura fora dos limites em ngx_http_charset_module quando diretivas de conversão de charset e proxy_pass com buffering desativado aparecem em conjunto.

Fluxo técnico

Em CVE-2026-42945, o ponto crítico está na forma como o NGINX processa regras de reescrita que usam grupos de captura PCRE sem nome. Em uma configuração vulnerável, a expressão regular extrai partes da URI e a substituição usa referências posicionais, como $1 ou $2. A presença de ? na string de substituição muda a interpretação do resultado porque separa caminho e argumentos de consulta. Esse processamento cria uma situação em que o tamanho ou o posicionamento do dado derivado da URI do atacante não é tratado corretamente antes da escrita em heap. O resultado é corrupção de memória no worker responsável pela requisição.

O atacante não precisa de sessão existente, credenciais ou acesso prévio ao sistema. A pré-condição real é alcançar uma rota servida por NGINX que use a sequência de diretivas afetada. Como a entrada controlada é a URI, a exploração começa no tráfego HTTP comum. A corrupção não é meramente aleatória: os bytes que extrapolam a alocação são influenciados pela URI enviada. Isso torna o defeito mais sério do que uma falha que apenas encerra processo de forma não controlada, porque amplia as possibilidades de modelar o estado de heap, ainda que a execução de código dependa de mitigadores e do layout de memória do sistema.

Na prática, o primeiro impacto observável tende a ser reinicialização de workers. O master process do NGINX pode criar novos workers, mas requisições repetidas contra a mesma rota vulnerável podem manter o serviço em degradação. Em servidores que concentram múltiplos sites, APIs ou aplicações atrás da mesma instância, a falha de um worker pode impactar fluxos que não têm relação direta com a regra vulnerável, dependendo da distribuição de conexões e da configuração de processos. Em arquiteturas com proxy reverso, balanceamento local, TLS termination e aplicações internas, a falha fica na borda de entrada e deve ser tratada como exposição de infraestrutura, não como problema isolado da aplicação de backend.

CVE-2026-42946 segue um fluxo diferente. O risco aparece quando módulos SCGI ou uWSGI encaminham requisições para upstreams e um adversário com capacidade de interceptar ou manipular respostas controla o conteúdo retornado pelo servidor upstream. A condição de adversário em posição intermediária reduz o conjunto de cenários, mas não elimina risco em redes internas planas, ambientes com upstream sem proteção adequada, proxies intermediários comprometidos ou tráfego não autenticado entre camadas. A consequência indicada é leitura de memória do worker ou reinicialização do processo. Para CVE-2026-40701, a condição relevante é a validação de certificado de cliente combinada com OCSP. Para CVE-2026-42934, a superfície depende de conversão de charset e proxy com buffering desligado, condição comum em alguns fluxos de streaming ou respostas grandes.

Superfície afetada

A superfície mais urgente é formada por servidores NGINX expostos à internet ou a redes não confiáveis que executam NGINX Open Source entre 1.0.0 e 1.30.0, ou NGINX Plus em versões ainda não atualizadas, com regras rewrite que usam capturas sem nome e substituição contendo ?. O simples uso do módulo de reescrita não basta para caracterizar exposição à falha crítica; a configuração precisa reunir a cadeia de diretivas e os padrões de substituição descritos. Por isso, inventários baseados apenas na versão do pacote devem ser complementados por análise de configuração.

Ambientes com múltiplos arquivos incluídos por include, templates gerados por automação e configurações de ingress controller exigem atenção adicional. A regra vulnerável pode estar em um arquivo de site, em um bloco server, em um bloco location ou em configuração produzida por ferramenta de deployment. Em pipelines que montam imagens de container com NGINX, a versão corrigida precisa estar no artefato final, não apenas no repositório base. Em hosts com pacotes de sistema, a validação deve confirmar o binário em execução e o reload efetivo do serviço após atualização.

As demais vulnerabilidades ampliam a revisão para módulos e diretivas menos universais, mas relevantes em ambientes corporativos. scgi_pass e uwsgi_pass são usados para integração com aplicações que falam SCGI ou uWSGI; ssl_verify_client com ssl_ocsp aparece em cenários de autenticação mTLS; charset, source_charset e charset_map surgem em conversão de codificação; proxy_pass com buffering desligado costuma ser adotado para reduzir latência, transmitir fluxos ou evitar armazenamento temporário de respostas. Cada condição precisa ser verificada de forma declarativa nos arquivos de configuração e, quando possível, confirmada por telemetria de tráfego.

A exposição deve ser priorizada por criticidade do ponto de entrada. Um NGINX na borda pública, com regras complexas de reescrita e alto volume de tráfego, tem prioridade maior do que uma instância interna isolada. Ainda assim, instâncias internas não devem ser descartadas quando fazem roteamento entre zonas, aceitam tráfego de usuários autenticados, processam webhooks ou recebem requisições de parceiros. A ausência de autenticação na falha principal significa que qualquer controle de acesso implementado apenas no backend pode não ser suficiente se a corrupção ocorrer antes do encaminhamento.

• NGINX Open Source 1.0.0 a 1.30.0 deve ser tratado como vulnerável até confirmação de atualização para 1.30.1, 1.31.0 ou pacote corrigido equivalente.
• Regras rewrite com referências posicionais $1, $2 e substituição contendo ? devem ser revisadas em todos os arquivos carregados pela configuração efetiva.
• Instâncias com scgi_pass, uwsgi_pass, ssl_verify_client, ssl_ocsp, charset, source_charset, charset_map ou proxy_pass com buffering off exigem triagem adicional para as demais CVEs.

Hunting e telemetria

A investigação deve começar pela configuração efetiva, não apenas por logs de erro. Operadores devem coletar a saída de validação de configuração, mapear arquivos incluídos e procurar diretivas rewrite que combinem capturas PCRE sem nome com substituições contendo ?. Expressões regulares em configurações geradas por automação devem ser avaliadas no artefato final implantado. O objetivo é localizar a condição de exploração antes de procurar sinais de abuso, porque uma rota vulnerável pode permanecer silenciosa até receber a URI adequada.

Nos logs, o sinal mais direto é instabilidade de workers correlacionada a requisições HTTP específicas. Mensagens de encerramento anormal, reinicialização frequente de workers, falhas de segmentação, aumento de erros 502, 499 ou 500, e quedas de conexões podem indicar exploração ou teste de exploit. A correlação temporal precisa considerar o access log no mesmo intervalo do erro do worker. URIs incomuns, comprimentos atípicos, padrões repetidos contra a mesma rota e variações pequenas de payload podem indicar tentativa de modelar heap ou manter o serviço indisponível.

Em endpoint e sistema operacional, a telemetria deve observar reinícios do processo worker, core dumps, eventos de proteção de memória, encerramentos por sinal e alterações inesperadas no comportamento do binário nginx. Em ambientes Linux, eventos do supervisor, systemd, logs do kernel e alertas de EDR podem ajudar a distinguir falha acidental de sequência repetida induzida por tráfego. Se houver ASLR desativado em qualquer host, o risco sobe e a investigação deve procurar execução anômala sob o usuário do worker, conexões de saída inesperadas e processos filhos incomuns iniciados pelo contexto do NGINX.

Para CVE-2026-42946, o hunting precisa incluir confiança entre NGINX e upstreams SCGI/uWSGI. Respostas anômalas de upstream, tamanhos inesperados de cabeçalhos ou corpo, falhas de worker logo após respostas de backend e alterações de rota entre proxy e aplicação são sinais relevantes. Para CVE-2026-40701, a atenção recai sobre handshakes TLS com certificado de cliente, validação OCSP e reinicializações associadas a fluxos mTLS. Para CVE-2026-42934, logs de proxy com buffering desligado e conversão de charset devem ser correlacionados com reinicializações ou vazamento suspeito de conteúdo de memória.

• Procurar rewrite com $1, $2 ou outras capturas posicionais e substituições que incluam ? nos arquivos carregados pelo NGINX.
• Correlacionar reinicializações de workers, falhas de segmentação e erros de gateway com URIs repetidas ou incomuns no access log.
• Verificar se ASLR está ativo nos hosts que executam NGINX e elevar prioridade de resposta em qualquer sistema com mitigação desativada.
• Revisar tráfego e respostas de upstream quando scgi_pass ou uwsgi_pass estiver configurado, especialmente em segmentos onde um adversário poderia manipular respostas.
• Inspecionar fluxos mTLS com ssl_verify_client e ssl_ocsp, além de rotas com conversão de charset e proxy_pass com buffering desativado.

Mitigação

A resposta deve priorizar atualização do NGINX em todos os pontos de entrada expostos. Para NGINX Open Source, as correções foram introduzidas em 1.30.1 e 1.31.0; em distribuições que empacotam backports, a versão exibida pelo pacote pode não refletir diretamente a versão upstream, então a validação precisa confirmar o changelog do fornecedor e o binário em execução. Depois da instalação, o serviço deve ser recarregado ou reiniciado conforme a política operacional, e a equipe deve confirmar que workers antigos não permanecem ativos com o binário vulnerável.

Quando a atualização imediata não for possível para CVE-2026-42945, a mitigação de configuração é substituir capturas PCRE sem nome por capturas nomeadas nas diretivas rewrite afetadas. Essa mudança precisa ser feita com cuidado porque regras de reescrita podem alterar roteamento, parâmetros de consulta e compatibilidade de aplicações. O procedimento defensivo deve incluir revisão do padrão, alteração em ambiente controlado, execução de nginx -t, testes de rotas críticas e implantação com monitoramento de erros. A mitigação não deve ser tratada como substituto permanente da correção, porque outras falhas do mesmo ciclo dependem de módulos e condições diferentes.

A contenção de uma suspeita de exploração deve combinar redução de superfície e preservação de evidências. Em uma instância com crash loop, vale remover temporariamente a rota vulnerável, aplicar bloqueio de tráfego no balanceador ou WAF e capturar logs antes de rotação. Se execução de código for uma possibilidade real, especialmente em host sem ASLR, a resposta deve incluir isolamento do servidor, coleta de processos, conexões de rede, arquivos modificados, unidades de serviço, cron jobs e artefatos no diretório de trabalho do usuário do worker. Credenciais acessíveis ao processo, como certificados, chaves de upstream, tokens de ambiente e arquivos de configuração com segredos, devem entrar no plano de rotação quando houver indício de comprometimento.

Para as demais CVEs, a mitigação depende da presença das diretivas condicionais. Ambientes com scgi_pass ou uwsgi_pass devem proteger o caminho até upstreams, evitar tráfego manipulável entre camadas e aplicar a atualização. Configurações com ssl_verify_client e ssl_ocsp devem ser testadas após atualização para garantir que a validação de cliente continue funcionando. Rotas com charset, source_charset, charset_map e proxy_pass com buffering desligado devem ser revisadas para confirmar necessidade operacional e reduzir combinações de diretivas que ampliem risco de leitura fora dos limites. Após a correção, a validação deve incluir teste funcional, monitoramento de workers e revisão de alertas de endpoint e rede no período anterior à atualização.

• Atualizar NGINX Open Source para 1.30.1, 1.31.0 ou pacote corrigido do fornecedor; aplicar correções equivalentes no NGINX Plus.
• Executar revisão de configuração para eliminar capturas PCRE sem nome em diretivas rewrite afetadas quando a atualização ainda não puder ser aplicada.
• Rodar nginx -t, recarregar o serviço e confirmar que os workers ativos foram substituídos por processos usando o binário corrigido.
• Ativar e verificar ASLR nos hosts que executam NGINX, porque a ausência dessa mitigação aumenta o risco associado à corrupção de heap.
• Preservar logs de access, error, sistema operacional e EDR em qualquer caso com crash de worker, loop de reinicialização ou comportamento anômalo após requisições HTTP.