CVE-2025-8671: HTTP/2 Stream Reset DoS Vulnerability

CVE-2025-8671 Overview

CVE-2025-8671 is a denial-of-service vulnerability affecting multiple HTTP/2 server implementations. The vulnerability, dubbed "Made You Reset," exploits a fundamental mismatch between HTTP/2 protocol specifications and the internal architectures of various HTTP/2 implementations. By manipulating stream resets through malformed frames or flow control errors, an attacker can cause excessive server resource consumption, effectively rendering the service unavailable.

Critical Impact

This vulnerability enables attackers to exhaust server resources by exploiting incorrect stream accounting in HTTP/2 implementations, allowing unbounded concurrent streams on a single connection and causing denial-of-service conditions.

Affected Products

• H2O HTTP/2 Server
• Varnish Cache
• BIND9
• Envoy Proxy
• Kong Gateway
• Varnish Hitch
• Wind River Products

Discovery Timeline

• August 13, 2025 - CVE-2025-8671 published to NVD
• November 4, 2025 - Last updated in NVD database

Technical Details for CVE-2025-8671

Vulnerability Analysis

The "Made You Reset" vulnerability exploits a fundamental design gap between the HTTP/2 specification and how servers internally manage stream states. When a client opens multiple HTTP/2 streams and then rapidly triggers the server to reset them using malformed frames or flow control errors, the server's stream accounting becomes incorrect. Streams that are reset by the server are considered closed at the protocol level, freeing up the client's perceived stream count. However, backend processing for these streams continues on the server side.

This creates an asymmetric resource consumption scenario where the client can open what appears to be a limited number of concurrent streams while the server handles an effectively unbounded number of concurrent operations. The vulnerability is classified under CWE-404 (Improper Resource Shutdown or Release), as the core issue lies in servers failing to properly account for and release resources associated with reset streams.

Root Cause

The root cause stems from improper resource management when handling client-triggered server-sent stream resets. HTTP/2 servers maintain internal counters to track active streams and enforce concurrency limits (typically SETTINGS_MAX_CONCURRENT_STREAMS). When a stream is reset due to protocol errors like malformed frames or flow control violations, the server correctly marks the stream as closed at the protocol level. However, in vulnerable implementations, the backend processing associated with that stream continues to consume resources. This allows attackers to bypass concurrency limits since the stream appears closed for accounting purposes while still consuming server-side resources.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker establishes an HTTP/2 connection to the target server and opens multiple streams. For each stream, the attacker deliberately sends malformed frames or triggers flow control errors, causing the server to issue RST_STREAM frames. Because the server considers these streams closed after sending the reset, the attacker can immediately open new streams up to the maximum concurrent stream limit. Meanwhile, backend processing for the "closed" streams continues, allowing the attacker to accumulate resource consumption far beyond the intended limits.

The following code from the H2O HTTP/2 server patch demonstrates how the fix addresses the vulnerability by adding a new flag to track streams reset by peer actions:

             unsigned casper_is_ready : 1;
         } pull;
     };
+    /**
+     * see h2o_http2_conn_t::num_streams.blocked_by_server
+     */
     unsigned blocked_by_server : 1;
+    /**
+     * if the stream was reset by peer sending an RST_STREAM
+     */
     unsigned reset_by_peer : 1;
+    /**
+     * if the stream was reset by peer's invalid action
+     */
+    unsigned reset_by_peer_action : 1;
     /**
      *  state of the ostream, only used in push mode
      */

Source: GitHub H2O Commit

The fix then uses this new flag to properly penalize connections that trigger excessive resets:

     if (stream->blocked_by_server)
         h2o_http2_stream_set_blocked_by_server(conn, stream, 0);
 
-    /* Decrement reset_budget if the stream was reset by peer, otherwise increment. By doing so, we penalize connections that
-     * generate resets for >50% of requests. */
-    if (stream->reset_by_peer) {
+    /* Decrement reset_budget if the stream was reset by peer or by peer's invalid action, otherwise increment. By doing so, we
+     * penalize connections that generate resets for >50% of requests. */
+    if (stream->reset_by_peer || stream->reset_by_peer_action) {
         if (conn->dos_mitigation.reset_budget > 0)
             --conn->dos_mitigation.reset_budget;
     } else {

Source: GitHub H2O Commit

Detection Methods for CVE-2025-8671

Indicators of Compromise

• Unusual spike in HTTP/2 RST_STREAM frames from individual client connections
• High rate of stream creation followed immediately by stream reset errors
• Elevated server CPU and memory utilization without corresponding legitimate traffic increase
• Connection patterns showing maximum concurrent streams being continuously reached and reset

Detection Strategies

• Monitor HTTP/2 connection statistics for abnormal RST_STREAM frame ratios compared to successful request completions
• Implement alerting on connections that exceed a threshold of reset streams within a time window
• Deploy network intrusion detection rules to identify rapid stream open/reset patterns
• Analyze server logs for connections generating disproportionate numbers of protocol errors

Monitoring Recommendations

• Configure HTTP/2 server metrics to track per-connection reset counts and backend processing queue depths
• Establish baseline metrics for normal RST_STREAM frame rates and alert on significant deviations
• Monitor backend worker thread or process utilization alongside HTTP/2 connection statistics
• Implement connection-level rate limiting visibility to identify potential attack sources

How to Mitigate CVE-2025-8671

Immediate Actions Required

• Update all affected HTTP/2 server software to patched versions immediately
• Review and lower SETTINGS_MAX_CONCURRENT_STREAMS to reduce potential attack impact
• Implement connection rate limiting at the load balancer or reverse proxy level
• Consider temporarily downgrading to HTTP/1.1 for critical services if patches are unavailable

Patch Information

Security patches have been released by multiple vendors. Review the following advisories for specific patch information:

• H2O Security Advisory GHSA-mrjm-qq9m-9mjq - H2O HTTP/2 server patch
• Varnish Cache Security Advisory VSV00017 - Varnish Cache patch
• SUSE Knowledge Base Document 000021980 - SUSE product updates
• CERT Vulnerability ID 767506 - Comprehensive vendor patch listing
• Wind River Security Notices - Wind River product updates

Workarounds

• Reduce SETTINGS_MAX_CONCURRENT_STREAMS to a lower value (e.g., 100 or less) to limit potential resource exhaustion
• Implement connection-level rate limiting to restrict the number of new streams per second per client
• Deploy Web Application Firewall (WAF) rules to detect and block connections exhibiting rapid reset patterns
• Consider using a reverse proxy with HTTP/2-to-HTTP/1.1 translation for backend servers

# Example: Limiting concurrent streams in nginx
http {
    http2_max_concurrent_streams 100;
    http2_max_requests 1000;
    limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
    limit_conn conn_limit 10;
}