CVE-2022-23959: Varnish Cache Request Smuggling Flaw

CVE-2022-23959 Overview

CVE-2022-23959 is an HTTP request smuggling vulnerability affecting Varnish Cache and Varnish Enterprise (Cache Plus) deployments. The flaw allows attackers to smuggle HTTP requests through HTTP/1 connections, bypassing security controls applied at the cache layer. Affected versions include Varnish Cache before 6.6.2, 7.x before 7.0.2, Varnish Cache 6.0 LTS before 6.0.10, Varnish Enterprise 4.1.x before 4.1.11r6, and 6.0.x before 6.0.9r4. The vulnerability is tracked under [CWE-444] Inconsistent Interpretation of HTTP Requests. Linux distributions including Debian and Fedora shipped vulnerable packages and issued coordinated updates.

Critical Impact
Remote unauthenticated attackers can smuggle HTTP requests through Varnish Cache, enabling cache poisoning, security control bypass, and unauthorized access to backend resources.

Affected Products

Varnish Cache versions before 6.6.2 and 7.x before 7.0.2
Varnish Cache 6.0 LTS before 6.0.10
Varnish Enterprise (Cache Plus) 4.1.x before 4.1.11r6 and 6.0.x before 6.0.9r4
Debian Linux 9, 10, 11 and Fedora 35 distributions shipping affected packages

Discovery Timeline

2022-01-26 - CVE-2022-23959 published to NVD
2022-02 - Debian LTS announcement releases patched packages
2022-03 - Fedora package announcement releases updates
2024-11-21 - Last updated in NVD database

Technical Details for CVE-2022-23959

Vulnerability Analysis

The vulnerability is an HTTP Request Smuggling flaw classified under [CWE-444]. Varnish Cache acts as a reverse proxy between clients and backend origin servers. When Varnish and the backend disagree on the boundaries of an HTTP/1 request, an attacker can craft a request that is interpreted as one request by Varnish and as two requests by the backend. The smuggled request bypasses Varnish-enforced controls and can poison cached responses for other users. The issue is exploitable over the network without authentication or user interaction, and is documented in Varnish Security Advisory VSV00008.

Root Cause

The root cause is inconsistent parsing of HTTP/1 request framing headers between Varnish Cache and backend servers. Discrepancies in how Content-Length and Transfer-Encoding headers are interpreted allow an attacker to embed a hidden request inside the body of an outer request. Varnish forwards both the visible and smuggled portions to the backend, which then processes them as separate requests.

Attack Vector

An unauthenticated remote attacker sends a specially crafted HTTP/1 request to a Varnish instance over the network. The request contains conflicting or malformed framing directives. Varnish processes the request based on its interpretation, while the backend processes the embedded smuggled request independently. The smuggled request can be used to poison the cache, redirect responses intended for other clients, or reach administrative endpoints that should not be exposed.

Full technical details, affected ranges, and fixed versions are documented in the Varnish Security Advisory VSV00008.

Detection Methods for CVE-2022-23959

Indicators of Compromise

HTTP/1 requests with both Content-Length and Transfer-Encoding: chunked headers reaching Varnish instances
Anomalous cache hits returning responses inconsistent with the requested URL or host
Unexpected backend responses logged in varnishlog that do not correspond to any client-issued request
Spikes in 4xx or 5xx responses from backends following malformed request headers

Detection Strategies

Inspect Varnish access logs and varnishncsa output for requests carrying conflicting framing headers or unusual whitespace in header names
Compare request counts and request boundaries between Varnish and backend application logs to surface desynchronization
Deploy a web application firewall rule set that rejects HTTP/1 requests containing both Content-Length and Transfer-Encoding headers

Monitoring Recommendations

Centralize Varnish, load balancer, and backend access logs and correlate request IDs to detect mismatched request counts
Alert on responses served from cache that contain content from unrelated hosts or paths, which indicates potential cache poisoning
Monitor the installed Varnish version against the fixed releases listed in VSV00008 as part of routine vulnerability management

How to Mitigate CVE-2022-23959

Immediate Actions Required

Upgrade Varnish Cache to 6.6.2, 7.0.2, or 6.0.10 LTS, and Varnish Enterprise to 4.1.11r6 or 6.0.9r4 or later
Apply distribution updates from the Debian Security Advisory DSA-5088 and the Fedora package announcement
Restart the varnishd service after patching to ensure the new binary is loaded
Audit Varnish-fronted applications for evidence of cache poisoning or unauthorized backend access

Patch Information

Varnish Software released fixed versions concurrent with the VSV00008 advisory. Debian addressed the issue across stable, oldstable, and LTS releases via DSA-5088 and the Debian LTS announcement. Fedora 35 received an updated package documented in the Fedora package announcement.

Workarounds

Place a strict reverse proxy or WAF in front of Varnish to normalize HTTP/1 requests and reject those with conflicting Content-Length and Transfer-Encoding headers
Disable HTTP/1 keep-alive on exposed listeners where feasible to limit smuggling reuse across requests
Restrict direct network exposure of Varnish to trusted upstream proxies until patches are applied

bash

# Verify installed Varnish version against fixed releases
varnishd -V

# Debian/Ubuntu: install patched package
sudo apt-get update && sudo apt-get install --only-upgrade varnish

# Fedora: install patched package
sudo dnf upgrade varnish

# Restart service after upgrade
sudo systemctl restart varnish