NGINX: a configuração ativa deve entrar no inventário de segurança

NGINX 1.30.6 e 1.31.7 corrigem cinco vulnerabilidades que abrangem erros de memória, tratamento de HTTP/3 e verificação de certificados de cliente em sessões TLS.[4] As condições dependem da configuração, e há divergência de severidade: o projeto as classifica como médias, enquanto a F5 atribui notas mais altas a quatro delas.[4] Para operar um proxy, escolher uma dessas classificações não substitui descobrir quais recursos estão ativos.

O que muda para quem desenvolve

A CVE-2026-15176 combina alias, reescrita de URI e leitura de $request_filename; a CVE-2026-93479 envolve capturas de expressões regulares em map utilizadas por outras diretivas.[4] A CVE-2026-97205 depende de operações assíncronas e páginas SSI com inclusões virtuais.[4] Segundo a F5, os três erros de memória podem derrubar workers e possivelmente permitir execução de código.[4]

No HTTP/3, a CVE-2026-95101 pode encaminhar bytes adicionais ao backend ou ultrapassar o limite de corpo configurado em um cenário com buffering.[4] Já a CVE-2026-97629 envolve rotação automática de chaves de tickets TLS com cache compartilhado e sem chaves explicitamente carregadas, podendo afetar a verificação do certificado do cliente.[4]

Minha leitura é que o proxy precisa ser tratado como código executável da arquitetura. Diretivas que pareciam apenas escolhas de desempenho ou organização de arquivos também definem a superfície de risco. Isso exige relacionar a configuração final aos serviços e às barreiras de autenticação que ela protege.

Como aplicar

Comece por um inventário da configuração carregada, incluindo arquivos incluídos. Para cada serviço, registre uso de HTTP/3, buffering, SSI, AIO, capturas em map, alias e política de tickets TLS. Relacione cada condição ao aviso aplicável, sem presumir que toda diretiva isolada seja vulnerável.

O fornecedor recomenda atualizar e descreve contornos temporários específicos, como desativar AIO ou SSI e alterar buffering ou configuração de chaves TLS.[4] Distribuições podem aplicar backports, e NGINX Plus e controladores de ingresso têm matrizes próprias de versões e correções.[4]

Como exercício de homologação, faça a atualização em uma réplica do proxy e compare roteamento, limites de upload e autenticação por certificado antes e depois. Use certificados de teste aceitos e rejeitados e registre a decisão esperada para cada caso. O objetivo é comprovar preservação do contrato de acesso, não tentar forjar sessões.

Cuidados e limites

A F5 ressalva que a falsificação de sessão TLS é não determinística e não fica sob controle direto do atacante; instalações com tickets desativados não são afetadas por esse caminho.[4] A publicação não informava exploração conhecida.[4]

Não generalize um contorno como equivalente aos cinco patches. Também não conclua que um teste funcional aprovado comprova ausência de falhas de memória. Atualização, configuração e regressão respondem a perguntas diferentes. Uma manutenção bem feita precisa das três, com possibilidade de retorno controlado caso o comportamento do proxy mude.

Fonte

[4] Fonte: The Hacker News. Publicação: 15/10/2026 às 09:58:05.