CVE-2020-11767 in Istio
Summary
by MITRE
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 05/07/2025
The vulnerability described in CVE-2020-11767 represents a critical data leakage issue affecting Istio service mesh versions 1.5.1 and earlier, along with Envoy proxy versions 1.14.1 and earlier. This security flaw stems from improper handling of HTTP/2 connection reuse in environments where multiple domains share common parent domains, creating a scenario where sensitive data can be inadvertently transmitted to incorrect servers. The issue specifically manifests when TCP connections are established through SNI-based HTTPS negotiation to wildcard domains such as *.example.com, while explicit domain configurations like abc.example.com exist within the same network topology.
The technical root cause of this vulnerability lies in the failure of both Istio and Envoy to properly implement the HTTP/2 Misdirected Request status code 421 as defined in RFC 7540. When a client establishes a connection to a wildcard domain server and that connection is subsequently reused for requests to explicitly configured domains within the same parent domain, the proxy infrastructure does not validate that the requested host matches the connection's original configuration. This behavior violates the fundamental security assumptions browsers make about domain isolation, particularly when HTTP/2 connection coalescing occurs between different hostnames. The vulnerability operates at the application layer and affects the transport security model by allowing data to flow across domain boundaries that should be strictly separated.
The operational impact of this vulnerability is significant and potentially devastating for organizations relying on Istio and Envoy for their service mesh operations. The security implications extend beyond simple data leakage to encompass complete bypass of browser security models that separate different domains. When a victim browser interacts with abc.example.com while the underlying TCP connection has been recycled from a previous interaction with *.example.com, sensitive information can be transmitted to the wrong server without proper error handling. This scenario is particularly dangerous in shared caching forward proxy environments where many users access different subdomains within the same domain hierarchy, creating numerous potential attack vectors for data exfiltration. The vulnerability essentially undermines the security boundaries that browsers enforce between different domains, allowing for cross-domain data leakage that could expose user credentials, personal information, and corporate data.
Organizations affected by this vulnerability should implement immediate mitigations including upgrading to patched versions of Istio (1.5.2 or later) and Envoy (1.14.2 or later) where the proper 421 Misdirected Request handling has been implemented. Network administrators should also consider implementing additional monitoring and logging around HTTP/2 connection reuse patterns to detect potential exploitation attempts. The fix addresses the core issue by ensuring that when a connection is established to one domain but subsequently used for requests to a different but related domain, the proxy correctly returns a 421 status code rather than allowing the request to proceed to the wrong server. This aligns with the HTTP/2 specification requirements and restores proper security boundaries that browsers expect. From an ATT&CK perspective, this vulnerability maps to T1071.004 (Application Layer Protocol: DNS) and T1566 (Phishing) as it enables data exfiltration through manipulated connection reuse, while CWE-200 (Information Exposure) and CWE-310 (Cryptographic Issues) directly apply to the data leakage and connection handling flaws present in the affected systems.