Patch de segurança NGINX (Rift e CVEs de 2026)
Em 2026 o NGINX corrigiu vários lotes de falhas: o NGINX Rift (CVE-2026-42945) em maio, o CVE-2026-42533, com prova de conceito pública, e cinco CVEs em outubro, entre eles um request smuggling em HTTP/3 e uma falsificação de sessão TLS que contorna a verificação de certificado de cliente. Para ter todas as correções é preciso 1.31.7 ou superior (mainline) ou 1.30.6 ou superior (estável).
Você tem esta vulnerabilidade? Atualizamos o NGINX nos seus servidores e contêineres, revisamos a configuração que torna algumas destas falhas exploráveis e verificamos que tudo continua sendo servido igual.
$ nginx -vnginx version: nginx/1.30.2# Estável < 1.30.6: faltam as correções de outubro$ nginx -V 2>&1 | grep -o with-http_v3_modulewith-http_v3_module# HTTP/3 compilado: verifique o CVE-2026-95101$ grep -rnE 'request_filename|alias ' /etc/nginx//etc/nginx/sites-enabled/app.conf:14: alias /var/www/static/;# alias numa rota pública: padrão do CVE-2026-151761.31.7+ (mainline) · 1.30.6+ (stable)Três lotes de falhas no NGINX em 2026 até agora
Se você atualizou em maio por causa do Rift, faltam as correções posteriores. E se usa o NGINX da sua distribuição, o número da versão pode parecer antigo mesmo com o pacote corrigido: vale o aviso de segurança do fornecedor.
O NGINX Rift (CVE-2026-42945) foi encontrado em maio pela plataforma de IA da DepthFirst em cerca de seis horas, e a falha vinha da versão 0.6.27, de 2008. Afeta o NGINX Open Source da 0.6.27 à 1.30.0 e foi corrigido nas versões 1.31.0 e 1.30.1. O nginx.org o classifica como de severidade média; a Cloud Security Alliance e a Help Net Security o tratam como crítico (9.2). Segundo a Help Net Security, a VulnCheck viu tentativas de exploração desde 16 de maio.
Depois veio o CVE-2026-42533, corrigido nas versões 1.31.3 e 1.30.4, para o qual a DepthFirst publicou uma prova de conceito de cadeia completa. Em outubro, outro lote de cinco: CVE-2026-15176, CVE-2026-93479, CVE-2026-95101 (request smuggling em HTTP/3), CVE-2026-97629 (falsificação de sessão TLS que contorna a verificação de certificado de cliente) e CVE-2026-97205, todos corrigidos nas versões 1.31.7 e 1.30.6.
Fontes: nginx.org security advisories · Cloud Security Alliance · Help Net Security
Versões corrigidas do NGINX
Compare a sua versão com esta tabela. Vale para o NGINX Open Source baixado do nginx.org ou compilado por você; para pacotes de distribuição, consulte o aviso do fornecedor para cada CVE.
| Se você tem | Atualize para | O que falta |
|---|---|---|
| 1.31.3 – 1.31.6 | 1.31.7+ | O lote de outubro |
| 1.31.0 – 1.31.2 | 1.31.7+ | CVE-2026-42533 e o lote de outubro |
| 1.30.4 – 1.30.5 | 1.30.6+ | O lote de outubro |
| 1.30.1 – 1.30.3 | 1.30.6+ | CVE-2026-42533 e o lote de outubro |
| 0.6.27 – 1.30.0 | 1.30.6+ ou 1.31.7+ | Rift e tudo o que veio depois |
Verifique isto
-
nginx -vmostra uma versão anterior a 1.31.7 (mainline) ou 1.30.6 (estável). - Você tem HTTP/3 ativado: o request smuggling do CVE-2026-95101 se aplica.
- Você exige certificado de cliente (
ssl_verify_client): o CVE-2026-97629 permite contornar essa verificação. - A sua configuração usa
$request_filenameoualias(CVE-2026-15176), ou expressões regulares com capturas sem nome (CVE-2026-93479). - O NGINX roda dentro de imagens Docker ou como ingress do Kubernetes: cada imagem é atualizada separadamente.
Mudanças de configuração enquanto você atualiza
O nginx.org sugere ajustes de configuração para algumas falhas de outubro. Reduzem a exposição a esses CVEs específicos; para o Rift e os demais, a correção é a atualização.
- 01 CVE-2026-15176: evite
$request_filenameealiasnaslocationexpostas. - 02 CVE-2026-93479: use capturas com nome, como
(?<caminho>.+), em vez de capturas sem nome ($1,$2). - 03 Verifique em cada
serverse você usa mesmo HTTP/3 e certificados de cliente: são as funções afetadas pelos CVE-2026-95101 e CVE-2026-97629. - 04 Antes de recarregar,
nginx -t. Um erro de sintaxe em produção derruba mais serviços do que a falha que você está corrigindo.
Sete passos, nesta ordem
Aplicamos o mesmo procedimento em cada servidor: primeiro saber qual versão roda em cada lugar, depois corrigir e, no fim, verificar que ninguém entrou antes do patch.
Inventário de versões
Listamos cada NGINX: servidores, balanceadores, contêineres e ingress, com a versão, os módulos compilados (nginx -V) e a origem do pacote: nginx.org, distribuição ou imagem Docker.
Mitigação imediata
Procuramos $request_filename, alias e capturas sem nome na configuração e os trocamos onde é possível sem alterar o que o site serve.
Atualização
Subimos para 1.31.7+ ou 1.30.6+, ou para o pacote corrigido da sua distribuição, e reconstruímos as imagens que incluem o NGINX.
Verificação
Rodamos nginx -t, recarregamos e verificamos redirecionamentos, certificados, HTTP/2 e HTTP/3 e as rotas que servem arquivos estáticos.
Revisão de indícios de comprometimento
Revisamos os logs de acesso e de erro em busca de requisições anômalas, desde maio se o servidor estava numa versão afetada pelo Rift.
Rotação de segredos, se necessário
Se houver sinais de invasão, renovamos certificados e chaves privadas TLS e as credenciais que passam pelo proxy.
Acompanhamento de novos avisos
Deixamos registrada a versão e a origem de cada NGINX, para que o próximo lote de avisos do nginx.org comece desse inventário.
O que um patch só para o Rift deixa de fora
Tem vários NGINX e não sabe qual versão cada um usa?
Consultoria gratuita →Perguntas frequentes sobre os CVEs do NGINX de 2026
O que é o NGINX Rift?
Já atualizei por causa do Rift. Estou coberto?
Minha distribuição traz uma versão mais antiga. Estou afetado?
Posso me proteger mudando só a configuração?
Conte onde o seu NGINX roda
Começamos pelo inventário: versão, origem do pacote e módulos de cada NGINX, e qual configuração precisa mudar antes de atualizar.
Conte-nos seu desafio. Propomos uma solução.
Sem compromisso. Em menos de 24 horas, você recebe uma proposta com escopo, cronograma e orçamento. Sem letras miúdas.