CVE-2021-36740

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.

This is Varnish Cache, a web application accelerator also known as a caching HTTP reverse proxy. You install it in front of any server that speaks HTTP and configure it to cache the contents. Varnish Cache is really, really fast. It typically speeds up delivery with a factor of 300 - 1000x, depending on your architecture.

Security Fix(es):

A flaw was found in Varnish. The Varnish Cache, with HTTP/2 enabled, allows request smuggling and VCL authorization bypass via a large Content-Length header for a POST request. As a result, this flaw allows the information on the Varnish cache to be poisoned. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.(CVE-2021-36740)

Varnish Cache is a high-performance HTTP accelerator. It stores web pages in memory so web servers don't have to create the same web page over and over again, giving the website a significant speed up.

Security Fix(es):

• varnish: HTTP/2 request smuggling attack via a large Content-Length header for a POST request (CVE-2021-36740)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

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.

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.

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 (CVE-2021-36740).

This update for varnish fixes the following issues:

varnish was updated to release 7.1.0 [boo#1195188] [CVE-2022-23959]

• VCL: It is now possible to assign a BLOB value to a BODY variable, in addition to STRING as before.
• VMOD: New STRING strftime(TIME time, STRING format) function for UTC formatting.

Update to release 6.6.1

• CVE-2021-36740: Fix an HTTP/2.0 request smuggling vulnerability. [boo#1188470]

Update to release 6.6.0:

• The ban_cutoff parameter now refers to the overall length of the ban list, including completed bans, where before only non-completed (“active”) bans were counted towards ban_cutoff.
• Body bytes accounting has been fixed to always represent the number of body bytes moved on the wire, exclusive of protocol-specific overhead like HTTP/1 chunked encoding or HTTP/2 framing.
• The connection close reason has been fixed to properly report SC_RESP_CLOSE where previously only SC_REQ_CLOSE was reported.
• Unless the new validate_headers feature is disabled, all newly set headers are now validated to contain only characters allowed by RFC7230.
• The filter_re, keep_re and get_re functions from the bundled cookie vmod have been changed to take the VCL_REGEX type. This implies that their regular expression arguments now need to be literal, not e.g. string.
• The interface for private pointers in VMODs has been changed, the VRT backend interface has been changed, many filter (VDP/VFP) related signatures have been changed, and the stevedore API has been changed. (Details thereto, see online changelog.)

Update to release 6.5.1

• Bump the VRT_MAJOR_VERSION number defined in the vrt.h

Update to release 6.5.0

• PRIV_TOP is now thread-safe to support parallel ESI implementations.
• varnishstat's JSON output format (-j option) has been changed.
• Behavior for 304-type responses was changed not to update the Content-Encoding response header of the stored object.

• Update Git-Web repository link

Update to release 6.4.0

• The MAIN.sess_drop counter is gone.
• backend 'none' was added for 'no backend'.
• The hash algorithm of the hash director was changed, so backend selection will change once only when upgrading.
• It is now possible for VMOD authors to customize the connection pooling of a dynamic backend.
• For more, see changes.rst.

Update to release 6.3.2

• Fix a denial of service vulnerability when using the proxy protocol version 2.

Update to release 6.3.0

• The Host: header is folded to lower-case in the builtin_vcl.
• Improved performance of shared memory statistics counters.
• Synthetic objects created from vcl_backend_error {} now replace existing stale objects as ordinary backend fetches would (for details see changes.rst)

It was dicovered that Varnish Cache did not clear a pointer between the handling of one client request and the next request within the same connection. A remote attacker could possibly use this issue to obtain sensitive information. (CVE-2019-20637)

It was discovered that Varnish Cache could have an assertion failure when a TLS termination proxy uses PROXY version 2. A remote attacker could possibly use this issue to restart the daemon and cause a performance loss. (CVE-2020-11653)

It was discovered that Varnish Cache allowed request smuggling and VCL authorization bypass via a large Content-Length header for a POST request. A remote attacker could possibly use this issue to obtain sensitive information. (CVE-2021-36740)

It was discovered that Varnish Cache allowed request smuggling for HTTP/1 connections. A remote attacker could possibly use this issue to obtain sensitive information. (CVE-2022-23959)