Varnish sc_rapid_reset: the HTTP/2 Rapid Reset DDoS (CVE-2023-44487)

sc_rapid_reset incrementing on a Varnish instance means the HTTP/2 Rapid Reset rate limiter has closed at least one session for exceeding its configured reset budget. This is the primary detection signal for CVE-2023-44487, the HTTP/2 Rapid Reset DDoS disclosed in October 2023. The attack exploits an asymmetry in HTTP/2: a client can open hundreds of streams per connection and immediately cancel each one with an RST_STREAM frame, forcing the server to do real work (stream setup, header parsing, resource allocation) at near-zero cost to the attacker.

Varnish Cache 7.3.1 and 7.4.2 introduced the h2_rapid_reset* runtime parameters and the sc_rapid_reset counter to detect and limit this pattern. When a client sends RST_STREAM frames faster than the configured threshold, Varnish closes the HTTP/2 session and increments the counter. The rate limiter operates per-session, not globally.

If your Varnish version predates these releases, you have no built-in detection. If you are running a version between the original VSV00013 fix and the VSV00017 patch (released August 2025 as 7.7.2 and 7.6.4), the original rate limiter can be bypassed by a variant attack (CVE-2025-8671) that tricks the server into generating the resets rather than the client. This article covers how to read the relevant counters, confirm whether you are under attack, and apply the right mitigations.

What this means

The CVE-2023-44487 attack works like this:

1. The attacker opens an HTTP/2 connection to the target.
2. For each stream, it sends a HEADERS frame followed immediately by an RST_STREAM frame.
3. The server must process the stream setup (allocate state, parse headers, begin request routing) before processing the reset.
4. The client sends thousands of these open-reset cycles per second across multiple connections.
5. The server burns CPU, memory, and thread resources on work that is immediately discarded.

Varnish’s defense is a per-session rate limiter controlled by three parameters:

• h2_rapid_reset - the duration threshold below which a stream reset is considered “rapid” (a stream that lived shorter than this and was reset counts toward the budget).
• h2_rapid_reset_limit - the maximum number of rapid resets allowed within the measurement window.
• h2_rapid_reset_period - the sliding time window over which rapid resets are counted. The current defaults are 1 second for h2_rapid_reset, 100 resets for h2_rapid_reset_limit, and 60 seconds for h2_rapid_reset_period.

When the limit is exceeded, Varnish closes the HTTP/2 session. The shared memory log records SessError H2: Hit RST limit. Closing session. and the session close reason is RAPID_RESET.

flowchart TD
    A["Attacker opens HTTP/2 connection"] --> B["Open many streams rapidly"]
    B --> C["Send RST_STREAM per stream immediately"]
    C --> D["Varnish: allocate stream state, parse headers"]
    D --> E["Varnish: process RST, tear down stream"]
    E --> F{"Stream lifetime below h2_rapid_reset?"}
    F -->|Yes| G["Count toward rapid reset budget"]
    F -->|No| H["Normal stream close"]
    G --> I{"Budget exceeded in period?"}
    I -->|Yes| J["Close session, sc_rapid_reset increments"]
    I -->|No| K["Continue serving"]
    J --> L["SessClose RAPID_RESET"]

Common causes

Quick checks

# Check rapid reset and related HTTP/2 abuse counters
varnishstat -1 -f MAIN.sc_rapid_reset -f MAIN.sc_bankrupt -f MAIN.req_reset

# Check if HTTP/2 streams are being dropped due to overload
varnishstat -1 -f MAIN.req_dropped -f MAIN.sess_dropped

# Check the rapid reset runtime parameters
varnishadm param.show h2_rapid_reset
varnishadm param.show h2_rapid_reset_limit
varnishadm param.show h2_rapid_reset_period

# Verify vcl_req_reset feature flag is enabled (7.5+)
varnishadm param.show feature | grep vcl_req_reset

# Check Varnish version for CVE patch coverage
varnishd -V

# Look for rapid reset session closures in the log
varnishlog -g session -q 'SessClose ~ "RAPID_RESET"'

# Check thread pool pressure (DDoS collateral)
varnishstat -1 -f MAIN.thread_queue_len -f MAIN.threads -f MAIN.threads_limited

How to diagnose it

1. Confirm sc_rapid_reset is actually incrementing. Take two readings a few seconds apart and compute the delta. A static counter value means no rapid-reset closures are happening right now.

2. Check req_reset alongside sc_rapid_reset. The req_reset counter counts VCL work interrupted because its HTTP/2 stream was no longer open while vcl_req_reset is enabled. If req_reset is climbing but sc_rapid_reset is not, streams are being abandoned during VCL work; this can range from clients abandoning legitimate requests to a reset-amplification variant.

3. Check for VSV00017 exposure. If you see DDoS-like symptoms (thread pool exhaustion, req_dropped incrementing, elevated req_reset) but sc_rapid_reset is flat, check your version. Varnish Cache 7.7.2 and 7.6.4 (released August 2025) close the VSV00017 variant. Varnish Cache 6.0 LTS needs 6.0.15 or later. The VSV00017 advisory at docs.varnish-software.com/security/VSV00017 lists all affected versions.

4. Correlate with thread pool and drop signals. A genuine attack will stress the thread pool before the rate limiter catches every session. Check MAIN.thread_queue_len, MAIN.threads_limited, and MAIN.req_dropped. If these are elevated alongside sc_rapid_reset, the attack is causing collateral damage even though Varnish is closing abusive sessions.

5. Identify source IPs. Use varnishlog to attribute the rapid-reset sessions to specific clients:

   # Show session-level details for rapid reset closures
   varnishlog -g session -q 'SessClose ~ "RAPID_RESET"' -i SessionOpen -i SessClose
   

   A narrow set of source IPs suggests a targeted attack. Distributed source IPs suggest a botnet.

6. Verify your runtime parameters. The defaults should be adequate for most deployments, but if you have tuned h2_rapid_reset_limit downward (tighter) and are seeing false positives on legitimate browser traffic, the limit may be too aggressive. Modern browsers can open 100 or more streams at connection start, and legitimate resets from exceeding concurrency limits can trigger the counting mechanism.

Metrics and signals to monitor

Fixes

Verify patch coverage (both CVEs)

Ensure your Varnish version is patched against both the original CVE-2023-44487 (VSV00013) and the VSV00017 variant (CVE-2025-8671):

If you are between 7.3.1 and 7.6.4/7.7.2, you are vulnerable to the VSV00017 bypass even though the original rate limiter is present. Upgrade is the recommended fix. Varnish Cache 7.3 is end-of-life as of the 7.5 release.

Ensure vcl_req_reset is enabled

The vcl_req_reset feature flag (on by default since Varnish 7.5) is the second line of defense. When the client disconnects or resets a stream mid-request, Varnish interrupts the in-progress VCL processing rather than completing the work for a client that is already gone. The request is logged with a synthetic HTTP 408 status.

This flag partially mitigates the VSV00017 variant even without upgrading, because it prevents the server from completing expensive work for abandoned requests. Do not disable it unless you have a specific, documented reason.

# Check if vcl_req_reset is active
varnishadm param.show feature | grep vcl_req_reset

# It should appear in the enabled features list.
# Do NOT disable it: varnishadm param.set feature -vcl_req_reset

Tune the rapid-reset parameters (with caution)

If you are seeing false positives where legitimate browser traffic triggers sc_rapid_reset, the limit may be too tight. The Varnish developers chose a rate-limit approach over lowering SETTINGS_MAX_CONCURRENT_STREAMS specifically to avoid false positives from browsers that send many parallel requests at connection start. If you have manually tightened the limit, reverting toward the confirmed defaults above should help.

# Increase the number of rapid resets allowed per period
varnishadm param.set h2_rapid_reset_limit <higher_value>

Tightening the limit (lowering it) makes Varnish more aggressive against attackers but risks false positives. Loosening it reduces false positives but gives attackers more headroom. The defaults are designed to balance both concerns.

Per-session tuning with the h2 VMOD

The open-source Varnish Cache h2 VMOD provides per-session overrides of the rapid-reset parameters, allowing you to apply different limits based on client attributes (IP range, User-Agent, TLS characteristics). Functions include h2.rapid_reset(), h2.rapid_reset_limit(), h2.rapid_reset_period(), and h2.rapid_reset_budget(). The h2.rapid_reset_budget() function returns how many more rapid resets the session can send before closure, which can be used for request-level monitoring in VCL.

Disable HTTP/2 as a fallback

If you cannot upgrade and the attack is causing service degradation, disabling HTTP/2 entirely is the emergency fallback:

# Destructive: disables HTTP/2 for all clients.
# Overload will then manifest as sess_dropped (connection drops) rather than
# req_dropped (stream drops). Re-enable after the attack subsides or after upgrading.
varnishadm param.set feature -http2

This forces all traffic to HTTP/1.1. You should also remove h2 from your ALPN protocols if TLS termination is at Varnish. This is a blunt instrument and will impact legitimate HTTP/2 clients, but it eliminates the attack surface entirely.

Edge-layer mitigation

If you have a CDN, load balancer, or WAF in front of Varnish, apply rate limiting and connection limits there. The Rapid Reset attack affects all HTTP/2 servers, not just Varnish. Most CDN providers deployed their own mitigations for CVE-2023-44487 shortly after disclosure. Ensure your edge is patched independently of Varnish.

Prevention

• Keep Varnish patched. Subscribe to Varnish security advisories. The VSV00017 variant was disclosed in August 2025, nearly two years after the original CVE. Staying on the latest stable release ensures both the rate limiter and the vcl_req_reset defense are present.
• Monitor sc_rapid_reset and req_reset continuously. A sustained nonzero sc_rapid_reset rate is the earliest Varnish-native signal of a Rapid Reset attack. If req_reset climbs without sc_rapid_reset following, investigate why clients or server-side behavior are abandoning in-flight streams, including the VSV00017 variant.
• Do not disable vcl_req_reset. It is the defense that covers the variant the rate limiter misses.
• Monitor req_dropped separately from sess_dropped. With HTTP/2, overload manifests as stream drops (req_dropped), not connection drops (sess_dropped). Teams that monitor only sess_dropped will miss HTTP/2 traffic loss entirely.
• Layer defenses. Do not rely on Varnish alone. Apply connection rate limits and HTTP/2 flood protections at the CDN or load balancer layer.

How Netdata helps

• Per-second sc_rapid_reset rate. Netdata’s Varnish collector exposes sc_rapid_reset at per-second resolution, which makes the onset of a Rapid Reset attack visible immediately rather than after a longer polling interval.
• Correlation with req_dropped and thread_queue_len. An attack that overwhelms the rate limiter will push streams into the queue. Watching sc_rapid_reset, req_dropped, and thread_queue_len on the same dashboard reveals whether the rate limiter is keeping up or the attack is causing collateral damage.
• req_reset vs. sc_rapid_reset divergence. Plotting both together reveals the VSV00017 variant pattern: req_reset climbing while sc_rapid_reset stays flat.
• Anomaly detection on session close reasons. Netdata’s ML anomaly detection can flag an unusual distribution of sc_* close reasons, including a spike in RAPID_RESET closures, even if you have not explicitly alerted on the counter.
• Backend request rate correlation. If the attack degrades cache effectiveness, backend_req will spike. Correlating this with sc_rapid_reset confirms the attack is reaching the backend path.

Related guides

• Varnish Error 503 Backend fetch failed: what the error page actually means
• Varnish backend_fail, backend_unhealthy, and backend_busy: three different backend problems
• Varnish backend connection reuse low: keepalive not working and slow TTFB
• Varnish backend probe configuration: threshold, window, interval, and initial
• Varnish backend is sick: health probes, all-backends-sick, and grace
• Varnish ban list growing: O(n) lookups and the lurker falling behind
• Varnish ban lurker not keeping up: contention and ban_lurker_sleep
• Varnish cache hit ratio dropped: hit rate collapse and backend overload
• Varnish cache stampede: a popular object expires and the herd hits the backend
• Varnish child panic: Child died signal, core dumps, and the crash loop
• Varnish ESI errors: broken pages and workspace pressure from Edge Side Includes
• Varnish fetch_failed: backend connected but the fetch broke