CVE-2026-40396: Varnish Cache DoS Vulnerability

CVE-2026-40396 Overview

CVE-2026-40396 is a denial-of-service vulnerability in Varnish Cache 9.0.0 caused by a workspace overflow during HTTP/1 request pipelining. A malicious client can send an HTTP/1 request, wait until the session releases its worker thread via timeout_linger, then resume traffic before the session closes via timeout_idle. By submitting multiple requests at once during this window, the attacker triggers a pipelining operation that overflows workspace_client, causing the Varnish daemon to panic and crash. The flaw was introduced when the Varnish Enterprise non-blocking HTTP/2 architecture was ported to Varnish Cache, and a merge conflict resolution missed a code path that should have performed a complete workspace rollback.

Critical Impact
Remote unauthenticated attackers can crash the Varnish Cache daemon by exploiting HTTP/1 request pipelining timing windows, resulting in service disruption for cached web traffic.

Affected Products

Varnish Cache 9.0.0
Deployments using HTTP/1 with default timeout_linger and timeout_idle settings
Caching proxy infrastructure derived from Varnish Cache 9.0.0

Discovery Timeline

2026-04-12 - CVE-2026-40396 published to the National Vulnerability Database (NVD)
2026-04-17 - Last updated in NVD database

Technical Details for CVE-2026-40396

Vulnerability Analysis

The vulnerability is classified under [CWE-670] Always-Incorrect Control Flow Implementation. It affects the worker thread session lifecycle in Varnish Cache 9.0.0, specifically the transition logic between consecutive HTTP/1 requests on the same client session.

Varnish maintains a per-client workspace called workspace_client to hold request data. When a session is idle but not yet closed, the worker thread is released after timeout_linger. If new traffic arrives before timeout_idle expires, the session resumes and begins processing the next request. During this transition, prefetched data must fit within the existing workspace allocation.

The bug originates from a port of the Varnish Enterprise non-blocking HTTP/2 architecture into Varnish Cache 9. The port introduced a new workspace API that formalized the pipelining operation. Merge conflicts arose from differences such as partial trailer support in Varnish Enterprise. During conflict resolution, one code path that configures pipelining was not updated to perform a complete workspace rollback.

Root Cause

The missed code path eliminated the guarantee that prefetched data would fit inside workspace_client during the transition from one request to the next. When the attacker stacks multiple pipelined requests after the timeout_linger window, the cumulative data exceeds the workspace boundary. Varnish detects this overflow condition and triggers a daemon panic as a safety measure, terminating the worker process.

Attack Vector

The attack requires no authentication and can be executed by any client able to reach the Varnish HTTP port. The attacker opens an HTTP/1 connection, sends an initial request, then waits for the duration of timeout_linger so the worker thread is released. Before timeout_idle elapses, the attacker sends multiple additional requests in rapid succession on the same connection. The pipelining transition path fails to roll back the workspace, the overflow check fires, and the daemon panics. See the GitHub Issue Discussion for the upstream technical analysis.

Detection Methods for CVE-2026-40396

Indicators of Compromise

Unexpected Varnish daemon panic messages referencing workspace overflow in workspace_client
Repeated child process restarts logged by the Varnish management process (varnishd)
HTTP/1 client sessions exhibiting long idle gaps followed by bursts of pipelined requests
Sudden drops in cache hit rates correlated with worker process crashes

Detection Strategies

Monitor varnishlog and syslog output for Panic and WS_ (workspace) assertion failures
Alert on Varnish child process restart counters exceeding baseline thresholds
Inspect HTTP access logs for client sessions with timing patterns matching timeout_linger followed by pipelined request bursts
Correlate panic events with source IPs to identify repeat offenders

Monitoring Recommendations

Track Varnish daemon uptime and child process restart frequency as a service-health metric
Forward Varnish logs to a centralized log platform for retention and correlation with edge traffic
Establish baseline values for MAIN.client_req and MAIN.sess_dropped counters to detect anomalous request patterns
Review reverse proxy and load balancer logs for HTTP/1 connection reuse patterns matching the exploit timing window

How to Mitigate CVE-2026-40396

Immediate Actions Required

Upgrade Varnish Cache to version 9.0.1 or later, which contains the fix per the GitHub Release Notes v9.0.1
Restrict direct internet exposure of Varnish instances where feasible, placing them behind authenticated edge proxies
Configure process supervisors to restart varnishd quickly to limit downtime if a panic occurs
Audit Varnish deployments to confirm version 9.0.0 instances are identified and prioritized for patching

Patch Information

The fix is included in Varnish Cache 9.0.1. The patch restores the workspace rollback logic in the pipelining code path, ensuring that prefetched data is correctly bounded by workspace_client during request-to-request transitions. Operators should review the upstream release notes and apply the update through their package manager or source build pipeline.

Workarounds

Disable HTTP/1 keep-alive or reduce timeout_idle to a value that minimizes the exploit window between timeout_linger and session close
Place a hardened reverse proxy in front of Varnish to terminate and normalize HTTP/1 connections
Apply rate limiting on pipelined HTTP/1 requests at the network edge
Use Web Application Firewall (WAF) rules to drop sessions exhibiting the timing pattern described in the GitHub Issue Discussion

bash

# Configuration example - reduce idle timeout to shrink the exploit window
varnishd -a :80 \
  -f /etc/varnish/default.vcl \
  -p timeout_idle=5 \
  -p timeout_linger=0.5 \
  -s malloc,256m