Ah, NGINX. O confiável servidor web que silenciosamente alimenta a internet como aquele amigo fiel que sempre aparece com pizza... até que um dia ele acidentalmente inunda sua cozinha com código malicioso porque alguém sussurrou o nome errado de uma variável. Senhoras e senhores, bem-vindos ao CVE-2026-8711, o episódio mais recente da interminável novela intitulada "Como Deixamos os Clientes Controlarem Tudo Novamente?". Nesta emocionante edição, atacantes remotos não autenticados podem provocar um estouro de buffer baseado em heap no módulo JavaScript do NGINX (njs). Sim, você leu certo. Seu sofisticado proxy reverso, que deveria proteger tudo, agora está vulnerável a um clássico "ops, estourou o heap", que pode levar a deliciosas falhas de negação de serviço e, em sistemas mal configurados (estou falando com vocês, inimigos do ASLR), à execução remota completa de código no processo worker.
Imagine a situação: um administrador bem-intencionado habilita o js_fetch_proxy com variáveis controladas pelo cliente. Sabe, coisinhas inocentes como $http_x_user ou $http_x_password. Porque nada transmite mais segurança do que deixar estranhos na internet ajudarem a construir as URLs do seu proxy. Aí ele conecta isso a uma função NJS que chama ngx.fetch(). Pronto. É como dar um lança-chamas para uma criança pequena e dizer: "Só não aponte para as cortinas". Um atacante cria uma requisição HTTP especial e, de repente, o worker do NGINX começa a ter um dia péssimo – a memória heap fica corrompida, o processo trava, reinicia, trava de novo... É o equivalente digital daquele amigo que fica atualizando a página "sem querer" durante uma chamada importante no Zoom. DoS executado com estilo.
E se o ASLR estiver desativado ou configurado de forma inadequada? Parabéns! Você pode ganhar o grande prêmio: execução de código arbitrário. Porque se contentar com servidores travando quando você pode redecorá-los com malware?
CVE: CVE-2026-8711 (soa como um quarto de hotel chique onde o frigobar está cheio de exploits)
CWE: 122 – Estouro de buffer baseado em heap (o caso especial "Não verifiquei o tamanho novamente")
Afetado: versões do njs de 0.9.4 a 0.9.8
Corrigido em: njs 0.9.9 (sim, finalmente contaram até 9 corretamente)
A F5, orgulhosa criadora do NGINX, confirmou que a vulnerabilidade se limita ao plano de dados. O plano de controle está seguro, provavelmente sentado em um canto tomando café e julgando a todos. Outros grandes produtos da F5, como o BIG-IP, aparentemente não foram convidados para essa festa de vulnerabilidades.
O NGINX é famoso por ser leve, rápido e estável. No entanto, aqui estamos em 2026, ainda descobrindo que misturar JavaScript, variáveis controladas pelo cliente e proxy é como misturar Red Bull, tequila e más decisões. Quem poderia prever que deixar estranhos influenciarem suas chamadas fetch() terminaria mal? É quase como se os servidores web continuassem esquecendo a regra de ouro: Nunca confie no cliente. Nem um pouco. Nem mesmo se eles disserem "por favorzinho com $http_x_hax no topo".
O que você deve fazer? (Além de rir/chorar)
Atualize imediatamente para o NGINX JavaScript 0.9.9 ou mais recente. Sim, agora mesmo. Deixe o meme de lado e atualize.
Se você não puder atualizar (por algum motivo), revise suas configurações do js_fetch_proxy com variáveis de cliente. Refatore ou remova esses padrões antes que alguém refatore toda a sua infraestrutura.
Habilitem o ASLR corretamente. Estamos em 2026, pessoal. Parem de viver como se ainda fosse 1999.
Em resumo, mais um dia, mais um estouro de buffer nos lembrando que software é apenas uma maneira sofisticada de dizer "um monte de vulnerabilidades esperando para serem exploradas". O NGINX continua incrível... quando não está ocupado se autodestruindo com um ataque de buffer. Mantenham-se atualizados, pessoal. E talvez parem de deixar cabeçalhos aleatórios construírem suas URLs. Isso não é "dinâmico" – isso é "dinamicamente controlado".
