HTTP/2 MadeYouReset: The Sneaky New DoS Attack That Can Crash Your Server—Patch It Before It Hits You!

Introduction: A New Wave of DoS at Scale

A new Denial of Service (DoS) vulnerability has been uncovered in the HTTP/2 protocol, and it’s already sending shockwaves through the cybersecurity community. Known as MadeYouReset and tracked as CVE-2025-8671, this flaw allows attackers to trigger massive server resource exhaustion using carefully crafted HTTP/2 frames.

Unlike previous HTTP/2 flaws, this one bypasses some existing defenses (such as Rapid Reset), making it both novel and dangerous. Attackers can crash or severely degrade web servers, application servers, and even reverse proxies at scale with relatively low bandwidth input.

If your infrastructure uses HTTP/2 (which powers the majority of modern web traffic), you need to act now.

What Exactly Is MadeYouReset?

At its core, MadeYouReset is a protocol exploitation of the way HTTP/2 servers handle RESET_STREAM frames.

In HTTP/2, a RESET_STREAM frame is supposed to let a client cancel an in-progress request — for example, if the user stops a page load. But in this attack, adversaries repeatedly send streams that are immediately reset, forcing the server to allocate resources and then tear them down in rapid succession.

Why It Works So Well

• Asymmetric cost: The client spends almost nothing (sending resets is cheap), while the server burns CPU, memory, and sometimes thread pools.
• Bypasses rate-limiting: Requests look “valid” at the protocol level, making them hard to distinguish from real traffic.
• Amplifies easily: Botnets or cloud servers can scale the attack to distributed denial of service (DDoS) levels.

This turns a simple client into a server resource drain cannon.

Attack Mechanics: Step by Step

Here’s how attackers abuse this:

1. Connection Established
   • The attacker opens a valid HTTP/2 connection (TLS or cleartext).
2. Fake Request Streams
   • They start sending new streams with small, cheap HEADERS frames.
3. Immediate Reset
   • Before the server completes handling, the attacker issues a RST_STREAM frame.
4. Server Burnout
   • The server allocates memory/threads for the stream, only to clean up instantly. Repeating this thousands of times creates CPU spikes and memory pressure.
5. Denial Achieved
   • Legitimate clients experience timeouts, connection drops, or full outages.

Impact Assessment

Affected Systems

• Web servers: Apache Tomcat, NGINX (with HTTP/2 enabled), Envoy, Netty-based applications, Node.js with HTTP/2.
• Load balancers: F5 BIG-IP, HAProxy with HTTP/2 support.
• Reverse proxies & CDNs: Those not running mitigations like Cloudflare’s Rapid Reset.

Potential Damage

• Server CPU pegged at 100%
• Memory exhaustion, leading to crashes or restarts
• Denial of critical services (web apps, APIs, SaaS platforms)
• Possible cascade failure in microservices architectures relying on HTTP/2

In essence, one attacker with modest bandwidth can knock out enterprise-grade infrastructure.

Technical Deep Dive: RESET Frame Exploitation

Here’s a simplified view of what’s happening inside the server:

[Attacker]  ----->  [Server]

HEADERS (stream 1)   --> Allocates memory, handler thread
RST_STREAM (stream 1) --> Cleanup begins

HEADERS (stream 2)   --> Allocates resources again
RST_STREAM (stream 2) --> Cleanup again

Repeat thousands of times...

The cleanup path is the weak point. Servers often do:

• Free allocated memory
• Roll back partial state
• Log errors

All of which are expensive operations compared to the attacker’s cost of sending a few bytes.

How to Detect Vulnerability or Ongoing Attacks

1. Log Analysis

Check HTTP/2 debug or error logs for high volumes of RST_STREAM events in short time windows.

2. Network Monitoring

Look for:

• Abnormal spike in HTTP/2 connection churn
• Low bandwidth but high request counts
• Spikes in CPU utilization not matched by traffic volume

3. Penetration Testing

Run controlled tests using tools like h2spec or custom scripts to flood your server with reset frames.

Example using nghttp:

nghttp -nv --no-dep -H ":method: GET" https://yourserver.com/ --reset-after-headers

Immediate Mitigation Steps

If you cannot patch immediately, apply these emergency measures:

1. Rate-Limiting

Configure servers to limit the number of resets per connection. Example in NGINX (with limit_req):

limit_req_zone $binary_remote_addr zone=resetlimit:10m rate=100r/s;
limit_req zone=resetlimit burst=200;

2. Disable or Restrict HTTP/2

As a last resort, fall back to HTTP/1.1 until patches are applied:

Apache:

Protocols h2 http/1.1
ProtocolsHonorOrder On

NGINX:

listen 443 ssl http2;
http2_max_concurrent_streams 100;

(Or remove http2 temporarily.)

3. Deploy WAF/IDS Rules

Use a WAF (e.g., ModSecurity) to detect excessive resets. Some vendors already ship updated signatures.

Long-Term Protection: Patch Now

Several vendors have released official patches:

• Apache Tomcat: Upgrade to 11.0.10, 10.1.44, or 9.0.108
• F5 BIG-IP: Patched in latest hotfixes (check your specific TMOS version)
• Netty: Fixed in Netty 4.1.114.Final
• Envoy Proxy: Patches released in v1.32.2+
• Cloudflare: Already protected via Rapid Reset mitigation
• Kubernetes ingress-nginx: Patch merged; upgrade recommended

📌 Always check your vendor’s security advisories for your exact version.

Case Study: Cloudflare’s Defense

Cloudflare reported that their Rapid Reset mitigation, originally designed for HTTP/2 CVE-2023-44487, incidentally blocked MadeYouReset. By aggressively limiting resets and enforcing stricter state cleanup, their edge network absorbed attack attempts automatically.

This highlights that proactive protocol hardening can protect against not just known but also future classes of vulnerabilities.

Practical Recommendations

1. Patch immediately – Don’t delay; update Tomcat, Netty, Envoy, or your load balancer.
2. Reduce HTTP/2 stream limits – Keep http2_max_concurrent_streams conservative.
3. Implement anomaly detection – Watch for RESET floods in logs.
4. Enable CDN protection – Offload traffic through providers with DDoS filtering.
5. Prepare an incident playbook – Define clear actions (disable HTTP/2, throttle, failover).

Resources & References

• CERT Vulnerability Note VU#767506
• Cloudflare Blog: MadeYouReset
• Imperva Research: Turning HTTP/2 Servers Against Themselves
• Apache Tomcat Security Updates
• F5 BIG-IP Security Advisories

Conclusion: Act Before Attackers Do

The MadeYouReset vulnerability (CVE-2025-8671) is a powerful reminder of how even mature protocols like HTTP/2 can harbor devastating denial-of-service flaws. Attackers don’t need huge botnets anymore — they just need clever exploitation of protocol logic.

If your servers run HTTP/2, assume you’re a target.

• Patch today, not tomorrow.
• Apply temporary mitigations until upgrades are verified.
• Strengthen your monitoring and incident response so future flaws don’t catch you off-guard.

The internet is moving fast — don’t let your servers crash before you do.