Introduction
HTTP/2 was designed for performance- faster multiplexed connections, stream prioritization, and header compression. But these same features have also opened the door for sophisticated denial-of-service attacks. Back in 2023, the HTTP/2 Rapid Reset vulnerability made headlines after attackers exploited the protocol’s stream cancellation mechanism to crash large-scale services.
Now, in a fascinating new variant uncovered through a collaboration between Imperva and researchers from Tel Aviv University, the game has changed. The discovery was made by Gal Bar Nahum, a master’s student, and Professor Anat Bremler-Barr from the Deepness Lab at the Blavatnik School of Computer Science and Artificial Intelligence, together with Dr. Yaniv Harel from the Tel Aviv University Cyber Center. Unlike the original version, where clients spam RST_STREAM frames to exhaust server resources, this new method tricks the server into resetting its own streams, causing similar damage without ever directly violating protocol rules: hence the name: “MadeYouReset”.
Background: What Is The HTTP/2 Rapid Reset Attack?
Disclosed in 2023, the Rapid Reset vulnerability exploited how HTTP/2 handles stream lifecycles. A client rapidly opens and cancels streams using RST_STREAM frames. The trick lies in how the server interprets these resets: it assumes the stream is gone, and that resources have been freed- including the stream count, which governs how many active streams a client can have.
However, although the stream is logically closed, processing and cleanup are still ongoing, and the stream remains active in the backend. This creates a loophole: the server believes it has capacity for more streams and continues accepting new ones, compounding the resource load. Repeating this loop at scale can overwhelm even the most resilient infrastructure.
Fig1: Rapid Reset attack diagram
Industry Response to Rapid Reset: Patch, Rate-Limit, Monitor
Once the attack vector was understood, major infrastructure providers implemented a wide range of mitigation techniques, including:
- Rate limiting the number of RST_STREAM frames per connection or IP.
- Limiting the maximum number of concurrent streams.
- Detecting stream churn as an abuse pattern.
- In extreme cases, downgrading clients to HTTP/1.1 or disconnecting abusers.
Patches in NGINX, Envoy, Apache, and HAProxy added thresholds for stream resets and behavioral analytics to flag clients abusing the protocol.
Introducing The New Variant: “MadeYouReset”
In this newly discovered variant, the attack moves beyond resetting streams directly and instead targets the server’s behavior when handling invalid (but protocol-compliant) frames.
But here’s the twist: the client never sends a single RST_STREAM frame. Instead, it sends carefully crafted frames that violate protocol expectations in subtle ways. The server, upon processing these frames, detects an invalid internal state and reacts by resetting the stream or the entire connection, essentially performing the attack on itself.
Key primitives that were identified:
- Window-Overflow: Sending a WINDOW_UPDATE frame with an increment that causes the flow-control window to exceed 2³¹−1 violates the protocol’s upper bound. The server detects the overflow and cancels the stream with a RST_STREAM frame.
- Zero-Increment: Sending a WINDOW_UPDATE frame with an increment of 0 is explicitly disallowed by the HTTP/2 spec. While the frame is well-formed, it results in a PROTOCOL_ERROR, prompting the server to issue a RST_STREAM.
- Half-Closed Stream Abuse: Once a stream is half-closed (remote), sending additional HEADERS or DATA frames creates a protocol violation. The server must respond with a RST_STREAM to close the stream cleanly. At scale, this technique forces the server into a loop of error-handling and resource cleanup.
- Priority-Length Mismatch: The PRIORITY frame must always be exactly 5 octets long. Any deviation, longer or shorter, breaks the protocol. Servers encountering these invalid frames generate a PROTOCOL_ERROR at the steam level and terminate the session stream, providing attackers with another stealthy reset trigger.
How Does It Work?
The attacker begins by establishing a standard HTTP/2 connection and opening multiple streams. Instead of using RST_STREAM, the attacker sends strategically malformed but syntactically valid frames that trigger protocol violations.
Each of the primitives violates the HTTP/2 specification in subtle ways, and according to RFC 9113, the server must respond with a RST_STREAM frame upon detecting a PROTOCOL_ERROR. Using this way, the stream count can be under the limit, while in reality, there are many active streams in the backend. This results in excessive CPU and memory usage up to a complete denial of service.
Fig2: MadeYouReset attack diagram
The MadeYouReset vulnerability was found to affect several widely used HTTP/2 server implementations, including Netty, Jetty, Apache Tomcat, IBM WebSphere, and BIG-IP. Security updates addressing the issue are now available, and organizations are urged to patch promptly to reduce the risk of exploitation. Additional details on the coordinated disclosure process and research findings can be found on the Tel Aviv University research page.
Why Does It Matter?
- Harder to Detect: There’s no flood of RST_STREAM frames from the client. Instead, the attack uses ordinary-looking frames like WINDOW_UPDATE, HEADERS, or PRIORITY, making it blend in with normal traffic.
- Bypasses Existing Defenses: Most mitigations focus on identifying abusive client behavior, like excessive resets or stream churn. This technique sidesteps those checks by making the server do the resetting.
- Stays Within Spec: The client never breaks the protocol at the packet level. Every frame is syntactically valid, exploiting edge-case behavior rather than sending anything overtly malicious.
PoC Demo: MadeYouReset attack
Mitigation Strategies and Solutions
As the cybersecurity community digests these findings, mitigating server-triggered Rapid Reset variants like MadeYouReset should be a priority. Since the attack leverages legitimate-looking frames that trigger self-inflicted failures, defenses must go beyond traditional client-side rate limiting.
- Stricter Protocol Validation: Developers of HTTP/2 implementations should enforce tighter checks for protocol compliance. Frames such as WINDOW_UPDATE with zero increments or invalid size PRIORITY frames should be immediately rejected at the parsing stage.
- Stream State Enforcement: Servers must rigorously track stream states to reject invalid transitions, such as receiving DATA or HEADERS on half-closed streams, before processing begins.
- Anomaly Detection and Behavioral Monitoring: Deploy monitoring tools that flag unusual patterns, such as high volumes of protocol violations or repeated self-induced resets across connections. These are often precursors to exploitation attempts.
- Connection-Level Rate Controls: Limit the rate of protocol-level errors (e.g., how often a connection triggers GOAWAY or RST_STREAM) rather than focusing solely on client-issued resets. This helps catch stealthy, server-side abuse patterns.
- Regular Updates and Defensive Hardening: Vendors should continuously integrate the latest protocol abuse findings into their HTTP/2 stacks and WAFs. Keeping server software up to date is critical to patching emerging vectors like MadeYouReset.
Conclusion
The discovery of server-triggered Rapid Reset vulnerabilities highlights the evolving complexity of modern protocol abuse. As HTTP/2 remains a foundation of web infrastructure, protecting it against subtle, spec-compliant attacks like MadeYouReset is more critical than ever.
This research underscores the need for proactive defenses, tighter protocol validation, and collaboration across the security and the academic communities. While defending against such stealthy techniques is challenging, identifying and addressing them is essential to maintaining the resilience of our digital ecosystem.
MadeYouReset serves as a reminder: even well-formed traffic can be weaponized if we don’t look closely enough.
Imperva WAF Protects Against HTTP/2-based DDoS Attacks
The Imperva Web Application Firewall (WAF) offers a robust defense against a multitude of cyber threats, including the ‘HTTP/2 Rapid Reset’ and ‘MadeYouReset’ DDoS Attacks, and provides unparalleled visibility into these attacks. Our WAF’s reporting capabilities offer customers a comprehensive and detailed view of all attack vectors, as illustrated in the dashboard below.
Fig3: Imperva’s security event dashboard
While HTTP/2-based DDoS attacks pose a significant threat, Imperva WAF is designed to protect a business from all forms of DDoS attacks. It leverages a global network of scrubbing centers to absorb large volumetric attacks, and its advanced algorithms accurately identify and mitigate application layer attacks.
In addition to its robust protection features, Imperva WAF also provides integrated Attack Analytics that correlates DDoS and related critical events to focus on what truly matters. This allows your business to quickly adjust security policies on the fly based on recommended actions to stop attacks in their tracks.
As a member of the security community, Imperva values its collaborations with companies such as Google and Fastly, as well as collaborative research with Tel Aviv University. Our world is more secure when our industry collaborates to tackle complex security challenges.
The post MadeYouReset: Turning HTTP/2 Server Against Itself appeared first on Blog.