MadeYouReset: New HTTP/2 DoS Vulnerability Explained

A newly disclosed technique called “MadeYouReset” lets attackers coax HTTP/2 servers into resetting their own streams, slipping past many Rapid Reset defenses. Here’s how it works, who’s affected, and what to do now.

Rapid Reset vs. MadeYouReset

In 2023, CVE-2023-44487 (“Rapid Reset”) showed that rapidly opening and then canceling HTTP/2 streams can overwhelm back‑end processing even after the protocol marks those streams as “closed.” In response, providers began rate‑limiting RST_STREAM bursts, tightening concurrent‑stream caps, and monitoring for excessive churn.

Rapid Reset vulnerability, CVE-2023-44487 (SOCRadar Vulnerability Intelligence)

MadeYouReset keeps the impact but changes the signature. Instead of client‑issued resets, an attacker sends ordinary‑looking HTTP/2 frames that trigger subtle protocol violations. The server reacts by resetting the streams itself, inadvertently increasing resource pressure. Same Denial‑of‑Service (DoS) effect, far less noise.

What’s New with MadeYouReset?

Instead of flooding the server with explicit reset commands, MadeYouReset takes a quieter route. Attackers send frames that look perfectly normal on the surface but cause subtle inconsistencies when processed. These edge-case scenarios force the server to issue its own resets, sometimes even closing the entire connection.

When repeated quickly across many streams, the end result mimics the damage of Rapid Reset, only without the obvious signature that defenders normally watch for.

Key techniques attackers might use include:

• Window overflow: Increasing the flow-control window beyond allowed limits, triggering a reset.
• Zero increment: Sending a WINDOW_UPDATE with a value of zero, which the spec forbids, prompting an error.
• Half-closed stream misuse: Continuing to send data or headers to a stream that should be inactive.
• PRIORITY size mismatch: Sending a priority frame of the wrong size, forcing the server to correct with a reset.

These tactics can trick servers into thinking they have freed up stream capacity while still burning CPU and memory, and in some cases, even crash the system.

Why Defenders Should Care

• Low-profile traffic: The requests resemble normal HTTP/2 operations, making detection harder.
• Bypasses existing safeguards: Many mitigations are tuned to spot client-issued resets; this method sidesteps that by letting the server create the resets itself.
• Spec-compliant on the surface: The attack works within the allowed frame formats, exploiting rare protocol scenarios rather than sending malformed packets.

Who Is Affected & the CVEs to Track

Coordinated disclosure lists multiple popular stacks as impacted, with patches already rolling out. Among those needing attention:

• General tracking: CVE‑2025‑8671 (umbrella identifier for the family) and related vendor advisories; also see CERT/CC notes where available.
• Apache Tomcat: CVE‑2025‑48989.
• Netty: CVE‑2025‑55163.
• F5 BIG‑IP: CVE‑2025‑54500.
• IBM WebSphere Application Server Liberty: CVE‑2025‑36047.
• Jetty: Vendor guidance indicates affected code paths; check Jetty’s channels for MadeYouReset‑specific fixes.

Track the latest CVEs and exploitation trends with SOCRadar Vulnerability Intelligence

SOCRadar’s Vulnerability Intelligence, through the Cyber Threat Intelligence module, keeps you ahead by tracking the latest CVEs, exploit chatter, and threat actor activity tied to your exact tech stack.

Pair it with Attack Surface Management (ASM) to continuously map your exposed assets, spot outdated or misconfigured services, and prioritize patching based on real-world risk. This combination turns a static defense plan into a living, adaptive security posture.

How the MadeYouReset HTTP/2 Attack Works

1. Open a standard HTTP/2 connection and multiple streams under the server’s concurrency cap.
2. Send crafted frames that violate expectations (e.g., WINDOW_UPDATE anomalies, PRIORITY size errors, illegal frames on half‑closed streams).
3. Server detects protocol problems and responds with RST_STREAM or GOAWAY, while back‑end work and memory pressure continue accumulating.
4. Repeat to exceed practical concurrency and resource limits, potentially causing outages or out‑of‑memory conditions.

A diagram of the MadeYouReset attack (Imperva)

How Can You Mitigate the MadeYouReset HTTP/2 Attack?

• Apply vendor patches quickly. Follow security bulletins from your HTTP/2 vendor or reverse proxy/CDN to address CVE-2025-8671 and related vulnerabilities.
• Harden protocol handling. Validate incoming frames at the earliest parsing stage, rejecting any that would create illegal states (e.g., window overflows, zero-increment updates, malformed PRIORITY frames).
• Enforce strict state rules. Prevent DATA or HEADERS from being processed on half-closed streams to avoid unnecessary resource use.
• Watch for stealthy signs. Monitor connection-level errors (e.g., PROTOCOL_ERROR, GOAWAY) and server-originated resets – key indicators of this attack – especially when client resets are absent.
• Limit error rates. Cap the number of protocol-level errors allowed per connection or IP to prevent resource exhaustion.
• Use upstream protection. If your HTTP/2 traffic flows through a CDN or WAF with MadeYouReset or Rapid Reset mitigations, enable them while origin servers are patched.

Once you’ve identified the right defenses, the next step is putting them into action. The checklist below turns these mitigation strategies into concrete, operational tasks for blue teams.

Blue Team Checklist for the MadeYouReset HTTP/2 Attack

• Inventory your HTTP/2 services – include edge servers, load balancers, application gateways, service meshes, and application servers.
• Map to CVEs – check each component against current vendor advisories (e.g., CVE-2025-8671, CVE-2025-48989, CVE-2025-55163, CVE-2025-54500, CVE-2025-36047) and patch the most exposed systems first.
• Deploy targeted monitoring – create dashboards to track spikes in server-initiated resets or protocol errors.
• Test in staging – run simulations for abnormal WINDOW_UPDATE values, sending data to half-closed streams, and invalid PRIORITY frame sizes to confirm protections work.
• Document fallback options – prepare and test a plan for downgrading specific clients or services to HTTP/1.1 as an emergency mitigation.

For the full technical walkthrough and disclosure timeline, see Imperva’s research post and Tel Aviv University’s Deepness Lab project page and publication list.