O NGINX lançou as versões 1.30.6 e 1.31.7 em 14 de outubro para corrigir cinco vulnerabilidades, sendo que uma delas está presente em todas as versões desde maio de 2005.
São três falhas de memória que a F5, empresa por trás do NGINX, afirma poderem derrubar um processo worker ou, possivelmente, permitir que um invasor execute código. Cada uma exige uma configuração específica para ser explorada.
Uma quarta falha permite que um invasor forje uma sessão de Segurança da Camada de Transporte (TLS) que poderia burlar verificações de certificado de cliente, embora a F5 classifique a forjagem como não determinística e fora do controle do invasor. A quinta permite que um cliente HTTP/3 (versão do protocolo de transferência de hipertexto) insira bytes extras em uma requisição que o NGINX repassa a um servidor de backend.
Nenhuma das cinco estava no catálogo de Vulnerabilidades Exploradas Conhecidas (Known Exploited Vulnerabilities, KEV) da CISA (Agência de Segurança Cibernética e de Infraestrutura dos EUA) em 15 de outubro, e nem o NGINX nem a F5 relatam ataques. O NGINX classifica as cinco como de gravidade média. A F5 atribui às três falhas de memória nota 9,2, crítica, no Sistema de Pontuação de Vulnerabilidades Comuns (CVSS) v4.0; à falha de TLS, nota 8,3; e à falha de HTTP/3, nota 6,9.
Quais configurações estão expostas
Cada uma das cinco exige uma diretiva que você adicionou: um alias com rewrite, um mapa com expressão regular, AIO (entrada e saída assíncrona) com SSI (inclusão do lado do servidor), um cache de sessão TLS compartilhado ou HTTP/3. A documentação do próprio NGINX recomenda o cache de sessão compartilhado e o buffer de requisições; a outra condição para a falha de HTTP/3 já vem ativada por padrão.
A falha de TLS está na rotação automática das chaves de tickets de sessão. Os tickets permitem que um cliente retome uma sessão de TLS sem um handshake completo e, desde a versão 1.23.2, de outubro de 2022, um cache de sessão compartilhado faz com que o NGINX gere e rotacione ele mesmo as chaves dos tickets, a menos que você carregue as chaves de um arquivo.
Cada processo worker mantém uma cópia de três slots de chave. A rotação copiava apenas dois, então o terceiro slot mantinha o que já estivesse na memória antes. Um ticket que referenciasse esse slot podia ser verificado e descriptografado com esse material de chave não inicializado, « permitindo uma sessão forjada », segundo diz o commit de correção.
A F5 afirma que a forjagem funciona « de maneira não determinística, fora do controle do invasor », e que um invasor poderia usá-la para contornar a verificação de certificados de cliente. A configuração exposta, ssl_session_cache shared:SSL:10m, é a que a documentação do NGINX usa em seu exemplo de configuração. Em fevereiro de 2025, o NGINX já havia corrigido uma falha de reutilização de sessão com a mesma consequência, a CVE-2025-23419 (sigla de Vulnerabilidades e Exposições Comuns, sistema de identificação de falhas).
As condições e as soluções alternativas a seguir são do NGINX e da F5. Os intervalos de versões vêm da página de avisos de segurança do NGINX.
Uma falha remonta à correção de julho
A falha de mapa, CVE-2026-93479, está no código de manipulação de strings que o NGINX corrigiu em 15 de julho para a CVE-2026-42533, um estouro de heap (área de memória dinâmica) classificado pela F5 com nota 9,2 e acionado por meio das capturas de um mapa com expressão regular.
O novo estouro tornou-se possível após uma mudança naquela versão de julho, segundo o commit de correção. Uma correção de julho adicionou proteção contra a extrapolação de um buffer, mas os dados ainda podiam transbordar para uma área reservada, e uma segunda correção de julho dimensionou a string final com base nesse tamanho transbordado, de modo que a string podia ultrapassar seu buffer.
O commit impõe limites. O estouro fica restrito ao tamanho da área reservada no caminho do document root e a um único byte nulo no caminho do log de acesso.
O aviso da F5 e a página de avisos do NGINX listam as versões 1.30.0 e 1.31.2 como as mais antigas afetadas, anteriores à mudança de julho. Um servidor corrigido em julho continua dentro do intervalo afetado de qualquer forma.
A solução alternativa da F5 para a falha de julho já havia sido questionada. O pesquisador Stan Shaw disse ao The Hacker News, em julho, que trocar para capturas nomeadas deixava aberto um caminho mais estreito e que atualizar era « a única correção completa ».
As correções das falhas de alias, AIO e HTTP/3 descrevem os outros três bugs. A falha de alias se abre no instante após uma reescrita alterar o URI (identificador de recurso) de uma requisição e antes de o NGINX escolher o próximo location. Se algo ler $request_filename nessa janela, e o prefixo do location for mais longo que o URI reescrito, o mapeamento do URI para um caminho de arquivo estoura um buffer.
A falha de AIO é um contador. Cada operação assíncrona pendente em uma requisição soma um a um campo de 8 bits sem nenhuma verificação, então 256 operações pendentes fazem o contador voltar a zero, e a requisição pode ser liberada enquanto essas operações ainda apontam para sua memória. O NGINX cita como gatilho páginas SSI nomeadas com comandos de inclusão virtual, que podem executar suas requisições incluídas em paralelo.
A falha de HTTP/3 veio de um campo do analisador que fazia duas funções: guardar o tamanho restante de um quadro desconhecido que estava sendo ignorado e o número de bytes de quadros DATA a serem repassados como corpo da requisição. Quando um quadro desconhecido era dividido em duas leituras, a contagem restante era tratada como corpo e enviada ao backend, fora da verificação de client_max_body_size.
O que fazer
Atualize para a 1.30.6 do ramo estável ou para a 1.31.7 da linha mainline. A versão estável contém apenas correções. O NGINX publica correções apenas para esses dois ramos, então versões mais antigas, como a 1.28, permanecem dentro dos intervalos afetados, e um pacote de distribuição só está corrigido se sua distribuição tiver aplicado as correções por backport.
Clientes do NGINX Plus e usuários dos produtos Ingress Controller, Gateway Fabric, Instance Manager e WAF (firewall de aplicação web) da F5 devem consultar os avisos da empresa, que listam as versões afetadas e, para vários produtos, nenhuma versão corrigida até 15 de outubro.
Se ainda não puder atualizar, consulte as soluções alternativas da F5 para cada falha.
Para verificar quais caminhos estão ativados no seu servidor, imprima a configuração em execução com o comando nginx -T e procure por alias ao lado de rewrite, um mapa de expressão regular usado por root ou log_format, aio junto com ssi, linhas listen com QUIC (protocolo de transporte usado pelo HTTP/3) e ssl_session_cache shared sem ssl_session_ticket_key.
A falha de estouro no módulo rewrite, corrigida pelo NGINX em maio com o número CVE-2026-42945, estava sendo explorada poucos dias após a divulgação, segundo a VulnCheck. Esta é a oitava versão de segurança do NGINX em 2026.
A F5 credita Matt Suiche, da Tolmo, e Mateusz Gierblinski pela falha de mapa; Hansol Lee, da GOTROOT, pela falha de HTTP/3; a PhiNode Labs pela falha de TLS; e um pesquisador identificado como Cyberlanc3r pela falha de AIO.
A própria F5 encontrou a falha de alias. No mesmo dia, o NGINX também lançou o njs 1.0.2, que corrige duas falhas de gravidade média no tratamento de XML (linguagem de marcação extensível) em seu módulo JavaScript, identificadas como CVE-2026-101025 e CVE-2026-101019.
