CVE-2024-32475: Envoyproxy Envoy DoS Vulnerability

CVE-2024-32475 Overview

CVE-2024-32475 is a denial-of-service vulnerability in Envoy, the cloud-native edge and service proxy. The flaw affects configurations where an upstream TLS cluster uses auto_sni. When Envoy receives a request with a host or :authority header longer than 255 characters, it attempts to use that value as the Server Name Indication (SNI) for the outbound TLS connection. The SNI standard limits this field to 255 characters, so the operation fails. Envoy does not handle the failure gracefully and instead triggers a RELEASE_ASSERT, abnormally terminating the process. Maintainers fixed the issue in versions 1.30.1, 1.29.4, 1.28.3, and 1.27.5.

Critical Impact
A single unauthenticated HTTP request with an oversized host/:authority header crashes the Envoy proxy, disrupting all traffic flowing through the affected instance.

Affected Products

Envoy 1.30.0
Envoy 1.29.x prior to 1.29.4
Envoy 1.28.x prior to 1.28.3 and 1.27.x prior to 1.27.5

Discovery Timeline

2024-04-18 - CVE-2024-32475 published to the National Vulnerability Database
2025-09-04 - Last updated in NVD database

Technical Details for CVE-2024-32475

Vulnerability Analysis

The vulnerability is classified as [CWE-253] Incorrect Check of Function Return Value. Envoy's TLS context implementation in source/common/tls/context_impl.cc assumed that setting the SNI on a new SSL object would always succeed. When auto_sni is enabled on an upstream cluster, Envoy derives the SNI from the inbound host or :authority header. BoringSSL rejects SNI values exceeding 255 characters, returning an error. Envoy's newSsl() method previously returned a raw bssl::UniquePtr<SSL> and used a RELEASE_ASSERT to enforce success. When the call failed, the assertion aborted the process. An attacker can therefore crash a production Envoy instance by sending a single HTTP request with a long Host header, causing a denial of service for every downstream consumer of that proxy.

Root Cause

The defect originates from improper validation of an external input length before passing it to a library API with strict bounds. Envoy treated SNI configuration as an infallible operation. Combined with auto_sni, which forwards attacker-controlled header data into the TLS stack, the unchecked precondition becomes remotely reachable.

Attack Vector

Exploitation requires only network access to a route that targets an upstream TLS cluster with auto_sni: true. The attacker sends an HTTP/1.1 or HTTP/2 request whose Host or :authority header exceeds 255 characters. No authentication, user interaction, or privileged position is required.

// Patch excerpt from source/common/tls/context_impl.h
// Source: https://github.com/envoyproxy/envoy/commit/b47fc6648d7c2dfe0093a601d44cb704b7bad382
 class ContextImpl : public virtual Envoy::Ssl::Context,
                     protected Logger::Loggable<Logger::Id::config> {
 public:
-  virtual bssl::UniquePtr<SSL> newSsl(const Network::TransportSocketOptionsConstSharedPtr& options);
+  virtual absl::StatusOr<bssl::UniquePtr<SSL>>
+  newSsl(const Network::TransportSocketOptionsConstSharedPtr& options);
 
   /**
    * Logs successful TLS handshake and updates stats.

The fix changes newSsl() to return an absl::StatusOr, allowing the caller to propagate the SNI error instead of asserting. See the Envoy GitHub commit b47fc66 for the complete patch.

Detection Methods for CVE-2024-32475

Indicators of Compromise

Unexpected Envoy process aborts with RELEASE_ASSERT messages referencing TLS context or SNI in stderr or container logs.
Sudden spikes in upstream connection failures or 5xx responses correlated with restarts of the Envoy pod or sidecar.
Inbound HTTP requests containing Host or :authority header values exceeding 255 characters, especially from external clients.

Detection Strategies

Inspect access logs for abnormally long Host/:authority header values and flag entries above 255 bytes.
Audit Envoy configuration for upstream TLS clusters with auto_sni: true and correlate them with externally reachable listeners.
Monitor for repeated Envoy process restarts or crash loops in Kubernetes events tied to service mesh sidecars.

Monitoring Recommendations

Forward Envoy admin endpoint metrics (server.live, server.uptime) and crash signals to a centralized data lake for trend analysis.
Enable WAF or reverse-proxy rules upstream of Envoy to log requests where header sizes exceed protocol norms.
Alert on cluster-wide TLS handshake error rate deviations that may indicate probing for the SNI condition.

How to Mitigate CVE-2024-32475

Immediate Actions Required

Upgrade Envoy to 1.30.1, 1.29.4, 1.28.3, or 1.27.5 or later as appropriate for your release branch.
Inventory all service mesh control planes (Istio, Consul, Gloo, AWS App Mesh) that embed Envoy and roll out the patched data plane.
Restart Envoy instances after upgrade to ensure the vulnerable binary is no longer resident in memory.

Patch Information

The upstream fix is tracked in GitHub Security Advisory GHSA-3mh5-6q8v-25wj and landed in commit b47fc66. The patch refactors ContextImpl::newSsl() to return absl::StatusOr<bssl::UniquePtr<SSL>>, allowing callers to handle SNI configuration failures without aborting the process.

Workarounds

Disable auto_sni on upstream TLS clusters and configure an explicit sni value in the cluster transport socket.
Enforce a maximum request header size below 255 characters for the Host and :authority headers via an upstream WAF or Envoy max_request_headers_kb and header validation filters.
Restrict the listeners that reach auto_sni-enabled clusters to authenticated or internal traffic where feasible.

bash

# Example Envoy cluster snippet pinning an explicit SNI instead of auto_sni
clusters:
  - name: upstream_tls
    transport_socket:
      name: envoy.transport_sockets.tls
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
        sni: backend.internal.example.com
        # auto_sni: true  # remove until patched version is deployed