MadeYouReset: the HTTP/2 attack that bypassed Rapid Reset fixes

02How does MadeYouReset work?

The attacker opens a stream with a valid, complete request that the server begins processing. Then, instead of cancelling it, the attacker sends a control frame that is invalid in that stream's current state. The HTTP/2 specification says the server must respond to such a stream error with RST_STREAM. The stream immediately transitions to closed and stops counting toward SETTINGS_MAX_CONCURRENT_STREAMS, but in affected implementations the backend keeps computing the response, because it never learns that the stream was cancelled.

Crucially, the request itself is valid, so the server starts real work before the error is triggered. Malformed requests do not work for this, because the server rejects them before doing anything. That distinction is why MadeYouReset keeps backend workers busy, the same property that made Rapid Reset an HTTP flood amplifier.

The researchers documented six RFC-defined ways to provoke a server-sent stream reset after a valid request. They fall into invalid control frames and improper protocol flow. Of these, the researchers found the WINDOW_UPDATE overflow the most consistently effective across implementations.

• WINDOW_UPDATE with an increment of 0
• PRIORITY frame with a length other than 5 bytes
• PRIORITY frame that makes a stream depend on itself
• WINDOW_UPDATE that pushes the flow-control window above 2^31 - 1
• HEADERS sent after the client already closed the stream with END_STREAM
• DATA sent after the client already closed the stream with END_STREAM

03MadeYouReset versus Rapid Reset

The effect is identical — a single connection drives unbounded concurrent backend work while staying under the advertised stream limit. The difference is purely in how the reset is caused, and that difference is enough to walk straight past a defence built only on counting client resets. The CONTINUATION flood (CVE-2024-27316) is a third HTTP/2 denial of service that needs no reset at all.

04Which implementations were affected?

Because MadeYouReset abuses RFC-defined behaviour, many compliant HTTP/2 stacks were affected, each with its own CVE and fix. Several were not: CERT/CC lists Envoy, HAProxy, Go, Node.js and Apache HTTP Server, among others, as not affected, while NGINX and F5 were listed as unknown at disclosure.

The researchers note that some stacks, such as Envoy and gRPC's C core, escalate these protocol errors to connection errors and close the whole connection, which removes the concurrency bypass. That is the clearest endorsement of the right fix: bound the work per connection, not just one cause of resets.

05How do you defend against it?

The fix is the same discipline that protected the unaffected stacks. Do not key your defence on client resets; account for streams and the control frames that cause resets, and treat the connection, not the request, as the unit of enforcement. CERT/CC's headline advice to implementers is to limit the number or rate of RST_STREAM frames the server sends.

• Limit the rate of server-sent RST_STREAM frames per connection, and tear the connection down past a budget
• Limit or reject the control frames that trigger resets — WINDOW_UPDATE with a zero or overflowing increment, malformed PRIORITY frames
• Treat repeated stream errors as a connection-level problem and close the connection
• Cap concurrent backend work per connection so cancelled or reset streams cannot free unlimited capacity
• Patch to the fixed version for every HTTP/2 component in your stack, including libraries behind your own code

06What does it look like in practice?

The traffic signature is high CPU with ordinary bandwidth (a request-rate problem, as bps vs pps vs rps explains), concentrated on a small number of HTTP/2 connections, with an unusual rate of stream errors. Because the resets are server-initiated, logs show the server closing streams rather than clients cancelling them, and control-frame counters (WINDOW_UPDATE, PRIORITY) climb far above normal browser behaviour.

Stacks that expose HTTP/2 metrics make this visible as a spike in stream resets or protocol errors without a matching rise in active connections. If you only alert on bandwidth or on whether the service is up, you will miss it until the origin is already saturated — the same blind spot that makes any application-layer flood hard to see. For how to respond once you spot it, see how to stop a DDoS attack.