New HTTP/2 Vulnerability: Understanding the ‘MadeYouReset’ Threat
On August 14, 2025, researchers revealed a significant security vulnerability within HTTP/2 known as MadeYouReset. This exploit poses serious risks to multiple implementations of the protocol, enabling attackers to launch powerful denial-of-service (DoS) attacks that can disrupt services for legitimate users.
How MadeYouReset Works
The MadeYouReset vulnerability effectively circumvents the server’s limitations, which typically restrict the number of concurrent HTTP/2 requests a single client can send. According to the researchers—Gal Bar Nahum, Anat Bremler-Barr, and Yaniv Harel—this limitation is designed to prevent DoS attacks by capping simultaneous requests. However, the MadeYouReset technique allows attackers to flood servers with thousands of requests, potentially overwhelming system resources.
These actions not only disrupt service but can also lead to memory exhaustion in the affected server implementations. Notably, the MadeYouReset vulnerability is categorized under the generic CVE identifier, CVE-2025-8671, affecting various products like Apache Tomcat (CVE-2025-48989), F5 BIG-IP (CVE-2025-54500), and Netty (CVE-2025-55163).
Past Vulnerabilities in HTTP/2
The disclosure of the MadeYouReset vulnerability adds to a concerning trend, as it follows previous vulnerabilities in the HTTP/2 protocol, such as Rapid Reset (CVE-2023-44487) and the HTTP/2 CONTINUATION Flood attack. Each of these exploits could similarly be weaponized to orchestrate extensive DoS assaults.
Technical Mechanism Behind MadeYouReset
Taking further detail into how the MadeYouReset attack unfolds, it capitalizes on the behavior of the RST_STREAM frame within the HTTP/2 protocol. This frame is essential for both canceling client-initiated requests and signaling stream errors. The attack hinges on the generation of carefully crafted frames that cause protocol violations, inadvertently prompting the server to reset the stream via RST_STREAM.
For the MadeYouReset strategy to work, the initial stream must commence with a valid request being processed by the server. The attacker then triggers a stream error that causes the server to emit an RST_STREAM while still working on the response. By sending meticulously crafted invalid control frames or intentionally violating protocol sequence rules, an attacker can cause the server to issue RST_STREAM for streams that initially contained legitimate requests.
Specific Techniques Used in the Attack
The technique involves six specific primitives that induce the server to send RST_STREAM frames:
- WINDOW_UPDATE frame with an increment of zero.
- PRIORITY frame with an invalid length that differs from the standard.
- A PRIORITY frame that incorrectly makes a stream dependent on itself.
- A WINDOW_UPDATE frame that triggers the window size limit.
- Sending a HEADERS frame after the stream has been closed.
- Sending a DATA frame after stream closure.
This attack is noteworthy, not only for sidestepping existing mitigations like Rapid Reset but also achieving a similar harmful impact.
Implications for Server Architecture
The CERT Coordination Center (CERT/CC) has indicated that MadeYouReset exploits fundamental mismatches between HTTP/2 specifications and the underlying architectures of many real-world web servers. This resource exhaustion vulnerability effectively lays the groundwork for potential DoS attacks, amplifying concerns surrounding server reliability and security.
As stated by Imperva, the identification of server-triggered vulnerabilities like Rapid Reset underscores the increasing complexity in modern protocol abuse. Given that HTTP/2 is central to web infrastructure, securing it against these subtle yet impactful attacks is critical.
The Case for Transitioning from HTTP/1.1
The MadeYouReset vulnerability emerges amid ongoing discussions about the need to retire HTTP/1.1. Recent findings from application security firm PortSwigger have uncovered vulnerabilities related to HTTP request smuggling, particularly a CL.0 variant known as 0.CL, compromising countless websites. Solutions have been rolled out by major players like Akamai (CVE-2025-32094) and Cloudflare (CVE-2025-4366) to address these issues.
PortSwigger’s James Kettle emphasizes the inherent flaws in HTTP/1.1 that allow attackers to create ambiguity concerning the treatment of successive requests. Transitioning to HTTP/2 or later versions significantly alleviates these risks. However, it’s insufficient to enable HTTP/2 just at the edge; it must also be consistently employed throughout the entire server architecture, including connections between reverse proxies and origin servers.
This scenario underscores the growing necessity to adopt modern protocols, tightening the noose on legacy technologies that have become increasingly vulnerable in today’s digital landscape.
