DISPUTED Varnish 2.0.6 writes data to a log file without sanitizing non-printable characters, which might allow remote attackers to modify a window's title, or possibly execute arbitrary commands or overwrite files, via an HTTP request containing an escape sequence for a terminal emulator. NOTE: the vendor disputes the significance of this report, stating that "This is not a security problem in Varnish or any other piece of software which writes a logfile. The real problem is the mistaken belief that you can cat(1) a random logfile to your terminal safely."

In Varnish Cache before 6.6.2 and 7.x before 7.0.2, Varnish Cache 6.0 LTS before 6.0.10, and and Varnish Enterprise (Cache Plus) 4.1.x before 4.1.11r6 and 6.0.x before 6.0.9r4, request smuggling can occur for HTTP/1 connections.

vbfstperror in bin/varnishd/cache/cachefetch.c in Varnish HTTP Cache 4.1.x before 4.1.9 and 5.x before 5.2.1 allows remote attackers to obtain sensitive information from process memory because a VFPGetStorage buffer is larger than intended in certain circumstances involving -sfile Stevedore transient objects.

An issue was discovered in Varnish Cache before 6.0.4 LTS, and 6.1.x and 6.2.x before 6.2.1. An HTTP/1 parsing failure allows a remote attacker to trigger an assert by sending crafted HTTP/1 requests. The assert will cause an automatic restart with a clean cache, which makes it a Denial of Service attack.

Varnish 3.x before 3.0.7, when used in certain stacked installations, allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via a header line terminated by a \r (carriage return) character in conjunction with multiple Content-Length headers in an HTTP request.

Varnish varnish-modules before 0.17.1 allows remote attackers to cause a denial of service (daemon restart) in some configurations. This does not affect organizations that only install the Varnish Cache product; however, it is common to install both Varnish Cache and varnish-modules. Specifically, an assertion failure or NULL pointer dereference can be triggered in Varnish Cache through the varnish-modules header.append() and header.copy() functions. For some Varnish Configuration Language (VCL) files, this gives remote clients an opportunity to cause a Varnish Cache restart. A restart reduces overall availability and performance due to an increased number of cache misses, and may cause higher load on backend servers.

An issue was discovered in Varnish HTTP Cache 4.0.1 through 4.0.4, 4.1.0 through 4.1.7, 5.0.0, and 5.1.0 through 5.1.2. A wrong if statement in the varnishd source code means that particular invalid requests from the client can trigger an assert, related to an Integer Overflow. This causes the varnishd worker process to abort and restart, losing 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. The specific source-code filename containing the incorrect statement varies across releases.

An issue was discovered in Varnish Cache before 6.0.6 LTS, 6.1.x and 6.2.x before 6.2.3, and 6.3.x before 6.3.2. It occurs when communication with a TLS termination proxy uses PROXY version 2. There can be an assertion failure and daemon restart, which causes a performance loss.

An issue was discovered in Varnish Cache before 6.0.5 LTS, 6.1.x and 6.2.x before 6.2.2, and 6.3.x before 6.3.1. It does not clear a pointer between the handling of one client request and the next request within the same connection. This sometimes causes information to be disclosed from the connection workspace, such as data structures associated with previous requests within this connection or VCL-related temporary headers.

In Varnish Cache 7.0.0, 7.0.1, 7.0.2, and 7.1.0, it is possible to cause the Varnish Server to assert and automatically restart through forged HTTP/1 backend responses. An attack uses a crafted reason phrase of the backend response status line. This is fixed in 7.0.3 and 7.1.1.

This vulnerability may allow for request smuggling attacks, potentially resulting in an unspecified system caching incorrect content.

The bug is an error in how to parse a chunked message body. The RFC tells to use only CRLF sequence to end a line: https://www.rfc-editor.org/rfc/rfc9112.html#name-chunked-transfer-coding However, Varnish has up until now mistakenly treated white-spaces as line ending as well. This allows a client to construct a HTTP/1 request to smuggle another malicious request in the body of the first request. When this is used against an endpoint that is blindly forwarding HTTP requests, it can lead to ways for this client to abuse this behavior of Varnish.

Varnish Cache, with HTTP/2 enabled, allows request smuggling and VCL authorization bypass via a large Content-Length header for a POST request. This affects Varnish Enterprise 6.0.x before 6.0.8r3, and Varnish Cache 5.x and 6.x before 6.5.2, 6.6.x before 6.6.1, and 6.0 LTS before 6.0.8.

libvmod-digest before 1.0.3, as used in Varnish Enterprise 6.0.x before 6.0.11r5, has an out-of-bounds memory access during base64 decoding, leading to both authentication bypass and information disclosure; however, the exact attack surface will depend on the particular VCL (Varnish Configuration Language) configuration in use.

This vulnerability may allow for request smuggling attacks, potentially resulting in an unspecified system caching incorrect content.

The bug is an error in how to parse a chunked message body. The RFC tells to use only CRLF sequence to end a line: https://www.rfc-editor.org/rfc/rfc9112.html#name-chunked-transfer-coding However, Varnish has up until now mistakenly treated white-spaces as line ending as well. This allows a client to construct a HTTP/1 request to smuggle another malicious request in the body of the first request. When this is used against an endpoint that is blindly forwarding HTTP requests, it can lead to ways for this client to abuse this behavior of Varnish.

Varnish before 3.0.5 allows remote attackers to cause a denial of service (child-process crash and temporary caching outage) via a GET request with trailing whitespace characters and no URI.

In Vinyl Cache before 9.0.1 and Varnish Cache before 9.0.3, a deficiency in HTTP/2 request parsing can be exploited to launch a backend request desync attack (request smuggling), which in turn can be used for cache poisoning, authentication bypass, or possibly even information disclosure and manipulation. The attack vector only exists if HTTP/2 support is enabled by setting the feature parameter to contain +http2. HTTP/2 support is disabled by default.

Hello again,

On Tue, May 13, 2025 at 4:57 PM Asad Ahmed <asadsa () varnish-software com> wrote: CVE: Not assigned yet, expect a follow-up here. CVE-2025-47905 <https://www.cve.org/CVERecord?id=CVE-2025-47905>

References: - https://varnish-cache.org/security/VSV00016.html#vsv00016 - https://varnish-cache.org/security/index.html - https://varnish-cache.org/lists/pipermail/varnish-announce/2025-May/000767.html - https://github.com/varnishcache/varnish-cache - https://varnish-cache.org/releases/rel7.7.1.html#rel7-7-1 - https://varnish-cache.org/releases/rel7.6.3.html#rel7-6-3 - https://varnish-cache.org/releases/rel6.0.14.html#rel6-0-14 A follow-up announcement to share an update to the release notes: - https://varnish-cache.org/lists/pipermail/varnish-announce/2025-May/000768.html

-- Asad