No dia 13 de maio, foi corrigida uma vulnerabilidade no popular servidor web nginx, utilizado em sistemas de alta carga: CVE-2026-42945, que poderia levar a RCE. A vulnerabilidade apareceu há 18 anos (em 2008) na versão 0.6.27.
Para sua exploração, uma combinação específica de diretivas deve estar definida na configuração do servidor, não necessariamente presente em todos, mas às vezes encontrável, como por exemplo:
rewrite ^(.*) /new?c=1;
set $myvar $1;
return 200 $myvar;
Detalhes importantes:
- primeiro vem a diretiva rewrite, onde (o primeiro argumento) uma expressão regular com um parâmetro destacado (algo entre parênteses) é substituído pelo (segundo argumento) um caminho que contém uma interrogação;
- a diretiva set (outra rewrite ou if também funcionariam), que utiliza o parâmetro destacado do caminho reescrito (neste caso, $1).
A vulnerabilidade atua assim:
- a primeira diretiva rewrite, ao encontrar o sinal de interrogação, estabelece uma flag interna is_args, significando "agora estamos coletando parâmetros GET para a URL reescrita, tudo deve ser escapado", e (este é o cerne do bug) esquece de resetar essa flag ao final de sua execução;
- a diretiva set subsequente, ao formar um valor para $myvar, erroneamente aplica o is_args previamente estabelecido, e grava em my_var o valor escapado do parâmetro destacado $1; o problema é que o buffer para $myvar é alocado antes, ainda antes das substituições serem feitas, e seu comprimento é calculado com is_args=0, ou seja, o valor escapado resulta ser mais longo que o buffer alocado, causando a gravação fora do buffer alocado em outras estruturas de dados do servidor. Para que isso ocorra, é suficiente enviar uma solicitação com caracteres que devem ser escapados, como sinais de "mais", no local do destaque do parâmetro da expressão regular.
Se não houver ALSR no host, essa vulnerabilidade pode ser explorada para execução remota de código com os direitos do processo de trabalho do nginx, existe PoC (não é um exploit em si, mas uma demonstração em sandbox).
A vulnerabilidade foi corrigida na versão estável do nginx 1.30.1 e na nova versão de desenvolvimento 1.31.0. link para o commit.
É notável que 14 anos atrás (em 2012), um erro semelhante já havia sido corrigido em outro lugar próximo.
——-
No site da F5, há uma recomendação para neutralizar temporariamente a vulnerabilidade caso não seja possível atualizar rapidamente a versão do nginx — é necessário substituir os parâmetros não nomeados por parâmetros nomeados, e, nesse caso, segundo eles, a vulnerabilidade não se manifestará. Exemplo de lá:
era: rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;
agora: rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;
As informações sobre a vulnerabilidade foram fornecidas por Zhenpeng (Leo) Lin da DepthFirst. Além disso, ele também relatou os seguintes problemas, que também foram corrigidos:
- CVE-2026-40701 (o commit) uso após a liberação ao utilizar ssl_verify_client+ssl_ocsp (aparentemente sem RCE)
- CVE-2026-42934 (o commit) leitura fora do buffer no parser utf-8 em circunstâncias específicas, que pode levar a um pequeno vazamento de dados ou a uma queda do processo de trabalho
- CVE-2026-42946 (o commit) alocação excessiva de memória e leitura fora do buffer ao usar os módulos scgi/uwsgi, o problema se manifesta na presença de um backend malicioso (upstream) através dos protocolos especificados, ou durante um ataque mitm do canal de comunicação com o backend, podendo levar à leitura de memória do nginx ou a queda do processo de trabalho
Fonte: linux.org.ru
