F5 libera patches emergenciais para duas falhas críticas no NGINX (CVE-2026-42530 e CVE-2026-42055) que permitem execução remota de código sem autenticação

A F5 publicou em 18 de junho atualizações de segurança out-of-band para o NGINX corrigindo duas falhas críticas exploráveis sem autenticação: CVE-2026-42530 no módulo ngx_http_v3_module (HTTP/3) e CVE-2026-42055 nos módulos ngx_http_proxy_v2_module e ngx_http_grpc_module. Ambas permitem que atacantes remotos disparem condição de uso-após-liberação ou estouro de heap nos processos worker, derrubando o servidor por DoS ou, em sistemas com ASLR desabilitado ou contornado, executando código arbitrário. NGINX Plus, NGINX Open Source, NGINX Gateway Fabric e NGINX Instance Manager estão na lista de produtos afetados.

O que aconteceu

NGINX é o servidor web e proxy reverso mais comum em infraestruturas de internet, presente em algo entre 30% e 35% de todos os sites ativos segundo levantamentos públicos. Quando uma falha crítica não autenticada surge nos seus módulos de processamento de protocolo, o universo de alvos é gigantesco. Foi exatamente isso que motivou a F5, dona da NGINX desde 2019, a romper o ciclo regular de patch e publicar uma correção emergencial fora do calendário.

As duas vulnerabilidades críticas atingem cenários distintos. A CVE-2026-42530 está no módulo HTTP/3, ainda relativamente novo e habilitado em proxies que oferecem QUIC para terminação de borda. Já a CVE-2026-42055 vive nos módulos de proxy versão 2 e de gRPC, comuns em ambientes que rodam backends modernos de comunicação por gRPC ou que terminam protocolos baseados em PROXY protocol v2 vindos de load balancers. Em ambos os casos o vetor é uma requisição maliciosa enviada de forma não autenticada.

A F5 também corrigiu, no mesmo pacote, duas falhas de severidade alta no NGINX Gateway Fabric: CVE-2026-11311 e CVE-2026-50107. Essas duas exigem autenticação, mas permitem injetar diretivas arbitrárias na configuração do NGINX, abrindo caminho para escalonamento de privilégios dentro do produto.

Detalhes técnicos

A exploração bem-sucedida das duas falhas críticas dispara use-after-free ou heap overflow dentro do processo worker do NGINX, causando seu reinício imediato. Esse comportamento já é, por si só, condição de negação de serviço. O cenário mais grave acontece quando o atacante consegue contornar o ASLR (Address Space Layout Randomization) ou quando o sistema está configurado sem ele: nesse caso, o caminho até RCE fica aberto. A F5 deixa claro que execução remota de código é resultado possível em configurações não padrão, particularmente em sistemas legados, em containers minimalistas mal endurecidos e em casos em que o atacante combine a falha com primitivas de leitura de memória.

Para quem não consegue aplicar o patch de imediato, a F5 publicou mitigações específicas. Para a CVE-2026-42530, basta desabilitar HTTP/3, removendo a palavra-chave quic de todas as diretivas listen. Para a CVE-2026-42055, a recomendação é remover a diretiva ignore_invalid_headers off do nginx.conf e reduzir o tamanho de large_client_header_buffers para abaixo de 2 megabytes. Nenhuma das mitigações é destrutiva, mas ambas alteram superfícies de protocolo e devem ser testadas antes da implantação em produção.

“A exploração bem-sucedida causa um use-after-free ou estouro de heap no processo worker do NGINX, levando a um reinício. Em ambos os casos, ela também pode executar código em sistemas com Address Space Layout Randomization (ASLR) desabilitado ou quando o atacante puder contornar o ASLR.”
F5, em comunicado de segurança publicado em 18 de junho de 2026

Quem está em risco

Instalações de NGINX Open Source e NGINX Plus que terminam HTTP/3 (QUIC) em borda.
Proxies reversos NGINX intermediando backends gRPC, padrão muito comum em arquiteturas de microsserviços modernas.
Load balancers que repassam tráfego ao NGINX usando PROXY protocol v2 com cabeçalhos influenciáveis por atacante.
Clusters Kubernetes baseados em NGINX Gateway Fabric, especialmente os que oferecem multitenancy.
Sistemas com ASLR desabilitado ou enfraquecido (cenário ainda comum em alguns appliances antigos e em containers customizados).
Operadores de CDN, hospedagens compartilhadas, e-commerce e portais governamentais que adotam NGINX como front-end padrão.

Análise

Embora a F5 afirme que não há, até agora, evidência de exploração ativa, três fatores recomendam cautela elevada. Primeiro, o histórico recente: a CISA já catalogou sete CVEs de F5/NGINX como ativamente explorados nos últimos anos, quatro deles em ataques de ransomware. Segundo, em outubro de 2025 a própria F5 confirmou que atacantes ligados a um estado-nação invadiram seus sistemas em agosto de 2025 e exfiltraram código-fonte do BIG-IP e vulnerabilidades ainda não divulgadas. Esse vazamento de inteligência interna eleva o risco de que correções desta janela já estejam sendo engenharia-reversa por atores estatais para weaponização rápida.

Terceiro, a natureza das falhas, com gatilho em parsing de protocolo via requisição não autenticada, é o tipo perfeito para integração em scanners automatizados e workers ofensivos em larga escala. Em vulnerabilidades semelhantes em NGINX no passado, como a CVE-2026-42945 explorada em maio, o intervalo entre patch e exploração pública em massa foi de poucos dias.

Para o ecossistema brasileiro, a relevância é alta. NGINX é onipresente em sites de governos estaduais, portais de bancos digitais e plataformas de e-commerce. Vale a aplicação rápida do patch em qualquer ambiente que termine HTTP/3 publicamente, mesmo experimentalmente, e a auditoria de configurações de proxy_v2 e gRPC em ingress controllers de clusters Kubernetes em produção.

Recomendações práticas

Aplicar imediatamente as atualizações divulgadas pela F5 nos artigos K000161616 (CVE-2026-42530) e K000161584 (CVE-2026-42055) e, para Gateway Fabric, K000161611 e K000161785.
Se o patch não for viável agora, desabilitar HTTP/3 removendo quic das diretivas listen.
Para a falha de gRPC/proxy_v2, remover ignore_invalid_headers off e reduzir large_client_header_buffers para menos de 2 MB.
Garantir que ASLR e Stack Canaries estejam habilitados em todos os hosts NGINX; auditar containers customizados.
Monitorar logs por crashes recorrentes de workers NGINX e por padrões anômalos de requisições HTTP/3 ou gRPC.
Revisar políticas de WAF e CDN para bloquear cabeçalhos PROXY protocol mal formados em pontos de borda.
Inventariar onde NGINX Gateway Fabric é usado em clusters Kubernetes e restringir permissões de configuração via RBAC.

Fonte: BleepingComputer