O NGINX lançou as versões 1.30.6 e 1.31.7 em 14 de outubro para corrigir cinco vulnerabilidades. Uma delas está presente em todas as versões desde maio de 2005.
Três falhas de memória podem interromper um processo worker e, possivelmente, permitir que um invasor execute código, segundo a F5, empresa responsável pelo NGINX. Cada falha exige uma configuração específica para ser explorada.
Uma quarta falha permite falsificar uma sessão TLS, o que poderia contornar a verificação de certificados de cliente. A F5 ressalta, porém, que a falsificação é não determinística e está fora do controle do invasor. A quinta vulnerabilidade permite que um cliente HTTP/3 inclua bytes extras em uma solicitação encaminhada pelo NGINX a um servidor backend.
Até 15 de outubro, nenhuma das cinco falhas constava no catálogo de vulnerabilidades conhecidas por serem exploradas da CISA. O NGINX e a F5 também não relataram ataques. O NGINX classificou todas as falhas como de gravidade média. A F5 atribuiu nota 9,2, considerada crítica, às três falhas de memória no CVSS v4.0. A vulnerabilidade TLS recebeu nota 8,3, e a falha no HTTP/3, 6,9.
Quais configurações estão expostas
As cinco falhas dependem de diretivas adicionadas à configuração: um `alias` combinado com `rewrite`, um mapa de expressão regular, AIO com SSI, um cache compartilhado de sessões TLS ou HTTP/3. A documentação do NGINX recomenda o uso do cache compartilhado de sessões e do armazenamento em buffer de solicitações. A outra condição necessária para explorar a falha no HTTP/3, por sua vez, vem ativada por padrão.
A vulnerabilidade TLS está relacionada à rotação automática das chaves de tíquete de sessão. Esses tíquetes permitem que um cliente retome uma sessão TLS sem realizar um handshake completo. Desde a versão 1.23.2, lançada em outubro de 2022, o NGINX gera e alterna essas chaves automaticamente quando há um cache compartilhado de sessões, a menos que as chaves sejam carregadas de um arquivo.
Cada processo worker mantém uma cópia de três espaços para chaves. Durante a rotação, apenas dois eram copiados. O terceiro espaço permanecia com o conteúdo que já estava na memória. Assim, um tíquete que apontasse para esse espaço poderia ser verificado e decifrado com dados de chave não inicializados, “permitindo uma sessão falsificada”, segundo a mensagem do commit que corrigiu o problema.
A F5 afirma que a falsificação ocorre “de maneira não determinística e fora do controle do invasor”. Ela poderia permitir que um invasor contornasse a verificação de certificados de cliente. A configuração vulnerável, `ssl_session_cache shared:SSL:10m`, é a mesma usada como exemplo na documentação do NGINX. Em fevereiro de 2025, o NGINX corrigiu uma falha na reutilização de sessões com consequência semelhante, a
CVE-2025-23419
.
As condições e medidas de mitigação abaixo foram divulgadas pelo NGINX e pela F5. Os intervalos de versões foram obtidos na página de avisos do NGINX.
| Falha | O que permite | Configuração vulnerável | Versões afetadas | Medida de mitigação caso não seja possível atualizar, segundo a F5 |
|---|---|---|---|---|
|
CVE-2026-15176
| Estouro de heap em um processo worker, que pode causar uma interrupção ou, possivelmente, permitir a execução de código | Um bloco `location` com `alias`, uma regra `rewrite` que altera o URI e qualquer elemento que leia `$request_filename`, como `return`, `set`, `if`, `add_header` ou o formato do registro de acesso | 0.1.29 a 1.31.6 | Não use `alias` nesse bloco `location` nem `$request_filename`. |
|
CVE-2026-93479
| Estouro de heap em um processo worker, que pode causar uma interrupção ou, possivelmente, permitir a execução de código | Um mapa de expressão regular cujas capturas sejam referenciadas por `root` ou `log_format` antes da variável de saída do mapa | 1.30.0 a 1.30.5 e 1.31.2 a 1.31.6 | Use capturas nomeadas e limite seu uso ao bloco que contém a correspondência com a expressão regular. |
|
CVE-2026-97205
| Uso de memória após sua liberação em um processo worker, podendo causar interrupção, corrupção de memória ou, possivelmente, execução de código | AIO ativado e uma página SSI com comandos `include virtual`, em algumas configurações | 0.8.11 a 1.31.6 | Desative AIO ou deixe de servir páginas SSI. |
|
CVE-2026-95101
| Inclusão de bytes extras em uma solicitação encaminhada por proxy ou de um corpo maior que o limite `client_max_body_size` | HTTP/3 com `proxy_request_buffering on`, opção ativada por padrão | 1.25.0 a 1.31.6 | Defina `proxy_request_buffering off`. |
|
CVE-2026-97629
| Falsificação de uma sessão TLS que poderia contornar a verificação de certificados de cliente. Segundo a F5, o resultado é não determinístico e está fora do controle do invasor | `ssl_session_cache shared:...` sem `ssl_session_ticket_key`, configuração que ativa a rotação automática de chaves | 1.23.2 a 1.31.6 | Remova a diretiva de cache compartilhado ou carregue as chaves de um arquivo com `ssl_session_ticket_key`. Servidores com `ssl_session_tickets off` não são afetados. |
Uma das falhas remonta a uma correção de julho
A falha no mapa,
CVE-2026-93479
, está no código de tratamento de strings que o NGINX corrigiu em 15 de julho para resolver a
CVE-2026-42533
. A vulnerabilidade anterior era um estouro de heap, recebeu nota 9,2 da F5 e podia ser acionada por capturas de um mapa de expressão regular.
Segundo a mensagem do commit, uma mudança feita naquela atualização de julho tornou possível o novo estouro. Uma primeira correção naquele mês impediu que dados ultrapassassem o limite de um espaço de memória, mas ainda permitia que invadissem uma área reservada. Em seguida, uma segunda atualização passou a dimensionar a string final com base no tamanho desses dados excedentes, permitindo que ela ultrapassasse o espaço disponível.
A mensagem do commit aponta limites para o problema. No caminho do diretório-raiz dos documentos, o estouro não pode ultrapassar o tamanho da área reservada. No caminho do registro de acesso, ele se limita a um único byte nulo.
O aviso da F5 e a página de avisos do NGINX indicam as versões 1.30.0 e 1.31.2 como as primeiras afetadas, ambas anteriores à mudança de julho. Portanto, um servidor que recebeu a atualização de julho também está dentro do intervalo vulnerável.
A medida de mitigação recomendada pela F5 em julho já havia sido questionada. Naquele mês, o pesquisador Stan Shaw disse ao The Hacker News que a substituição por capturas nomeadas deixava aberta uma possibilidade mais restrita de exploração e que a atualização era “a única correção completa”.
As mensagens dos commits das falhas relacionadas a `alias`, AIO e HTTP/3 descrevem os outros três problemas. A falha de `alias` ocorre entre o momento em que uma regra `rewrite` altera o URI de uma solicitação e aquele em que o NGINX escolhe o próximo bloco `location`. Se algum elemento ler `$request_filename` nesse intervalo e o prefixo do bloco `location` for maior que o URI reescrito, a conversão do URI em um caminho de arquivo pode causar um estouro de heap.
A falha de AIO envolve um contador. Cada operação assíncrona pendente em uma solicitação incrementa um campo de 8 bits, sem verificação de limite. Quando há 256 operações pendentes, o contador volta a zero, e a solicitação pode ser liberada enquanto essas operações ainda apontam para a memória que ela ocupava. O NGINX identifica como possível gatilho páginas SSI com comandos `include virtual`, que podem executar solicitações incluídas em paralelo.
A vulnerabilidade no HTTP/3 surgiu porque um campo do analisador de dados tinha duas funções: armazenar o tamanho restante de um quadro desconhecido que estava sendo ignorado e indicar quantos bytes de dados deveriam ser encaminhados como corpo da solicitação. Quando um quadro desconhecido era dividido entre duas leituras, o tamanho restante podia ser tratado como parte do corpo e enviado ao servidor backend sem passar pela verificação de `client_max_body_size`.
O que fazer
Atualize para a versão 1.30.6, no ramo estável, ou para a 1.31.7, no ramo mainline. A versão estável contém apenas correções. O NGINX publica atualizações somente para esses dois ramos. Por isso, ramos mais antigos, como o 1.28, permanecem dentro dos intervalos afetados. Um pacote distribuído por terceiros só estará corrigido se a distribuição tiver incorporado as atualizações.
Clientes do NGINX Plus e usuários do controlador de entrada, do Gateway Fabric, do Instance Manager e dos produtos de firewall para aplicações web da F5 devem consultar os avisos da empresa. Até 15 de outubro, eles listavam as compilações afetadas e, para vários produtos, ainda não indicavam uma versão corrigida.
Se não for possível atualizar imediatamente, consulte na tabela acima as medidas de mitigação indicadas pela F5. Para identificar quais recursos estão ativados no servidor, exiba a configuração em execução com `nginx -T` e procure por `alias` junto de `rewrite`, mapas de expressão regular usados por `root` ou `log_format`, AIO combinado com SSI, linhas `listen` com `quic` e `ssl_session_cache shared` sem `ssl_session_ticket_key`.
A vulnerabilidade de estouro no módulo `rewrite` corrigida pelo NGINX em maio,
CVE-2026-42945
, começou a ser explorada poucos dias após sua divulgação, segundo a VulnCheck. Esta é a oitava atualização de segurança do NGINX em 2026.
A F5 atribuiu a descoberta da falha no mapa a Matt Suiche, da Tolmo, e a Mateusz Gierblinski; a da falha no HTTP/3, a Hansol Lee, da GOTROOT; a vulnerabilidade TLS, à PhiNode Labs; e a falha de AIO, a um pesquisador identificado como Cyberlanc3r.
A própria F5 identificou a falha de `alias`. No mesmo dia, o NGINX também lançou o njs 1.0.2, que corrige duas vulnerabilidades de gravidade média no tratamento de XML do seu módulo JavaScript:
CVE-2026-101025
e
CVE-2026-101019
.
Publicidade
Vibecoding cria 10x mais sistemas, 20x mais vulneráveis. E quem ganha com isso é a galera do hacking ético e pentest. Quer ser pago para invadir sistemas? Então você tem que aprender com a Solyd que são os melhores do Brasil. Saiba mais...