August 20, 2025 16 min to read

MadeYouReset' HTTP/2 Vulnerability (CVE-2025-8671) Explained

How Servers Can Be Tricked Into Self-Destruction

Introduction

The internet carries much of its vital traffic over the HTTP protocol. With the evolution from HTTP/1.1 to HTTP/2, websites and web apps became dramatically faster, more responsive, and capable of handling heavier loads. But with these leaps forward come new, sometimes quietly lurking, risks. In 2023, the world’s top cloud providers faced the “Rapid Reset” vulnerability, which allowed attackers to crash powerful services using HTTP/2’s own stream management features. While defenses for that attack were deployed quickly, 2025 saw the discovery of a new twist: “MadeYouReset” (CVE-2025-8671). This crafty vulnerability asks a chilling question—what if attackers didn’t flood servers with resets, but instead quietly tricked servers into resetting themselves, bypassing all the common defenses?

In this blog, we’ll journey through the origins and mechanics of the MadeYouReset attack, focusing on how it abuses HTTP/2’s strengths. We’ll explain the basic workings of HTTP/2, demystify the stream reset mechanisms and the history of denial-of-service (DoS) tactics like Rapid Reset, and then lay out exactly how MadeYouReset turns one of modern web’s favorite protocols against itself. Along the way, we’ll examine who is impacted, how the attack actually works, and—perhaps most importantly—what defenders are doing, and can do, to keep servers safe. We’ll end with a look at how this sets the stage for further evolution of HTTP protocol design and best practices.

HTTP/2 Fundamentals: Performance, Multiplexing, and Features

To understand MadeYouReset, it’s important to appreciate how HTTP/2 works and why it became so popular. HTTP/2 is a complete overhaul of web communication, engineered for speed, efficiency, and increased concurrency. Instead of relying on multiple separate TCP connections to serve a webpage—something HTTP/1.1 often requires—HTTP/2 introduced a system that multiplexes many requests and responses over a single, persistent connection2.

Core HTTP/2 Features:

Multiplexing: Multiple simultaneous streams (representing individual requests or responses) share a single TCP connection, making page loads much faster.

Stream Prioritization: Allows clients and servers to control which resources load first, optimizing the user experience for complex websites.

Header Compression (HPACK): Reduces bandwidth and processing costs by compressing HTTP headers, which are otherwise redundantly sent with each request.

Binary Framing Layer: HTTP/2 uses binary instead of textual frames, speeding up parsing and reducing ambiguity.

Server Push: Lets servers preemptively send resources, thinking ahead for the client.

The move from HTTP/1.1 to HTTP/2 was driven by the limitations of the older protocol. HTTP/1.1 suffered from “head-of-line blocking,” meaning a slow piece of content could hold up an entire page load unless the browser opened many connections in parallel—a process that strained both servers and networks. HTTP/2 fixes that by allowing independent, parallel communication over one secure, low-overhead channel, thanks to streams, messages, and frames2.

How Streams Work in HTTP/2:

A stream is a bi-directional, ordered series of frames, each with its own unique identifier.

Streams transition through states (idle, open, half-closed, closed) as requests are sent and completed. Control frames like RST_STREAM (for resets) and WINDOW_UPDATE (for flow control) help manage these states.

Multiplexing enables the browser and server to interleave frames, making much better use of network bandwidth.

The adoption of HTTP/2 across browsers and major web servers (like Apache, NGINX, IIS, Jetty, Netty, and more) further cements its role as a foundation of the modern web1.

Stream Resets and the Origin of “Rapid Reset”

How Stream Resets Work

In HTTP/2, every request and response happens over a stream, and streams can be shut down early—not just at the end of a successful request. Either the client or the server can send a special control frame called RST_STREAM, which instantly ends a stream, usually to signal an error or an abort. This is different from HTTP/1.1, where halting an in-progress transfer typically meant closing the entire TCP connection, causing all in-flight and potentially future requests to be canceled.

The RST_STREAM frame in HTTP/2 is a versatile tool. It can be used for benign reasons, like a user navigating away from a page, or when an error is detected mid-request by the server. However, it also introduces a critical bookkeeping responsibility: When a stream is reset, HTTP/2 considers it immediately closed, freeing up a “slot” for other streams on that connection. This mechanism is policed by the SETTINGS_MAX_CONCURRENT_STREAMS parameter, which limits how many active streams a client can have. Once a stream is reset, it is no longer counted against this limit.

The Rapid Reset Attack (CVE-2023-44487)

image source credits : Imperva

Discovered and weaponized in 2023, the “Rapid Reset” attack (CVE-2023-44487) was a major leap in HTTP/2 denial-of-service vectors6. The attack exploited the very mechanism that makes HTTP/2 cancellation efficient. Attackers would open streams, send requests, and then instantly issue RST_STREAM frames to cancel them. From the HTTP/2 protocol’s perspective, these streams were gone and no longer counted toward the concurrent stream limit. But beneath the surface, servers often continued processing those requests—sometimes all the way to generating a response, only for it to be discarded once it reached the HTTP/2 layer. This led to “phantom” workloads that could massively overload a server’s CPU or memory resources.

At scale, this discrepancy allowed attackers to overwhelm—even crash—massive cloud infrastructures, not by brute force, but by exploiting the protocol’s assumptions and state handling8.

The Industry Response

The Rapid Reset vulnerability was a wake-up call. Vendors and cloud providers responded rapidly, deploying patches and mitigations, such as:

• Rate-limiting client-sent RST_STREAM frames

• Stricter enforcement of MAX_CONCURRENT_STREAMS

• Behavioral monitoring to spot and block abusive reset patterns

• For some, forcibly downgrading suspicious clients to HTTP/1.1 or closing connections entirely5

Enter “MadeYouReset”: A Clever New Attack Vector

What is MadeYouReset (CVE-2025-8671)?

Image source credit : Imperva

In late 2024 and publicly disclosed in August 2025, security researchers from Tel Aviv University (Gal Bar Nahum, Anat Bremler-Barr, and Yaniv Harel) revealed “MadeYouReset,” a new form of HTTP/2-based DoS attack. This vulnerability, tracked as CVE-2025-8671, is built on the same accounting flaw exploited by Rapid Reset—but with a devious twist: the attacker never sends a single RST_STREAM. Instead, the attacker sends protocol-valid but deliberately misused frames to provoke the server into sending RST_STREAM frames on itself. The net result is the same: effectively unlimited concurrent requests can be made, overwhelming backends, but this time, the attack side-steps all those “client reset” countermeasures that were put in place after Rapid Reset11.

At Its Core: Abusing the Server’s Own Error Handling

What differentiates MadeYouReset is that the request appears legitimate—the attack starts by opening and sending a valid HTTP/2 request. Only after the server has accepted and started processing this request does the attacker send frames that provoke a stream error (not a connection error). The server, as required by protocol, sends back its own RST_STREAM for that stream. From the protocol’s point of view, the stream is closed, and the concurrent stream counter is decremented. But critically, the server’s backend continues computing the original request, burning CPU and memory. The attacker repeats the loop, keeping the stream count low, but causing the server to work on hundreds, thousands, or even more concurrent “zombie” requests.

Because the attacker never sends RST_STREAM frames, most existing rapid-reset mitigations—rate limits, logging, and behavioral analytics—are rendered moot11.

The Technical Details: How MadeYouReset Works

Step-by-Step Walkthrough

Connection Established: The attacker creates a normal HTTP/2 connection to the target server.

Valid HTTP/2 Request Sent: For each stream, the attacker sends a fully valid HTTP/2 request—often a HEADERS frame with the END_STREAM flag set, so the server recognizes a complete request.

Server Begins Processing: The server begins backend work, expecting to eventually generate a response.

Malicious Frame Sent: Next, the attacker sends a frame—syntactically valid for HTTP/2—but structured in a way that violates a subtle protocol rule for that stream’s state.

Server Issues RST_STREAM: Detecting the protocol violation, the server (following RFC 9113 specifications) sends a RST_STREAM frame to the client, closing the stream for protocol purposes.

Backend Work Continues: Despite the protocol transition, the server’s backend continues processing the original request, because most implementations decouple protocol stream state from backend/deserialization state.

Repeat: The attacker starts this loop again, racking up unlimited “active” requests on the backend, with only a handful of nominally open streams.

The Attack Primitives

Researchers have identified six key “primitives”—ways to trick the server into issuing a RST_STREAM on a stream that has already been accepted for backend work:

In every case, the attacker ensures that their frame does not cause a connection-level error (like GOAWAY), which would shut down the whole connection and limit attack effectiveness. Each primitive is designed to only cause a stream-level error, so the protocol counter for active streams is freed, but backend work grinds on11.

Why Does This Work?

The foundational flaw is a mismatch between protocol and server backend assumptions:

• HTTP/2 assumes that resetting (closing) a stream means work is over.

• Servers often only stop delivering responses on a reset stream, but do not cancel backend computation already in progress.

This subtlety exists because most modern servers and proxies use internal APIs inherited from HTTP/1.1, where cancellation semantics weren’t strongly specified. The HTTP/2 front-end module simply discards work or responses for streams marked “closed.” Meanwhile, the backend churns along, using CPU, memory, and potentially other resources, sometimes until the task finishes or is garbage-collected much later. In high-load scenarios, this allows a determined attacker to push a server past its safe resource limits and cause a denial of service.

Impact: Who and What Is Affected?

Server Implementations and Vendors Hit

MadeYouReset was found to affect a wide range of popular HTTP/2 implementations and backend platforms, including but not limited to:

• Netty (4.1.x, 4.2.x)

• Jetty

• Apache Tomcat (versions 8.5.0–8.5.100, 9.0.0–9.0.107, 10.1.0–10.1.43, 11.0.0–11.0.9; patched in 8.5.101, 9.0.108, 10.1.44, 11.0.10)

• IBM WebSphere

• F5 BIG-IP

• Varnish (pre-7.7.2, Enterprise 6.0.14r5)

• Node.js (pre-20.9.0 in some HTTP/2 modules)

• Envoy Proxy and others

Cloudflare, Akamai, and several hyperscale CDN or WAF operators reported that their infrastructure was not susceptible, often due to having already implemented more comprehensive controls as part of previous DDoS protection work or rapid reset mitigations17.

Collateral Impact: The New DDoS Asymmetry

What makes MadeYouReset particularly concerning is just how little bandwidth and how small a botnet an attacker actually needs. By piggybacking on server-side error handling, a single connection with a modest stream rate can force the server to do the hard part—processing, allocating memory, and saturating backends with “zombie” requests. Researchers have demonstrated that with only a couple of connections and hundreds of crafted streams, robust enterprise servers could be brought offline in a matter of seconds.

Attackers benefit from:

• High amplification ratio: Minimal packets from the attacker versus significant work by the server.

• Evasion of rate-limits: Because RST_STREAM frames emanate from the server, most per-client or per-IP protections miss the pattern entirely.

• Stealth: The attack traffic blends into normal (but error-prone) network activity, making it harder to spot than a conventional flood.

Industry Coordination and Response

CERT/CC (VU#767506) coordinated the disclosure to affected vendors, and NIST published the CVE-2025-8671 advisory with high-severity warnings. Over 100 vendors were involved in the patching and response process, releasing new versions and mitigation guidance within days or weeks of disclosure. Organizations using affected products are strongly urged to patch immediately, and for those who cannot, to consider disabling HTTP/2 temporarily—a last resort given the associated performance losses16.

In-Depth: The Role of HTTP/2’s Design in Enabling MadeYouReset

HTTP/2’s design, while highly efficient under normal circumstances, is built on the assumption that protocol-level state management (streams, resets, flow control) cleanly lines up with internal backend handling. Unfortunately, in reality, legacy APIs, semi-cooperative thread pools, and asynchronous processing pipelines mean that cancellation at the framing layer does not always propagate immediately, or at all, to lower-level request processing.

The issue is especially acute in proxy and load-balancer architectures, where a front-end HTTP/2 handler translates incoming requests for origination over HTTP/1.1 or other protocols. When a stream is closed at the HTTP/2 level, the downstream proxy may have no way to abort an in-progress request to the backend. This disconnect opens a persistent avenue for DoS amplification, even when both sides of a proxy relationship are patched and modern18.

Mitigation: What Defenders Can Do

Patching and Immediate Fixes

The most critical step is to patch HTTP/2 components with vendor-provided updates as soon as possible. Most major affected server projects have now published hardening fixes that:

Limit the rate or absolute number of server-generated RST_STREAM frames per client connection

Properly account for in-flight backend requests, not just protocol-level streams

Optionally treat repeated stream errors from a single client as a connection-level abuse pattern, leading to a GOAWAY closure or IP block

Vendor Recommendations Include:

Apache Tomcat: Update to version 11.0.10, 10.1.44, 9.0.108, or higher16.

Netty: Update to 4.1.124.Final or 4.2.4.Final

F5 BIG-IP, IBM WebSphere, Jetty, Varnish: Follow vendor advisories and coordination via CERT/CC VU#767506.

Deeper Technical and Operational Safeguards

Short of patching (while you’re waiting for a fix), defenders can take emergency measures:

• Enforce stricter protocol validation: Rejects frames that immediately violate protocol rules (e.g., WINDOW_UPDATE with increment 0 or >2³¹−1, HEADERS/DATA after END_STREAM).

• Monitor and cap server-initiated RST_STREAMs: Set a threshold for how many RST_STREAM frames the server will send per connection or client IP, and sever the connection if exceeded.

• Track actual backend work, not just protocol states: Maintain a separate, application-level count of in-flight HTTP requests, regardless of stream resets, and cap or queue as needed.

• Anomaly detection and behavioral monitoring: Use WAF or SIEM analytics to flag unusual error rates, especially repeated protocol violations or excessive server-side resets that correlate with resource spikes.

• Operational fallback: Where patching is not feasible, and if under attack, disable HTTP/2 support (removing ‘h2’ from your ALPN protocol list in TLS configuration). This should be considered only as a temporary workaround due to loss of HTTP/2’s performance benefits1916.

Protocol-Level Discussion and the Road to Future HTTP/3

MadeYouReset is a symptom of broader challenges in HTTP/2’s state management and the mismatch between protocol and server architectures. While not a protocol bug per se (the protocol operates as specified), the RFCs (including RFC 9113, section 10.5) do highlight the risk of DoS from excessive stream creation, abuse of errors, and header size limits. The onus is currently on implementers to “track the use of these features and set limits on their use”.

Ongoing work in the IETF includes discussions on:

Adopting stream limiting schemes inspired by HTTP/3/QUIC for HTTP/2 connections.

Further tightening the relationship between protocol and backend, so that backend work is canceled or deprioritized immediately when a stream is reset.

Smarter flow control and “end-to-end” cancellation propagation in future web protocols.

Table: Comparison of Rapid Reset vs. MadeYouReset

This comparison demonstrates that, while both attacks exploit similar accounting mismatches, MadeYouReset is notably stealthier and designed to bypass the very controls introduced to counter its predecessor

Thanks to references and articles who made me to understand HTTP/2 Cve