Multiple HTTP/2 implementations have been found susceptible to a new attack technique called MadeYouReset that could be explored to conduct powerful denial-of-service (DoS) attacks.
“MadeYouReset bypasses the typical server-imposed limit of 100 concurrent HTTP/2 requests per TCP connection from a client. This limit is intended to mitigate DoS attacks by restricting the number of simultaneous requests a client can send,” researchers Gal Bar Nahum, Anat Bremler-Barr, and Yaniv Harel said.
“With MadeYouReset, an attacker can send many thousands of requests, creating a denial-of-service condition for legitimate users and, in some vendor implementations, escalating into out-of-memory crashes.”
The vulnerability has been assigned the generic CVE identifier, CVE-2025-8671, although the issue impacts several products, including Apache Tomcat (CVE-2025-48989), F5 BIG-IP (CVE-2025-54500), and Netty (CVE-2025-55163).
MadeYouReset is the latest flaw in HTTP/2 after Rapid Reset (CVE-2023-44487) and HTTP/2 CONTINUATION Flood that can be potentially weaponized to stage large-scale DoS attacks.
Just like how the other two attacks leverage the RST_STREAM frame and CONTINUATION frames, respectively, in the HTTP/2 protocol to pull off the attack, MadeYouReset builds upon Rapid Reset and its mitigation, which limits the number of streams a client can cancel using RST_STREAM.
Specifically, it takes advantage of the fact that the RST_STREAM frame is used for both client‑initiated cancellation and to signal stream errors. This is achieved by sending carefully crafted frames that trigger protocol violations in unexpected ways, prompting the server to reset the stream by issuing an RST_STREAM.
“For MadeYouReset to work, the stream must begin with a valid request that the server begins working on, then trigger a stream error so the server emits RST_STREAM while the backend continues computing the response,” Bar Nahum explained.
“By crafting certain invalid control frames or violating protocol sequencing at just the right moment, we can make the server send RST_STREAM for a stream that already carried a valid request.”
The six primitives that make the server send RST_STREAM frames include –
- WINDOW_UPDATE frame with an increment of 0
- PRIORITY frame whose length is not 5 (the only valid length for it)
- PRIORITY frame that makes a stream dependent on itself
- WINDOW_UPDATE frame with an increment that makes the window exceed 2^31 − 1 (which is the largest window size allowed)
- HEADERS frame sent after the client has closed the stream (via the END_STREAM flag)
- DATA frame sent after the client has closed the stream (via the END_STREAM flag)
This attack is notable not least because it obviates the need for an attacker to send an RST_STREAM frame, thereby completely bypassing Rapid Reset mitigations, and also achieves the same impact as the latter.
In an advisory, the CERT Coordination Center (CERT/CC) said MadeYouReset exploits a mismatch caused by stream resets between HTTP/2 specifications and the internal architectures of many real-world web servers, resulting in resource exhaustion — something an attacker can exploit to induce a DoS attack.
“The discovery of server-triggered Rapid Reset vulnerabilities highlights the evolving complexity of modern protocol abuse,” Imperva said. “As HTTP/2 remains a foundation of web infrastructure, protecting it against subtle, spec-compliant attacks like MadeYouReset is more critical than ever.”
HTTP/1.1 Must Die
The disclosure of MadeYouReset comes as application security firm PortSwigger detailed novel HTTP/1.1 desync attacks (aka HTTP request smuggling), including a variant of CL.0 called 0.CL, exposing millions of websites to hostile takeover. Akamai (CVE-2025-32094) and Cloudflare (CVE-2025-4366) have addressed the issues.
HTTP request smuggling is a security exploit affecting the application layer protocol that abuses the inconsistency in parsing non-RFC-compliant HTTP requests by front-end and back-end servers, permitting an attacker to “smuggle” a request and sidestep security measures.
“HTTP/1.1 has a fatal flaw: Attackers can create extreme ambiguity about where one request ends, and the next request starts,” PortSwigger’s James Kettle said. “HTTP/2+ eliminates this ambiguity, making desync attacks virtually impossible. However, simply enabling HTTP/2 on your edge server is insufficient — it must be used for the upstream connection between your reverse proxy and origin server.”
