CVE-2021-36740: Varnish Cache Auth Bypass Vulnerability

CVE-2021-36740 Overview

CVE-2021-36740 is an HTTP Request Smuggling vulnerability affecting Varnish Cache when HTTP/2 is enabled. The flaw allows attackers to bypass VCL (Varnish Configuration Language) authorization controls by exploiting improper handling of the Content-Length header in POST requests. When a large Content-Length header is provided, the HTTP/2 implementation fails to properly validate request body boundaries, enabling request smuggling attacks that can circumvent security controls.

Critical Impact

Attackers can bypass VCL-based authorization controls, potentially gaining unauthorized access to protected resources or injecting malicious requests into backend server queues.

Affected Products

• Varnish Enterprise 6.0.x before 6.0.8r3
• Varnish Cache 5.x and 6.x before 6.5.2
• Varnish Cache 6.6.x before 6.6.1
• Varnish Cache 6.0 LTS before 6.0.8
• Fedora 33 and 34
• Debian Linux 10.0 and 11.0

Discovery Timeline

• 2021-07-14 - CVE-2021-36740 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2021-36740

Vulnerability Analysis

This vulnerability exists in Varnish Cache's HTTP/2 request handling implementation. The core issue stems from the HTTP/2 protocol handler not properly accounting for the Content-Length header when processing request bodies. In HTTP/2, request body data is transmitted via DATA frames, which are separate from the HEADERS frame containing the Content-Length value. When these two values are inconsistent—particularly when a large Content-Length is specified but less data is actually sent—the Varnish Cache server fails to properly handle the discrepancy.

This desynchronization between the declared content length and the actual request body creates an HTTP Request Smuggling condition. An attacker can craft malicious requests that embed additional HTTP requests within the body, which the backend server interprets differently than the caching proxy, leading to authorization bypass scenarios.

Root Cause

The root cause is insufficient validation of the Content-Length header against actual request body bytes received in HTTP/2 DATA frames. The h2_req structure lacked tracking for received request body bytes (reqbody_bytes), preventing proper validation of the declared vs. actual content length. This allowed attackers to manipulate request boundaries and smuggle additional requests past VCL authorization rules.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:

1. Establishing an HTTP/2 connection to a vulnerable Varnish Cache server
2. Sending a POST request with a Content-Length header larger than the actual body content
3. Embedding a smuggled HTTP request within the malformed request structure
4. The smuggled request bypasses VCL authorization checks as it's processed out of the expected request context

The following patch commits show how the vulnerability was addressed by adding request body byte tracking to the h2_req structure:

 	/* Where to wake this stream up */
 	struct worker			*wrk;

+	ssize_t				reqbody_bytes;
+
 	VTAILQ_ENTRY(h2_req)		tx_list;
 	h2_error			error;
};

Source: GitHub Commit 82b0a629

The protocol handling was also updated to properly track content length:

    struct req *req, struct h2_req *r2)
{
 	h2_error h2e;
-	const char *b;
+	ssize_t cl;

 	ASSERT_RXTHR(h2);
 	assert(r2->state == H2_S_OPEN);

Source: GitHub Commit 9be22198

Detection Methods for CVE-2021-36740

Indicators of Compromise

• Unusual HTTP/2 POST requests with abnormally large Content-Length headers compared to actual body size
• VCL authorization log entries showing access to protected resources without proper authentication flow
• Backend server logs showing unexpected or malformed requests that weren't logged by the Varnish frontend
• HTTP/2 connection streams with mismatched content length and DATA frame totals

Detection Strategies

• Monitor HTTP/2 traffic for POST requests where Content-Length exceeds the actual payload size
• Implement log correlation between Varnish Cache and backend servers to identify request desynchronization
• Deploy intrusion detection rules to flag HTTP/2 streams with suspicious content-length discrepancies
• Review VCL authorization logs for access patterns that bypass expected authentication flows

Monitoring Recommendations

• Enable detailed HTTP/2 protocol logging in Varnish Cache to capture header and body size metrics
• Configure alerts for backend requests that lack corresponding frontend authorization records
• Implement request integrity validation between Varnish and backend servers
• Monitor for repeated connection patterns from single sources attempting HTTP/2 smuggling variations

How to Mitigate CVE-2021-36740

Immediate Actions Required

• Upgrade Varnish Cache to version 6.5.2, 6.6.1, or 6.0.8 (LTS) or later immediately
• For Varnish Enterprise, upgrade to version 6.0.8r3 or later
• If immediate patching is not possible, disable HTTP/2 support temporarily
• Review access logs for signs of exploitation attempts

Patch Information

Security patches are available through the official Varnish Cache project and distribution package managers. The vulnerability is tracked as Varnish Security Advisory VSV00007. Fixed versions include:

• Varnish Cache 6.5.2 and later
• Varnish Cache 6.6.1 and later
• Varnish Cache 6.0.8 LTS
• Varnish Enterprise 6.0.8r3

Distribution-specific advisories are available:

• Debian Security Advisory DSA-5088
• Fedora Package Announcements

Workarounds

• Disable HTTP/2 support in Varnish Cache configuration if patching is not immediately possible
• Implement additional request validation at the backend server level
• Deploy a Web Application Firewall (WAF) with HTTP/2 request smuggling detection capabilities
• Enforce strict Content-Length validation at the network perimeter

# Disable HTTP/2 in Varnish Cache configuration
# Edit /etc/varnish/default.vcl or equivalent configuration file
# Remove or comment out HTTP/2 related parameters

# For systemd-based systems, modify the varnish service parameters
# Edit /etc/systemd/system/varnish.service or /lib/systemd/system/varnish.service
# Remove the -p feature=+http2 parameter from ExecStart

# Restart Varnish to apply changes
systemctl daemon-reload
systemctl restart varnish