CVE-2022-23959: Varnish Cache Request Smuggling Flaw

CVE-2022-23959 Overview

CVE-2022-23959 is an HTTP Request Smuggling vulnerability affecting Varnish Cache, a widely deployed web application accelerator and caching reverse proxy. The flaw exists in multiple versions of Varnish Cache (before 6.6.2 and 7.x before 7.0.2), Varnish Cache 6.0 LTS (before 6.0.10), and Varnish Enterprise (Cache Plus) versions 4.1.x before 4.1.11r6 and 6.0.x before 6.0.9r4. This vulnerability allows attackers to perform HTTP/1 request smuggling attacks, potentially leading to cache poisoning, credential hijacking, and bypassing security controls.

Critical Impact

Attackers can exploit HTTP/1 connection handling to smuggle malicious requests past security controls, enabling cache poisoning attacks, session hijacking, and unauthorized access to protected 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.0, 10.0, and 11.0
• Fedora 35

Discovery Timeline

• 2022-01-26 - CVE-2022-23959 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2022-23959

Vulnerability Analysis

This vulnerability is classified as CWE-444 (Inconsistent Interpretation of HTTP Requests), commonly known as HTTP Request Smuggling. The flaw stems from how Varnish Cache processes HTTP/1 connections, where discrepancies in request parsing between Varnish and backend servers can be exploited by attackers.

HTTP Request Smuggling occurs when a front-end server (like Varnish Cache) and a back-end server interpret HTTP request boundaries differently. An attacker can craft a malicious request that is processed as a single request by Varnish but interpreted as multiple requests by the backend, or vice versa. This desynchronization allows the attacker to "smuggle" a hidden request that bypasses security controls implemented at the proxy layer.

The vulnerability enables network-based attacks without requiring authentication or user interaction. Successful exploitation can compromise both confidentiality and integrity of data flowing through the cache, though availability is not directly impacted.

Root Cause

The root cause of CVE-2022-23959 lies in the inconsistent handling of HTTP/1 request boundaries within Varnish Cache. Specifically, the vulnerability involves how Varnish parses and interprets Content-Length and Transfer-Encoding headers, allowing attackers to craft requests that create ambiguity in request delimitation between the caching proxy and origin servers.

When Varnish and the backend server disagree on where one request ends and another begins, the request queue becomes desynchronized. This desynchronization is the fundamental mechanism that enables request smuggling attacks.

Attack Vector

The attack is network-based and can be executed remotely without authentication. An attacker sends specially crafted HTTP requests to a Varnish Cache server that exploits parsing inconsistencies. The attack typically involves manipulating Content-Length and Transfer-Encoding headers to create ambiguous request boundaries.

Common attack scenarios include:

1. Cache Poisoning: Smuggled requests can inject malicious content into cached responses, affecting all users who request the poisoned resource
2. Request Hijacking: Attackers can capture or modify requests from other users by prepending their smuggled content to legitimate user requests
3. Security Bypass: Authentication and authorization controls implemented at the Varnish layer can be circumvented

The vulnerability mechanism involves sending HTTP requests with conflicting Content-Length and Transfer-Encoding headers, or using other parsing ambiguities. For detailed technical information, refer to the Varnish Cache Advisory VSV00008 and the Varnish Software Advisory VSV00008.

Detection Methods for CVE-2022-23959

Indicators of Compromise

• Unusual HTTP request patterns with conflicting Content-Length and Transfer-Encoding headers in access logs
• Unexpected cache entries for resources that should not be cached or contain malicious content
• Backend server logs showing requests that were not logged by the Varnish proxy
• Evidence of desynchronized request/response patterns in network traffic analysis

Detection Strategies

• Deploy web application firewalls (WAF) with HTTP request smuggling detection rules to identify and block malformed requests
• Implement deep packet inspection to detect requests with conflicting Content-Length and Transfer-Encoding headers
• Monitor Varnish logs for anomalous request patterns and compare with backend server logs for discrepancies
• Use SentinelOne Singularity Platform to detect exploitation attempts targeting this vulnerability through behavioral analysis

Monitoring Recommendations

• Enable detailed access logging on both Varnish Cache and backend servers to correlate request flows
• Implement alerting for requests containing both Content-Length and Transfer-Encoding headers
• Monitor cache hit/miss ratios for unexpected changes that may indicate cache poisoning attempts
• Review backend server logs for requests that appear malformed or unexpected given the proxy configuration

How to Mitigate CVE-2022-23959

Immediate Actions Required

• Upgrade Varnish Cache to version 6.6.2 or later for 6.x series, or 7.0.2 or later for 7.x series
• For Varnish Cache 6.0 LTS users, upgrade to version 6.0.10 or later
• Varnish Enterprise users should upgrade to 4.1.11r6 or later for 4.1.x series, or 6.0.9r4 or later for 6.0.x series
• Review and apply vendor-provided security patches from the official advisories

Patch Information

Security patches are available from Varnish Software and the Varnish Cache project. Organizations should consult the following resources for patch details:

• Varnish Cache Advisory VSV00008 - Official security advisory with patch information
• Varnish Software Advisory VSV00008 - Enterprise version advisory
• Debian Security Advisory DSA-5088 - Debian-specific patches
• Fedora Package Announcement - Fedora package updates

Workarounds

• Configure backend servers to strictly reject requests with both Content-Length and Transfer-Encoding headers
• Implement strict HTTP request validation at the network perimeter using WAF rules
• Consider placing an additional reverse proxy in front of Varnish that normalizes HTTP requests
• Temporarily disable HTTP/1.1 connection reuse between Varnish and backends as a short-term mitigation (may impact performance)

# Example: Varnish VCL configuration to reject ambiguous requests
# Add to your VCL file in vcl_recv subroutine
sub vcl_recv {
    # Reject requests with both Content-Length and Transfer-Encoding
    if (req.http.Content-Length && req.http.Transfer-Encoding) {
        return (synth(400, "Bad Request"));
    }
}