Security, bugs & vulnerabilities on Varnish Cache

VSV00001 DoS vulnerability

Mon, 16 Mar 2026 00:00:00 +0000

CVE-2017-12425

Date: 2017-08-02

A wrong if statement in the varnishd source code means that particular invalid requests from the client can trigger an assert.

This causes the varnishd worker process to abort and restart, loosing the cached contents in the process.

An attacker can therefore crash the varnishd worker process on demand and effectively keep it from serving content - a Denial-of-Service attack.

Mitigation is possible from VCL or by updating to a fixed version of Varnish Cache.

VSV00002 Data leak - ‘-sfile’ Stevedore transient objects

Mon, 16 Mar 2026 00:00:00 +0000

CVE-2017-8807

Date: 2017-11-15

A wrong if statement in the varnishd source code means that synthetic objects in stevedores which over-allocate, may leak up to page size of data from a malloc(3) memory allocation.

In a unpredictable percentage of the cases where this condition arises, a segmentation fault will happen instead.

All the following conditions are required to trigger the problem:

A -sfile or -spersistent stevedore must be configured
A synthetic object must be created in vcl_backend_error{}
The synthetic object ends up in the file or persistent stevedore.

For the third condition can arise in two different ways:

VSV00003 DoS attack vector

Mon, 16 Mar 2026 00:00:00 +0000

CVE-2019-15892

Date: 2019-09-03

An HTTP/1 parsing failure has been uncovered in Varnish Cache that will allow a remote attacker to trigger an assert in Varnish Cache by sending specially crafted HTTP/1 requests. The assert will cause Varnish to automatically restart with a clean cache, which makes it a Denial of Service attack.

The problem was uncovered by internal testing at Varnish Software. It has to the best of our knowledge not been exploited.

VSV00003 DoS attack vector VCL mitigation

Mon, 16 Mar 2026 00:00:00 +0000

Date: 2019-09-03

The issue documented in VSV00003 can be mitigated from VCL where deployment of binary fixes is not possible immediately.

We provide two methods of mitigation, one simple with a performance impact, and one more complex method which can avoid the performance impact, but may also need to the fall back to it.

Simple mitigation

The simple mitigation method is to not use HTTP/1 keepalive connections by setting the Connection: close header of the client response, which is respected by varnish in that it closes the connection after all of the response body has been sent.

VSV00004 Workspace information leak

Mon, 16 Mar 2026 00:00:00 +0000

CVE-2019-20637

Date: 2019-10-21

A bug has been discovered in Varnish Cache where we fail to clear a pointer between the handling of one client requests and the next on the same connection. This can under specific circumstances lead to information being leaked from the connection workspace.

The impact is an information leak, limited to the data in the workspace used for handling the connection. This will typically be data structures and stale header data from previous requests on the same connection, but could also be temporary headers set during processing of VCL.

VSV00005 Varnish HTTP Proxy Protocol V2 Denial of Service

Mon, 16 Mar 2026 00:00:00 +0000

CVE-2020-11653

Date: 2020-02-04

An assert can be triggered in Varnish Cache when using Varnish with a TLS termination proxy, and the proxy and Varnish use the PROXY version 2 protocol to communicate connection details. Depending on the type of proxy used and the details it include in the proxy payload, it may be possible for remote clients to cause Varnish to assert and restart, making it a denial of service attack.

VSV00006 varnish-modules Denial of Service

Mon, 16 Mar 2026 00:00:00 +0000

CVE-2021-28543

Date: 2021-03-16

An assert or NULL pointer dereference can be triggered in Varnish Cache through the header.append() and header.copy() functions from the separate varnish-modules bundle, which, depending on specifics of the Varnish Configuration Language (VCL) file used, might allow for remote clients to cause Varnish to assert and restart.

A restart reduces overall availability and performance due to an increased number of cache misses, and may cause higher load on backend servers.

VSV00007 Varnish HTTP/2 Request Smuggling Attack

Mon, 16 Mar 2026 00:00:00 +0000

CVE-2021-36740

Date: 2021-07-13

A request smuggling attack can be performed on Varnish Cache and Varnish Cache Plus servers that have the HTTP/2 protocol enabled. The smuggled requests do not go through normal VCL processing, and any authorization steps implemented in VCL would be bypassed.

The responses to the smuggled requests can under some circumstances also be obtained by the attacker. Also, it may be possible for an attacker to use this for cache poisoning, where the response to a smuggled request is inserted as the cached content.

VSV00008 Varnish HTTP/1 Request Smuggling Vulnerability

Mon, 16 Mar 2026 00:00:00 +0000

CVE-2022-23959

Date: 2022-01-25

A request smuggling attack can be performed on HTTP/1 connections on Varnish Cache servers. The smuggled request would be treated as an additional request by the Varnish server, go through normal VCL processing, and injected as a spurious response on the client connection.

Identifying smuggled requests

Smuggled requests will show in the logs generated by Varnish as normal requests. It may be possible to identify the smuggled requests by comparing the Varnish logs with logs from any proxy software between the Varnish server and the client.

VSV00009 Varnish Denial of Service Vulnerability

Mon, 16 Mar 2026 00:00:00 +0000

CVE-2022-38150

Date: 2022-08-09

A denial of service attack can be performed against Varnish Cache servers by specially formatting the reason phrase of the backend response status line. In order to execute an attack, the attacker would have to be able to influence the HTTP/1 responses that the Varnish Server receives from its configured backends. A successful attack would cause the Varnish Server to assert and automatically restart.

Versions affected

Varnish Cache releases 7.0.0, 7.0.1, 7.0.2, 7.1.0

Versions not affected

Varnish Cache 7.0.3 (released 2022-08-09)
Varnish Cache 7.1.1 (released 2022-08-09)
All versions of Varnish Cache 6.0 LTS series and Varnish Cache Plus by Varnish Software.
GitHub Varnish Cache master branch at commit c5fd097e5cce8b461c6443af02b3448baef2491d

Mitigation

If upgrading Varnish is not possible, it is possible to mitigate the problem by adding the following snippet at the beginning of the vcl_backend_response VCL function:

VSV00010 Varnish Request Smuggling Vulnerability

Mon, 16 Mar 2026 00:00:00 +0000

CVE-2022-45059

Date: 2022-11-08

A request smuggling attack can be performed on Varnish Cache servers by requesting that certain headers are made hop-by-hop, preventing the Varnish Cache servers from forwarding critical headers to the backend. Among the headers that can be filtered this way are both Content-Length and Host, making it possible for an attacker to both break the HTTP/1 protocol framing, and bypass request to host routing in VCL.

VSV00011 Varnish HTTP/2 Request Forgery Vulnerability

Mon, 16 Mar 2026 00:00:00 +0000

CVE-2022-45060

Date: 2022-11-08

A request forgery attack can be performed on Varnish Cache servers that have the HTTP/2 protocol turned on. An attacker may introduce characters through the HTTP/2 pseudo-headers that are invalid in the context of an HTTP/1 request line, causing the Varnish server to produce invalid HTTP/1 requests to the backend. This may in turn be used to successfully exploit vulnerabilities in a server behind the Varnish server.

VSV00012 Base64 decoding vulnerability in vmod-digest

Mon, 16 Mar 2026 00:00:00 +0000

CVE-2023-41104

Date: 2023-08-17

A base64 decoding vulnerability has been discovered in vmod-digest.

The potential outcome of the vulnerability can be both authentication bypass and information disclosure, however the exact attack surface will depend on the particular VCL configuration in use.

Common usage of vmod-digest is for basic HTTP authentication, in which case it may be possible for an attacker to circumvent the authentication check. If the decoded result string is somehow being made visible to the attacker (for example the result of the decoding is added to a response header), then there is the potential for information disclosure from reading out of band workspace data.

VSV00013 Varnish HTTP/2 Rapid Reset Attack

Mon, 16 Mar 2026 00:00:00 +0000

CVE-2023-44487

Date: 2023-11-13

A denial of service attack can be performed on Varnish Cache servers that have the HTTP/2 protocol turned on. An attacker can create a large volume of streams and immediately reset them without ever reaching the maximum number of concurrent streams allowed for the session, causing the Varnish server to consume unnecessary resources processing requests for which the response will not be delivered.

This is a vulnerability of the protocol itself, HTTP/2 has no provisions for servers to pace the creation of new streams from clients.

VSV00014 Varnish HTTP/2 Broke Window Attack

Mon, 16 Mar 2026 00:00:00 +0000

CVE-2024-30156

Date: 2024-03-18

A denial of service attack can be performed on Varnish Cacher servers that have the HTTP/2 protocol turned on. An attacker can let the server’s HTTP/2 connection control flow window run out of credits indefinitely and prevent progress in the processing of streams, retaining the associated resources.

Versions affected

All Varnish Cache releases with HTTP/2 support except:
- 7.5.x releases
- 7.4.x releases after 7.4.2.
- 7.3.x releases after 7.3.1.
- 6.0.x LTS releases after 6.0.12
Varnish Enterprise by Varnish Software 6.0.x up to and including 6.0.12r5.

Versions not affected

Varnish Cache 7.3.2 (released 2024-03-18)
Varnish Cache 7.4.3 (released 2024-03-18)
Varnish Cache 6.0 LTS version 6.0.13 (released 2024-03-18)
Varnish Enterprise by Varnish Software version 6.0.12r6.

Timeline

2019-04-19 the vulnerability is theorized (see commit message of e1a1fdc7)
2023-08-24 the vulnerability is confirmed
- it happened while working on bringing back the parameters timeout_req and timeout_reqbody to Varnish Enterprise 6.0
2023-09-20 the vulnerability is studied
- once the timeouts are reintroduced in Varnish Enterprise, work started to find an appropriate mitigation
2023-10-10 the HTTP/2 Rapid Reset Attack is disclosed
- work on the Rapid Reset Attack starts, see VSV00013 Varnish HTTP/2 Rapid Reset Attack
- work on the Broke Window Attack mitigation is postponed
2023-10-23 CVE-2023-43622 is published
- it describes a subset of the vulnerability for the Apache HTTP Server
- work on the Broke Window Attack mitigation resumes
- a first iteration is ready and submitted for a review
- the Varnish Cache maintainers are informed
2023-11-16 a second iteration is submitted for review
2023-11-29 the second iteration is approved
- Varnish Enterprise ships the mitigation in the 6.0.12r4 release
2023-12-05 the mitigation is ported to Varnish Cache
- the master branch is targeted
- the mitigation is not ready to publish
2024-01-15 the port to Varnish Cache resumes
- ported to supported branches 7.4, 7.4 and 6.0 LTS
2024-01-17 a regression is discovered
- the second iteration of the mitigation is racy
- when a race occurs, it is partially effective
- offending HTTP/2 streams are reset, but the connection is not closed
2024-01-23 the regression is fixed
- the ports to Varnish Cache are updated
- a bug fix is submitted to Varnish Enterprise
2024-03-05 the port to Varnish Cache master branch is updated
2024-03-18 public advisory and releases

Mitigation

If upgrading Varnish is not possible, it is possible to mitigate the problem by simply disabling HTTP/2 support:

VSV00015 Varnish HTTP/1 client-side desync vulnerability

Mon, 16 Mar 2026 00:00:00 +0000

CVE-2025-30346

Date: 2025-03-18

A client-side desync vulnerability can be triggered in Varnish Cache and Varnish Enterprise. This vulnerability can be triggered under specific circumstances involving malformed HTTP/1 requests.

Certain malformed HTTP/1 requests have been handled by issuing a 400 Bad Request response, and then allowing the connection to carry on with a subsequent request on that same connection. For the case where the initial malformed request contains a request body, the body is not properly processed and is instead treated as the basis for a subsequent request. This can result in the client receiving a response associated with the improperly embedded request as a response to a subsequent request.

VSV00016 Request Smuggling Attack

Mon, 16 Mar 2026 00:00:00 +0000

CVE-2025-47905

Date: 2025-05-12

A client-side desync vulnerability can be triggered in Varnish Cache and Varnish Enterprise. This vulnerability can be triggered under specific circumstances involving malformed HTTP/1 chunked requests.

An attacker can abuse a flaw in Varnish’s handling of chunked transfer encoding which allows certain malformed HTTP/1 requests to exploit improper framing of the message body to smuggle additional requests. Specifically, Varnish incorrectly permits CRLF to be skipped to delimit chunk boundaries.

VSV00017 Varnish HTTP/2 Made You Reset Attack

Mon, 16 Mar 2026 00:00:00 +0000

CVE-2025-8671 VU#767506

Date: 2025-08-13

A denial of service attack can be performed on Varnish Cache servers that have the HTTP/2 protocol turned on. An attacker can create a large number of streams and immediately reset them without ever reaching the maximum number of concurrent streams allowed for the session, causing the Varnish server to consume unnecessary resources processing requests for which the response will not be delivered.

This attack is a variant of the HTTP/2 Rapid Reset Attack, which was handled as VSV00013. The countermeasure put in place for VSV00013 was to implement a rate limit on the number of stream resets allowed before the session would be closed by the Varnish server. The new variant of the attack bypasses this rate limit by executing a benign protocol violation, causing the stream to be reset by the server rather than by the client. This would effectively bypass the rate limit, reopening the attack vector.

VSV00018 Varnish Cache absolute form parsing deficiency

Mon, 16 Mar 2026 00:00:00 +0000

CVE: pending

Date: 2026-03-16

A deficiency in HTTP/1.1 request parsing can potentially be used for cache poisoning or authentication bypass, if the req.url VCL variable gets passed unchecked to a backend which accepts requests with absolute form URIs.

The potential attack surface of this issue is limited to “root” URLs with a path of / as in https://example.com/, but not https://example.com/whatever.

We recommend upgrading to a version which is not affected, or mitigating the issue in VCL, as detailed below.