Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.34.0 until 1.35.13, 1.36.9, 1.37.5, and 1.38.3, a vulnerability exists in Envoy's TCP StatsD sink (TcpStatsdSink), where the thread-local flusher buffer can be overflowed by exceptionally long statistic names (e.g., >16KiB). During formatting, TcpStatsdSink reserves a single contiguous memory slice of 16KiB (FLUSHSLICESIZEBYTES). If formatting a single metric exceeds the remaining capacity, the flusher initiates a buffer rotation but incorrectly continues to allocate another fixed 16KiB slice. If an attacker can trigger a statistic name longer than 16KiB—for example, by sending an HTTP or gRPC request with an extremely long request path (:path) that is recorded by the grpcstats filter configured with statsforallmethods: true—the flusher will attempt to copy the metric name using memcpy operations beyond the allocated heap buffer boundaries. This leads to a heap write overflow, which can cause immediate denial-of-service (process crash) or potential remote code execution (RCE). This vulnerability is fixed in 1.35.13, 1.36.9, 1.37.5, and 1.38.3.

Summary Envoy’s mTLS certificate matcher for matchtypedsubjectaltnames may incorrectly treat certificates containing an embedded null byte (\0) inside an OTHERNAME SAN value as valid matches.

Details This occurs when the SAN is encoded as a BMPSTRING or UNIVERSALSTRING, and its UTF-8 conversion result is truncated at the first null byte during string assignment. As a result, "victim\0evil" may match an exact: "victim" rule and be accepted by Envoy.

PoC

Create a CA and a server certificate signed by that CA. Create two client certificates signed by the same CA: clientevil with OTHERNAME BMPSTRING = "evil" clientnull with OTHERNAME BMPSTRING = "victim\0evil" Configure Envoy with requireclientcertificate: true and a matchtypedsubjectaltnames entry for the OTHERNAME OID with matcher.exact: "victim". Connect without a client cert → connection rejected. Connect with clientevil → connection rejected. Connect with clientnull → connection accepted (but shouldn't!).

Impact An attacker who can obtain a trusted client certificate with a null byte embedded in an OTHERNAME SAN can exploit this vulnerability. The practical impact is unauthorized impersonation of the matched identity, enabling access to services or APIs protected by that exact OTHERNAME check.

Credit markevich.nikita1@gmail.com

Summary Envoy crashes when JWT authentication is configured with the remote JWKS fetching, allowmissingorfailed is enabled, multiple JWT tokens are present in the request headers and the JWKS fetch fails.

Details This is caused by a re-entry bug in the JwksFetcherImpl. When the first token's JWKS fetch fails, onJwksError() callback triggers processing of the second token, which calls fetch() again on the same fetcher object.

The original callback's reset() then clears the second fetch's state (receiver and request) which causes a crash when the async HTTP response arrives.

PoC allowmissingorfailed or allowmissing is enabled The client send 2 Authorization headers the remote JWKS fetching failed There will be crash

Impact DoS and Crash

Mitigation Disable the allowmissingorfailed or allowmissing

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.34.0 until 1.35.13, 1.36.9, 1.37.5, and 1.38.3, Envoy crashes if an extproc server sends a single gRPC message containing multiple, specially crafted ProcessingResponse messages. This can occur when the first response in the batch causes the gRPC stream object to be destroyed, leading to a use-after-free error when Envoy attempts to process subsequent responses in the same gRPC message. This vulnerability is fixed in 1.35.13, 1.36.9, 1.37.5, and 1.38.3.

Summary

Forwarding of early CONNECT data in TCP proxy mode.

Details

Per RFC 7231-4.3.6 the sender of CONNECT (and all inbound proxies) switch to tunnel mode only after receiving 2xx response. However in TCP proxy mode, Envoy accepts client data before it has issued a 2xx response and eagerly proxies it to an established TCP connection. This creates possibility of a de-synchronized tunnel state if a proxy upstream from Envoy responds with a status other an 2xx.

The RFC does not specify the behavior in case an early CONNECT data is received and early CONNECT data is common as a latency reduction mechanism. To prevent disruption to existing deployments Envoy will by default allow early CONNECT data. Setting the envoy.reloadablefeatures.rejectearlyconnectdata runtime flag to true will cause CONNECT requests that send data before 2xx response to be rejected. This options should be enabled if there are intermediaries upstream from Envoy that may reject establishment of a CONNECT tunnel.

Impact

De-synchronization of CONNECT tunnel state if a forwarding proxy upstream from Envoy responds with a non 2xx status.

Attack vector(s) Sending data for a CONNECT request before receiving 2xx response.

Patches Users should upgrade to v1.36.3, v1.35.7, v1.34.11 or v1.33.13

Credits

chasingimpact (Patrick)

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.34.0 until 1.35.13, 1.36.9, 1.37.5, and 1.38.3, PROXY Protocol v2 header generator emits TLVs beyond the maximum length of 65535 bytes, causing a mismatch between bytes written and the length field in the header. This can result in smuggled bytes on the upstream request. This vulnerability is fixed in 1.35.13, 1.36.9, 1.37.5, and 1.38.3.