Welcome to the deep dive into MadeYouReset. If you haven’t read the intro yet, start there for the high‑level picture. In this post, we’ll cover how MadeYouReset works - by getting familiar with the six MadeYouReset primitives - and the two behaviors that make it work:

1. How HTTP/2 counts active streams (by inspecting its state machine)
2. Why backend work often continues after a stream reset - which helps explain why so many vendors were affected

If you’ve been following along, we’ve already seen why HTTP/2 makes it easy to spin up work and why MadeYouReset can push servers into unbounded in‑flight requests. In this post, we’ll talk about the thing that sounds like it should save the day but usually doesn’t: end‑to‑end request cancellation.

Let’s talk about impact. In the first post we met MadeYouReset and how it bypasses Rapid Reset mitigations. In the second, we went down the rabbit hole of stream states, primitives, and why work keeps happening after a stream is reset. Here we’ll make it practical: what the attack is actually bounded by, how to measure it properly (and how not to), and where to find the “significant” impact in real systems.

During recent research into HTTP/2, I found a DoS vulnerability I call MadeYouReset (CVE‑2025‑8671), publicly disclosed on 13 Aug 2025. It lets an attacker create effectively unbounded concurrent work on servers by bypassing HTTP/2’s built-in concurrency limit - causing a denial of service condition. It builds on the flaw behind 2023’s “Rapid Reset”, with a neat twist that slips past the common mitigation. In this post, we’ll cover how MadeYouReset works at a high level.

In the last blog post we talked about the shortcomings of HTTP/1.1 and the magical promises of HTTP/2. But how does that actually work under the hood? By the end of the first part of the “HTTP/2 - How?” posts, you’ll understand exactly how HTTP/2 implements the binary frames that are the basic units of the protocol, how stream multiplexing works, what are the different types of frames HTTP/2 uses, what are their purpose and we will wrap everything up with understanding the protocol flow of HTTP/2.

In this post, we will see why we needed HTTP/2, and more precisely, where HTTP/1.1 falls short. Then we will look at how HTTP/2 solves those problems at a high level.