A correção do nginx saiu, o exploit chega em agosto

A 15 de julho chegou uma correção para código de 2011

A 15 de julho de 2026 o projeto nginx lançou as versões 1.30.4 e 1.31.3, e esse lançamento fechou um transbordo de memória alcançável em todas as versões até à 0.9.6. Essa versão é de 2011. A vulnerabilidade está registada como CVE-2026-42533 e pontua 9,2 na escala CVSS versão 4.0. A F5 publicou o aviso K000162097 para clientes do NGINX Plus, corrigido na 37.0.3.1.

A lista de quem reportou é invulgar. Mais de uma dezena de investigadores comunicaram o mesmo problema de forma independente, entre eles Mufeed VH da Winfunc Research, e o veterano responsável pela manutenção, Maxim Dounin, tratou da correção. Quando uma falha é encontrada por tanta gente ao mesmo tempo, o pressuposto razoável é que não era difícil de encontrar e que outros a encontraram sem apresentar qualquer relatório.

O que tem de estar na sua configuração para isto contar

O erro vive no motor de scripts, que avalia as expressões de texto que o nginx constrói no momento de cada pedido. Essa avaliação decorre em duas passagens. A primeira mede o tamanho necessário do armazenamento intermédio, usando o estado das capturas nesse instante. A segunda escreve nesse espaço com dados de captura que o pedido pode influenciar. Quando as duas passagens divergem, a escrita é maior do que o espaço reservado.

O gatilho é mais estreito do que o intervalo de versões sugere. Exige uma diretiva map baseada em expressões regulares cuja variável de saída seja referida numa expressão de texto depois de uma captura de uma correspondência anterior, as capturas numeradas escritas como dólar-um e dólar-dois. Se a sua configuração não contiver um mapa dessa forma, o número de versão por si só não o coloca no conjunto afetado. É o dado mais útil de toda esta divulgação.

Sem autenticação, mas ainda sem arma

Onde o padrão existe, o pedido que o aciona não precisa de credenciais. Basta um pedido HTTP manipulado a partir de qualquer ponto da internet. O resultado fiável é a falha e o reinício de um processo de trabalho, ou seja, uma negação de serviço à porta de entrada daquilo que o servidor publica. A execução remota de código é o caso mais difícil, possível onde a aleatorização do espaço de endereços está desativada ou pode ser contornada, e o investigador Stan Shaw sustenta que a falha fornece o seu próprio caminho para contornar essa proteção.

A 20 de julho não há código de ataque público e a CVE não consta do catálogo norte-americano de vulnerabilidades exploradas conhecidas. É o estado atual, não uma previsão. Shaw anunciou que vai publicar uma prova de conceito 21 dias depois de a correção sair, o que a coloca na primeira semana de agosto. Uma vulnerabilidade crítica não explorada mas com data publicada é um problema de planeamento diferente de uma sem data.

Três transbordos num subsistema em dois meses

A CVE-2026-42533 não é um achado isolado. É o terceiro transbordo de memória divulgado no código de avaliação de expressões do nginx em cerca de dois meses, depois da CVE-2026-42945 em maio e da CVE-2026-9256 pouco depois. Três achados num subsistema num trimestre são um padrão e não uma coincidência, e o padrão diz que o desenho de duas passagens está a ser esmiuçado por quem já sabe onde procurar.

A consequência para o planeamento é clara. Quem tratar isto como um simples salto de versão e seguir em frente tem uma probabilidade sensivelmente diferente de zero de voltar aqui dentro do trimestre. Na lista de vigilância entra o subsistema e não o número da CVE, e o que se pode reduzir de forma permanente são as formas de configuração que lá chegam.

A verificação antes de telefonar ao seu fornecedor

A maioria das divulgações críticas sobre servidores web deixa um empresário dependente de terceiros. Esta não, porque o gatilho é legível num ficheiro que pode abrir. Peça a sua versão do nginx e pergunte depois se algum bloco map da configuração usa uma expressão regular e alimenta uma variável que mais tarde é combinada num texto ao lado de capturas numeradas. Duas perguntas, uma resposta, e fica a saber se o início de agosto é um prazo ou uma nota.

Para as empresas abrangidas pela diretiva sobre segurança das redes e dos sistemas de informação na União Europeia, e para quem segue as orientações equivalentes do Reino Unido, o registo conta tanto como a correção. Anote em que versão estava, a data em que reviu a configuração e a mitigação aplicada. Uma autoridade que pergunte por uma vulnerabilidade crítica publicada em julho vai querer a data em que a avaliou, e não apenas a data em que acabou por atualizar.

Leia a seguir: Quatro agentes de código saíram sem arrombar  |  A ServiceNow corrigiu primeiro a nuvem dela, a sua casa só 103 dias depois