Uma vulnerabilidade crítica no protocolo HTTP/2, batizada de MadeYouReset e catalogada como CVE-2025-8671, está sendo explorada como vetor para ataques de negação de serviço (DoS) em larga escala. O ataque explora uma falha no mecanismo de controle de fluxo de streams do HTTP/2. Normalmente, quando um servidor recebe uma requisição e decide encerrá-la antecipadamente, ele envia um comando RST_STREAM para interromper o fluxo. No entanto, o MadeYouReset aproveita uma inconsistência, mesmo após o encerramento formal pelo protocolo, o servidor continua processando a requisição internamente.
Isso cria o que os especialistas chamam de “streams zumbis”, que permanecem consumindo CPU e memória sem serem contabilizados como ativos. Essa técnica permite que um invasor envie milhares de requisições falsas de forma contínua, ignorando o limite de 100 streams concorrentes imposto pelo protocolo. Na prática, um único cliente mal-intencionado pode abrir um volume massivo de processos que permanecem ativos no backend, causando lentidão extrema ou até a paralisação total do serviço. Entre as plataformas afetadas estão Apache Tomcat, F5 BIG-IP e implementações do framework Netty.
No caso do Netty, a vulnerabilidade foi corrigida nas versões 4.1.124.Final e 4.2.4.Final, e os administradores são fortemente orientados a atualizar o quanto antes. A F5 já emitiu um boletim específico tratando do problema sob o identificador CVE-2025-54500. O CERT/CC explicou que a vulnerabilidade decorre de um desalinhamento lógico entre o que o protocolo HTTP/2 considera como streams ativos e o que o servidor ainda processa internamente. Esse descompasso cria uma brecha para que invasores explorem os recursos do servidor de maneira silenciosa, muitas vezes sem disparar alarmes de monitoramento convencionais. A descoberta do MadeYouReset remete a um incidente semelhante ocorrido em 2023, quando a falha Rapid Reset também explorava limitações do HTTP/2 para derrubar servidores. Algumas empresas, como a Cloudflare, afirmaram que suas proteções contra o Rapid Reset acabaram mitigando automaticamente o novo ataque. Já a Akamai declarou que recebeu informações antecipadas sobre a vulnerabilidade e implementou contramedidas antes que a falha fosse divulgada publicamente.
