Introduction
Welcome to an insightful conversation on the latest cybersecurity threats targeting web protocols. Today, I’m joined by Rupert Marais, our in-house security specialist with extensive expertise in endpoint and device security, cybersecurity strategies, and network management. With the recent discovery of the “MadeYouReset” vulnerability in HTTP/2, which enables large-scale denial-of-service (DoS) attacks, Rupert is here to break down this complex issue, explore its implications, and share actionable advice for organizations looking to safeguard their systems. We’ll dive into the mechanics of this vulnerability, how it compares to other HTTP/2 exploits, and the steps needed to mitigate such risks in an ever-evolving threat landscape.
Can you explain the MadeYouReset vulnerability in simple terms, and why it’s a concern for servers?
Sure, MadeYouReset is a newly discovered flaw in the HTTP/2 protocol that lets attackers overwhelm a server by bypassing the usual limits on how many requests can be sent at once. Normally, servers cap the number of concurrent HTTP/2 requests per connection—often around 100—to prevent abuse. But with MadeYouReset, an attacker can send thousands of requests, flooding the server and causing a denial-of-service condition for legitimate users. In some cases, it can even lead to crashes or memory issues on certain server setups. It’s a big concern because it directly impacts availability, which is critical for any online service.
How does MadeYouReset stand out as a threat compared to other HTTP/2 vulnerabilities you’ve seen?
What makes MadeYouReset particularly dangerous is how it builds on and bypasses defenses for earlier HTTP/2 attacks like Rapid Reset. While Rapid Reset exploited the RST_STREAM frame to cancel streams rapidly and exhaust server resources, MadeYouReset takes this a step further by tricking the server into sending the RST_STREAM frame itself, rather than the client. This means it completely sidesteps mitigations that were put in place to limit client-initiated stream cancellations after Rapid Reset. It’s a subtle but powerful evolution of protocol abuse that’s harder to detect and block.
Could you walk us through the mechanics of how an attacker pulls off a MadeYouReset attack?
Absolutely. The attack hinges on exploiting specific quirks in the HTTP/2 protocol. An attacker starts by sending a valid request that the server begins processing. Then, they introduce carefully crafted invalid control frames or violate the protocol’s expected sequence—like sending a WINDOW_UPDATE frame with a zero increment or a HEADERS frame after closing a stream. These actions trigger a protocol error, prompting the server to issue an RST_STREAM frame to reset the connection. Since the server is doing the resetting while still processing the request in the background, it wastes resources, and repeating this at scale can cripple the server.
Why is it significant that the server, not the client, sends the RST_STREAM frame in this attack?
That’s a critical piece of the puzzle. When the server sends the RST_STREAM frame, it means the attacker doesn’t have to, which allows them to bypass mitigations designed to limit how many stream cancellations a client can initiate. After the Rapid Reset attack, many servers implemented caps on client-sent RST_STREAM frames to prevent resource exhaustion. MadeYouReset flips the script by making the server do the dirty work, rendering those safeguards useless and allowing the attacker to keep the attack going without hitting any client-side limits.
Which systems or software are most at risk from MadeYouReset, and how can organizations check if they’re vulnerable?
MadeYouReset affects a range of HTTP/2 implementations, with specific products like Apache Tomcat, F5 BIG-IP, and Netty already identified as vulnerable under CVEs like CVE-2025-48989 and others. Some vendors have rolled out patches, but not all systems are updated yet. Organizations can check if they’re at risk by reviewing their server software versions against the published advisories for CVE-2025-8671, the generic identifier for this issue. Additionally, tools like vulnerability scanners or consulting with their IT security teams to audit HTTP/2 traffic for unusual patterns can help identify exposure before an attack happens.
What kind of damage can a successful MadeYouReset attack cause to a server or its users?
The primary impact is a denial-of-service condition, where legitimate users can’t access the server because it’s overwhelmed handling the attacker’s flood of requests. This can disrupt business operations, e-commerce platforms, or any critical service. In more severe cases, depending on the server’s implementation, it can lead to out-of-memory errors or even crashes, as the server struggles to manage the resource drain from processing and resetting thousands of streams. It’s a straightforward but devastating way to knock a service offline.
How does MadeYouReset take advantage of the HTTP/2 protocol’s design, and what flaws does it expose?
MadeYouReset exploits a fundamental mismatch between the HTTP/2 specification and how many real-world servers are architected. The protocol allows for complex interactions with frames like RST_STREAM, which can be used for both normal cancellations and error handling. By sending unexpected or invalid frame sequences, attackers cause protocol violations that force the server to reset streams while still allocating backend resources to process requests. This discrepancy—where the spec is strict, but server implementations vary in handling edge cases—creates a perfect opening for resource exhaustion and DoS attacks.
What practical steps can organizations take right now to protect themselves from MadeYouReset?
First and foremost, apply any available patches or updates from vendors for affected software like Apache Tomcat or F5 BIG-IP. Many have already released fixes for the specific CVEs tied to MadeYouReset. Beyond that, organizations should review their HTTP/2 configurations to ensure they’re enforcing strict protocol compliance and limiting resource allocation per connection where possible. Implementing robust monitoring for unusual traffic patterns, like a spike in RST_STREAM frames from the server side, can also help detect and mitigate attacks early. Finally, consider working with a security provider to stress-test your systems against such vulnerabilities.
What’s your forecast for the future of HTTP/2 vulnerabilities and protocol security in general?
I think we’re going to see more of these subtle, spec-compliant attacks as HTTP/2 remains a cornerstone of modern web infrastructure. The protocol’s complexity offers a lot of room for creative exploitation, especially as attackers refine techniques to bypass mitigations for known issues like Rapid Reset or CONTINUATION Flood. My forecast is that we’ll need a stronger push toward unified implementation standards and proactive security testing for HTTP/2, alongside a growing reliance on AI-driven anomaly detection to catch these nuanced threats. It’s a cat-and-mouse game, and staying ahead will require constant vigilance and collaboration across the industry.
