TL;DR: Ao enfrentar o terceiro estouro de buffer detectado em 2026 (e, segundo a F5, RCE se ASLR não estiver ativado) ao trabalhar com regex e variáveis, o desenvolvedor do freenginx, Maksim Dunin, decidiu que era hora de parar e adicionou uma verificação do tamanho da variável antes de gravar nela. Essa novidade foi incorporada também no nginx, o que traz esperança para a cessação de novas CVEs sobre esse assunto.
Agora, os detalhes.
No dia 19 de junho, foi feito o commit no freenginx, adicionando ao descritor da variável um campo end, indicando o final do buffer. Anteriormente, havia apenas um ponteiro para o início (pos), e o comprimento necessário era calculado (e ainda é) previamente, e no momento da cópia dos dados na variável, presumiam-se que o comprimento calculado corretamente garantiria que os dados caberiam no buffer. Infelizmente, já duas vezes em maio de 2026, devido a diversas falhas de atenção, isso não se confirmou (1 (linux.org.ru), 2 (linux.org.ru)), o que levou a estouros de buffer e consequências negativas. Assim, agora, ao criar o buffer da variável, também é preenchido o ponteiro para seu final, e antes de escrever dados na variável, se os dados não couberem nela, o processamento da solicitação será encerrado de forma controlada com um erro. Ou seja, os erros de cálculo de comprimento ainda podem ocorrer, mas agora eles não vão corromper a memória, apenas falharão em uma solicitação HTTP específica. Os próximos commits (2 (freenginx.org), 3 (freenginx.org)) adicionaram proteção semelhante em outros locais do código, incluindo o código de registro de acesso. Em 7 de julho, foi publicada a versão freenginx 1.31.3, que inclui essa correção.
Em 15 de julho, esses commits foram incorporados ao nginx (1 (github.com), 2 (github.com), 3 (github.com), por algum motivo trocando o segundo e o terceiro na cadeia), foi atribuído o problema CVE-2026-42533, e a F5 lançou um SA (f5.com).
Sobre a vulnerabilidade específica desta vez: ela se manifesta ao usar a diretiva map com expressões regulares que possuem parâmetros extraídos. Em relação às outras condições necessárias para sua ativação, o texto na descrição do commit e o texto no SA diferem um pouco: no SA, menciona-se que deve haver um cálculo de uma determinada string, que utiliza o parâmetro extraído remanescente do map, antes que o resultado desse mesmo map. Na descrição do commit, no exemplo, entre essas etapas ocorre também a reinicialização de uma variável que contém o parâmetro extraído. De qualquer forma, na maioria das instâncias do nginx em execução, tal situação provavelmente não será encontrada, e a vulnerabilidade, portanto, afetou poucas pessoas. Também vale mencionar que na correção do cálculo do comprimento especificamente neste caso parece não haver (ou eu pesquisei mal?), há apenas uma proteção que transforma o problema em uma falha HTTP controlada. Embora em 19 de julho na freenginx tenham sido adicionadas algumas correções (5bfb, 7622, b906) de cálculo de comprimento para uma situação semelhante, mas não dá para entender de imediato se isso é ou não é.
A vulnerabilidade surgiu na versão do nginx 0.9.6, e as correções foram incluídas nas versões freenginx 1.31.3, nginx 1.30.4, nginx 1.31.3.
No SA do nginx, há agradecimentos a várias pessoas por relatarem de forma independente a vulnerabilidade e por seguirem os "padrões de divulgação coordenada":
A F5 agradece a Ming Xuan, DKD (@pidifn), Ji’an Zhou e Zhen Yan do AntAISecurityLab, Rafael Gacek, Sergii Negodiuk da EVO.company, Lam Jun Rong do Calif.io, Mufeed VH da Winfunc Research (winfunc.com), Vexera AI (https://vexera.ai), Tu Tran Dinh (@1w4y), Stan Shaw (cyberstan), qianshuidewajueji, zenneth (randomguy6407), Zhenpeng (Leo) Lin do depthfirst, Lukas Johannes Moeller, Melih Tolga Sahin da Vodafone Türkiye, Ayoub Nabil Boubagrat (GitHub: @ayoubnabil), e Milan Jovic (Kljunowsky) por trazerem esta questão à nossa atenção de maneira independente e por seguirem os mais altos padrões de divulgação coordenada.
Na freenginx, as informações que acompanham a correção são limitadas ao comunicado durante o commit. No changelog- essa correção nem mesmo está marcada com a assinatura "segurança" (security), nem "correção" (bugfix), apenas "adição" (feature). Provavelmente, o autor não considerou essa questão crítica. Como as mensagens sobre o problema das pessoas mencionadas na F5 se relacionam com o commit retirado do freenginx, se elas (ou outra pessoa) informaram o autor do freenginx sobre o problema, não foi possível esclarecer.
Fonte: linux.org.ru
