Falha crítica no NGINX permite derrubar servidores e pode evoluir para execução remota de código
A F5 corrigiu uma vulnerabilidade grave no NGINX que possibilita a atacantes remotos, sem qualquer autenticação, provocar um estouro de buffer na área de heap por meio de requisições HTTP especialmente construídas. De acordo com o cenário e com as proteções ativas no sistema operacional, o bug pode resultar desde a simples queda do serviço até, em situações mais críticas, a execução remota de código no servidor.
Catalogada como CVE-2026-42533, a falha foi corrigida em 15 de julho nas versões NGINX 1.30.4 (ramo estável) e 1.31.3 (ramo mainline. Para clientes da edição comercial, o patch foi incorporado ao NGINX Plus R37 P3 (37.0.3.1). Versões anteriores permanecem expostas se não forem atualizadas.
O problema é descrito oficialmente como um buffer overflow relacionado ao uso da diretiva map em conjunto com expressões regulares. Todas as compilações do NGINX entre as versões 0.9.6 e 1.31.2 são consideradas vulneráveis. Apenas as releases 1.30.4, 1.31.3 e posteriores – já com o ajuste aplicado – estão fora de risco.
Na métrica de severidade, a F5 atribuiu pontuação 9,2 no CVSS v4 e 8,1 no CVSS v3.1, refletindo o impacto potencial elevado. Ao mesmo tempo, a complexidade do ataque é classificada como alta, pois a exploração depende de uma combinação específica de diretivas na configuração e de como as capturas de expressões regulares são referenciadas.
É importante destacar que a CVE-2026-42533 não torna automaticamente vulneráveis todos os servidores que rodem versões afetadas do NGINX. A exposição real está diretamente ligada ao modo como o serviço foi configurado, em especial ao uso de map com regex e variáveis capturadas numericamente.
O bug se manifesta quando uma variável criada por uma diretiva map baseada em expressão regular é utilizada, posteriormente, dentro de uma expressão de texto que também faz referência a capturas numeradas anteriores, como $1 ou $2, resultantes de outra regex. Essa combinação específica altera o modo como o NGINX calcula e preenche as strings em memória.
A diretiva map serve para definir o valor de uma variável a partir de informações processadas pelo servidor, como trechos da URL, cabeçalhos HTTP ou dados enviados pelo cliente. É um recurso poderoso para criar lógicas de roteamento, seleção de backends ou aplicação de regras dinâmicas. Quando se adicionam expressões regulares, o administrador consegue identificar padrões complexos e extrair partes específicas da requisição para uso em outras diretivas.
Em configurações suscetíveis, o mecanismo interno responsável por montar as strings funciona em duas etapas: primeiro, estima o tamanho necessário para o resultado, depois grava o conteúdo em um buffer na heap. Em teoria, as duas fases deveriam se basear exatamente nas mesmas capturas da expressão regular, garantindo que a memória alocada fosse suficiente.
O erro, porém, está justamente na forma como essas capturas são compartilhadas. A avaliação da expressão regular que aparece na diretiva map modifica o estado interno das capturas numeradas usadas entre as duas etapas. Assim, a primeira passagem pode reservar memória tomando como referência uma captura menor, enquanto, na segunda, é escrita uma captura distinta – e potencialmente muito maior – controlada pelo atacante na requisição HTTP.
Quando o conteúdo gravado ultrapassa o tamanho originalmente calculado, ocorre o heap buffer overflow. Como tanto o tamanho quanto o conteúdo excedente podem ser manipulados por dados vindos do cliente, um invasor remoto é capaz de acionar o bug sem qualquer credencial, usando apenas requisições HTTP específicas.
O efeito mais imediato da exploração é o encerramento inesperado de um worker process do NGINX, o processo responsável por aceitar conexões e processar as requisições. Em muitos cenários, o processo mestre (master process) detecta a falha e reinicia automaticamente o worker afetado, o que mascara parcialmente o problema à primeira vista.
Entretanto, um volume contínuo de requisições maliciosas pode forçar reinicializações sucessivas dos workers, causar aumento de consumo de CPU e memória e, na prática, levar à indisponibilidade de sites, APIs e aplicações hospedados naquele servidor. Em ambientes com pouco excesso de capacidade, alto tráfego ou arquitetura de alta disponibilidade mal dimensionada, a interrupção intermitente dos workers tende a afetar a continuidade dos serviços digitais.
Além da indisponibilidade, a F5 alerta para um cenário ainda mais perigoso: a possibilidade de execução remota de código. Esse risco se materializa principalmente quando o mecanismo de Address Space Layout Randomization (ASLR) está desativado no sistema ou pode ser contornado. O ASLR é uma camada de proteção que aleatoriza os endereços de memória usados por um processo, dificultando que um atacante preveja onde injetar e executar código.
Se um adversário conseguir descobrir os endereços críticos e controlar de forma precisa a corrupção de memória gerada pelo overflow, o impacto deixa de ser apenas uma negação de serviço e passa a incluir a execução de comandos no servidor com os privilégios do processo NGINX – normalmente o usuário do serviço web, que muitas vezes tem acesso a arquivos sensíveis, sockets de backend e outros recursos internos.
O pesquisador Stan Shaw, que atua sob o pseudônimo cyberstan e foi um dos responsáveis pela descoberta independente da falha, publicou uma análise ainda mais preocupante do que a descrição inicial apresentada pela F5. De acordo com ele, a mesma inconsistência entre as capturas usadas nas duas etapas do processamento das strings pode levar o NGINX a devolver conteúdo não inicializado da heap quando a nova captura é menor do que aquela usada para calcular o tamanho do buffer.
Nesse caso, em vez de sobrescrever memória, o servidor acaba expondo trechos de memória que não foram limpos, o que pode conter endereços, dados de outras requisições ou informações internas do processo. Esse comportamento abre espaço para vazamentos de endereços de memória e pode fornecer pistas suficientes para contornar o ASLR, transformando um simples estouro em um componente de uma cadeia de exploração mais sofisticada.
Shaw afirma ter conseguido reproduzir esse cenário em uma instalação padrão do Ubuntu 24.04, utilizando apenas uma requisição GET não autenticada, o que reforça o caráter crítico da falha mesmo em ambientes considerados “default”. Na visão do pesquisador, a vulnerabilidade não deve ser tratada somente como um vetor de negação de serviço, mas como uma base sólida para ataques que busquem execução de código ou extração de informações sensíveis da memória.
Diante dessa combinação de impactos possíveis – negação de serviço, vazamento de memória e potencial RCE – a orientação central para administradores é clara: aplicar as atualizações de segurança o mais rápido possível. Em ambientes de produção, a atualização do NGINX deve ser planejada, mas não adiada indefinidamente. Manter versões 1.30.3 ou 1.31.2 e anteriores em operação aumenta exponencialmente o risco, especialmente em servidores expostos à internet.
Enquanto a atualização definitiva não é possível, algumas medidas de mitigação podem reduzir a exposição. A principal é revisar cuidadosamente a configuração e desativar, refatorar ou substituir blocos que utilizem diretiva map em conjunto com expressões regulares e capturas numeradas ($1, $2 etc.) usadas em variáveis de texto posteriores. Em muitos casos, é possível reescrever essas regras usando mapas estáticos, variáveis pré-processadas ou lógica em camada de aplicação.
Outra recomendação prática é validar se o ASLR está devidamente habilitado e configurado no sistema operacional. Em distribuições modernas de Linux, a função costuma vir ativada por padrão, mas pode ter sido alterada por políticas internas, ajustes de desempenho ou compatibilidade de softwares legados. Garantir a presença dessa proteção não elimina o bug, mas aumenta a dificuldade de exploração para fins de execução de código.
É igualmente importante acionar processos de gestão de configuração: documentar quais servidores usam NGINX, quais versões estão em produção, em homologação ou desenvolvimento, e quais arquivos de configuração aplicam diretivas map com regex. Ambientes em nuvem, com múltiplas instâncias e escalonamento automático, podem dificultar essa visibilidade, tornando essencial o uso de inventários e automação de configuração para aplicar patches de forma consistente.
Organizações que dependem de NGINX como balanceador de carga ou gateway de APIs devem considerar que um ataque bem-sucedido pode não apenas afetar a camada de front-end, mas também abrir portas para movimentação lateral dentro da infraestrutura, sobretudo se o processo do NGINX tiver acesso amplo a redes internas. Revisar o princípio do menor privilégio para o usuário do serviço e segmentar a rede reduz o impacto de um eventual comprometimento.
Do ponto de vista de desenvolvimento seguro, o incidente é mais um alerta sobre o uso indiscriminado de expressões regulares complexas dentro de servidores web e proxies reversos. Embora flexíveis, regex com capturas numeradas em estruturas como map podem introduzir interações inesperadas com outras partes do sistema. Sempre que possível, deve-se optar por padrões mais simples, validações na aplicação ou mecanismos de roteamento claros, evitando dependência excessiva de lógica complexa na camada de configuração.
Equipes de segurança também podem incluir a CVE-2026-42533 em rotinas de varredura de vulnerabilidades internas, identificando rapidamente hosts expostos. A partir daí, é recomendável acompanhar os logs do NGINX em busca de sinais de exploração: picos de erros de worker, mensagens de falha de segmentação, códigos 502/504 em grande volume ou padrões estranhos em parâmetros de URL e cabeçalhos.
Por fim, a falha destaca um ponto recorrente na segurança de infraestrutura: componentes consolidados e largamente adotados, como o NGINX, não são imunes a erros sutis com consequências graves. A confiança na maturidade da ferramenta não substitui a necessidade de atualização constante, revisão de configuração e monitoramento. Manter o servidor em versão suportada, com patches recentes e configuração revisada, é hoje uma exigência básica para qualquer operação digital que dependa de alta disponibilidade e proteção de dados.