Envoy version 1.14.2, 1.13.2, 1.12.4 or earlier may consume excessive amounts of memory when processing HTTP/1.1 headers with long field names or requests with long URLs.

Envoy version 1.14.2, 1.13.2, 1.12.4 or earlier may consume excessive amounts of memory when proxying HTTP/2 requests or responses with many small (i.e. 1 byte) data frames.

Istio through 1.5.1 and Envoy through 1.14.1 have a data-leak issue. If there is a TCP connection (negotiated with SNI over HTTPS) to *.example.com, a request for a domain concurrently configured explicitly (e.g., abc.example.com) is sent to the server(s) listening behind *.example.com. The outcome should instead be 421 Misdirected Request. Imagine a shared caching forward proxy re-using an HTTP/2 connection for a large subnet with many users. If a victim is interacting with abc.example.com, and a server (for abc.example.com) recycles the TCP connection to the forward proxy, the victim's browser may suddenly start sending sensitive data to a *.example.com server. This occurs because the forward proxy between the victim and the origin server reuses connections (which obeys the specification), but neither Istio nor Envoy corrects this by sending a 421 error. Similarly, this behavior voids the security model browsers have put in place between domains.

CNCF Envoy through 1.13.0 TLS inspector bypass. TLS inspector could have been bypassed (not recognized as a TLS client) by a client using only TLS 1.3. Because TLS extensions (SNI, ALPN) were not inspected, those connections might have been matched to a wrong filter chain, possibly bypassing some security restrictions in the process.

An issue was discovered in Envoy 1.12.0. An untrusted remote client may send HTTP/2 requests that write to the heap outside of the request buffers when the upstream is HTTP/1. This may be used to corrupt nearby heap contents (leading to a query-of-death scenario) or may be used to bypass Envoy's access control mechanisms such as path based routing. An attacker can also modify requests from other users that happen to be proximal temporally and spatially.

An issue was discovered in Envoy 1.12.0. Upon receipt of a malformed HTTP request without a Host header, it sends an internally generated "Invalid request" response. This internally generated response is dispatched through the configured encoder filter chain before being sent to the client. An encoder filter that invokes route manager APIs that access a request's Host header causes a NULL pointer dereference, resulting in abnormal termination of the Envoy process.

Envoy 1.12.0 allows a remote denial of service because of resource loops, as demonstrated by a single idle TCP connection being able to keep a worker thread in an infinite busy loop when continue_on_listener_filters_timeout is used."

Upon receiving each incoming request header data, Envoy will iterate over existing request headers to verify that the total size of the headers stays below a maximum limit. The implementation in versions 1.10.0 through 1.11.1 for HTTP/1.x traffic and all versions of Envoy for HTTP/2 traffic had O(n^2) performance characteristics. A remote attacker may craft a request that stays below the maximum request header size but consists of many thousands of small headers to consume CPU and result in a denial-of-service attack.

In Envoy through 1.11.1, users may configure a route to match incoming path headers via the libstdc++ regular expression implementation. A remote attacker may send a request with a very long URI to result in a denial of service (memory consumption). This is a related issue to CVE-2019-14993.

An issue was discovered in Envoy 1.12.0. An untrusted remote client may send an HTTP header (such as Host) with whitespace after the header content. Envoy will treat "header-value " as a different string from "header-value" so for example with the Host header "example.com " one could bypass "example.com" matchers.