CVE-2025-64763: Envoy CONNECT Tunnel Desynchronization Vulnerability – Understanding and Mitigation

Overview

This article provides a detailed analysis of CVE-2025-64763, a vulnerability affecting the Envoy proxy. This vulnerability, discovered in Envoy versions 1.33.12, 1.34.10, 1.35.6, 1.36.2, and earlier, can lead to CONNECT tunnel desynchronization when Envoy is configured as a TCP proxy handling CONNECT requests. This can happen due to Envoy’s behavior of accepting client data before receiving a 2xx response from the upstream.

Technical Details

The vulnerability stems from Envoy’s handling of CONNECT requests in TCP proxy mode. When Envoy receives a CONNECT request, it forwards the request to the upstream server. Crucially, it also accepts and forwards client data before the upstream server responds with a 2xx (success) response. If an intermediary proxy upstream from Envoy rejects the connection (responds with a non-2xx status), a de-synchronized state can occur. This means Envoy has already sent client data upstream, potentially leading to inconsistencies and unexpected behavior in the established tunnel.

By default, Envoy allows early CONNECT data to maintain compatibility with existing deployments. However, this behavior can be risky when intermediaries upstream from Envoy have the potential to reject the CONNECT tunnel establishment.

CVSS Analysis

CVE-2025-64763 has been assigned a CVSS score of 3.7, indicating a LOW severity. This score reflects the potential for limited impact due to the specific conditions required for exploitation. However, it’s still important to understand and address the vulnerability to prevent potential issues in your Envoy deployments.

Possible Impact

While the CVSS score is low, the potential impact of CVE-2025-64763 should not be ignored. A desynchronized CONNECT tunnel can lead to:

• Data inconsistencies: Data sent before the tunnel is fully established might be misinterpreted or lost.
• Unexpected behavior: Applications relying on the CONNECT tunnel might experience unexpected errors or failures.
• Denial of Service (DoS): In certain scenarios, the desynchronization could be leveraged to cause a DoS condition.

The specific impact will depend on the architecture and applications using Envoy as a proxy.

Mitigation and Patch Steps

The recommended mitigation strategy is to utilize the envoy.reloadable_features.reject_early_connect_data runtime flag. Setting this flag will cause Envoy to reject CONNECT requests that send data before receiving a 2xx response from the upstream, preventing the desynchronization issue.

Steps to Mitigate:

1. Identify Envoy instances: Locate all Envoy instances configured as TCP proxies handling CONNECT requests.
2. Set the runtime flag: Configure the envoy.reloadable_features.reject_early_connect_data runtime flag to true. This can typically be done through Envoy’s configuration files or runtime management API. Refer to the Envoy documentation for specific instructions based on your deployment environment.
3. Test the changes: After setting the flag, thoroughly test your applications to ensure the change doesn’t introduce any compatibility issues.
4. Monitor your deployment: Keep monitoring for any unusual behavior after applying the mitigation.

Example Configuration Snippet (Illustrative – Adapt to Your Specific Configuration):

            # Example Envoy configuration (check your Envoy version documentation)
            runtime:
              symlink_root: /var/run/envoy/runtime
              subdirectory: envoy
              override_subdirectory: envoy_override
              layering:
                static_layer:
                  envoy.reloadable_features.reject_early_connect_data: true
        

Note: Always consult the official Envoy documentation for the most up-to-date configuration options and best practices.

References

GHSA-rj35-4m94-77jh – Envoy Security Advisory
Envoy Proxy Official Website
CVE-2025-64763 at CVE.mitre.org