CVE-2024-30156: Varnish Cache DoS Vulnerability

CVE-2024-30156 Overview

CVE-2024-30156 affects Varnish Cache and Varnish Enterprise HTTP/2 implementations. The vulnerability allows remote attackers to exhaust credits for an HTTP/2 connection control flow window. This attack pattern is known as the Broke Window Attack. Affected releases include Varnish Cache before 7.3.2, 7.4.x before 7.4.3, versions before 6.0.13 LTS, and Varnish Enterprise 6 before 6.0.12r6. The flaw maps to [CWE-770] Allocation of Resources Without Limits or Throttling. Exploitation results in availability loss against the caching proxy, disrupting any HTTP service fronted by Varnish.

Critical Impact
Unauthenticated remote attackers can exhaust HTTP/2 flow control credits, causing denial of service against the Varnish caching layer.

Affected Products

Varnish Cache before 7.3.2
Varnish Cache 7.4.x before 7.4.3 and versions before 6.0.13 LTS
Varnish Enterprise 6 before 6.0.12r6

Discovery Timeline

2024-03-24 - CVE-2024-30156 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-30156

Vulnerability Analysis

The vulnerability resides in the HTTP/2 connection-level flow control logic in Varnish Cache. HTTP/2 uses credit-based flow control where each peer advertises a window size that the sender decrements as it transmits DATA frames. Varnish failed to bound how aggressively a client could consume connection-level flow control credits across streams. An attacker can drive the connection into a state where legitimate streams cannot progress, denying service to other users behind the cache.

Root Cause

The root cause is missing throttling on a finite resource, the HTTP/2 connection control flow window. Without limits on credit consumption rate or stream behavior, the server cannot defend against adversarial pacing patterns. This matches the [CWE-770] pattern of allocating resources without sufficient constraints.

Attack Vector

The attack requires only network reachability to the HTTP/2 listener. No authentication or user interaction is needed. A remote client opens an HTTP/2 session and manipulates stream and window state to drain the connection's flow control budget. The Varnish process stops serving requests on the affected connection, and repeated sessions amplify impact across the worker pool.

No verified public exploit code has been released. See the Varnish Cache Security Advisory VSV00014 and the Varnish 7.5 security change notes for the maintainer's technical description.

Detection Methods for CVE-2024-30156

Indicators of Compromise

Sustained HTTP/2 connections from a single client that hold many open streams without completing request bodies or responses.
Spikes in Varnish worker thread saturation, sess_dropped, or req_dropped counters in varnishstat output without a matching legitimate traffic increase.
Repeated WINDOW_UPDATE, RST_STREAM, or SETTINGS frame patterns on HTTP/2 sessions visible in packet captures or reverse proxy logs.

Detection Strategies

Baseline HTTP/2 stream counts per connection and alert when a single client exceeds normal concurrency for sustained periods.
Correlate varnishlog HTTP/2 session events with upstream latency and 5xx rates to surface flow control stalls.
Inspect TLS-terminating proxies in front of Varnish for anomalous HTTP/2 frame distributions per source IP.

Monitoring Recommendations

Forward Varnish counters and access logs to a centralized analytics platform and build dashboards for HTTP/2 session health.
Enable rate limiting and connection metrics at the load balancer to spot resource exhaustion attempts targeting the cache tier.
Track Varnish process restarts, worker queue depth, and connection churn as availability signals.

How to Mitigate CVE-2024-30156

Immediate Actions Required

Upgrade Varnish Cache to 7.3.2, 7.4.3, or 6.0.13 LTS, and Varnish Enterprise 6 to 6.0.12r6 or later.
Inventory all internet-facing Varnish instances and prioritize patching nodes terminating HTTP/2 directly.
Place a hardened reverse proxy or load balancer in front of Varnish to enforce HTTP/2 connection and stream limits if patching is delayed.

Patch Information

Varnish Software released fixes documented in Varnish Security Advisory VSV00014. The 7.5 release notes also reference the security change in What's new in Varnish 7.5. Apply the vendor packages for the matching branch and restart the varnishd service after upgrade.

Workarounds

Disable HTTP/2 on the Varnish listener and serve HTTP/1.1 only until the upgrade is applied.
Terminate HTTP/2 at an upstream proxy that enforces per-connection stream caps and flow control limits, then proxy HTTP/1.1 to Varnish.
Apply network-level rate limits on source IPs that establish abnormally long-lived HTTP/2 sessions.

bash

# Disable HTTP/2 by removing the feature flag from varnishd startup
# Edit /etc/varnish/varnish.params or the systemd unit and ensure
# DAEMON_OPTS does not include: -p feature=+http2

varnishd -a :80 -f /etc/varnish/default.vcl -s malloc,256m \
  -p feature=-http2

systemctl restart varnish