Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.37.0 until 1.37.5 and 1.38.3, when the %REQUESTEDSERVERNAME(X:Y)% is used in log format and host related options is specified, like HOSTFIRST, SNIFIRST, it's possible to crash Envoy when the specified host header is missing in the request headers. This vulnerability is fixed in 1.37.5 and 1.38.3.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.37.0 until 1.37.5 and 1.38.3, the HTTP OAuth2 filter (envoy.filters.http.oauth2) can leave an in-flight async token exchange attached to a downstream stream that has already been torn down. A late AsyncClient completion can still invoke OAuth2Filter methods that use StreamDecoderFilterCallbacks after that object’s lifetime has ended, causing undefined behavior, worker crashes (availability loss), and use-after-free / invalid-vptr failures under AddressSanitizer. This is a memory-safety / lifetime issue in the data plane, not a trivial config bug. Remote code execution is not claimed here; the primary demonstrated impact is DoS via crash and UB; any further impact would be deployment- and allocator-dependent. This vulnerability is fixed in 1.37.5 and 1.38.3.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.36.0 until 1.36.9, 1.37.5, and 1.38.3, a Use-After-Free (UAF) vulnerability leading to a sudden segmentation fault exists in Envoy's extauthz HTTP filter when processing per-route authorization overrides concurrently with rapid downstream client disconnects. During standard request lifecycles, Envoy instantiates the extauthz filter with a foundational authorization client object (client). If a matched route dictates a dynamic per-route HTTP or gRPC authorization service override, the filter generates a localized client. In the vulnerable implementation, this transient client aggressively overwrote the default client unique pointer by executing client = std::move(perrouteclient). When a client rapidly establishes and subsequently tears down a stream (such as rapidly refreshing a protected WebSocket endpoint), the downstream triggers the ConnectionManagerImpl::doDeferredStreamDestroy() -> ActiveStream::onResetStream() lifecycle. Envoy immediately sequences Filter::onDestroy() in an attempt to securely abort dispatched asynchronous authorization check transactions via client->cancel(). By destructing the default client abruptly during initiateCall, a memory lifecycle misalignment occurs within the async client manager. The stream teardown fails to reliably track and cancel the dynamically bound asynchronous authorization tasks, orchestrating a sequence where a late asynchronous callback from the network evaluates against a heavily destroyed ActiveStream validation span, generating a UAF process crash. This vulnerability is fixed in 1.36.9, 1.37.5, and 1.38.3.

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.

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.

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.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.26.0 until 1.35.13, 1.36.9, 1.37.5, and 1.38.3, the envoy.filters.http.grpcstats filter crashes (null pointer dereference / segfault) when a Connect protocol request (Content-Type: application/connect+proto or application/connect+json) hits a directresponse route. A single unauthenticated HTTP request crashes the Envoy process. This vulnerability is fixed in 1.35.13, 1.36.9, 1.37.5, and 1.38.3.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.18.0 until 1.35.13, 1.36.9, 1.37.5, and 1.38.3, the router filter contains a null pointer dereference vulnerability when handling HTTP 303 (See Other) internal redirects for body-less non-GET/HEAD requests. When a POST, PUT, DELETE, or PATCH request without a body is sent to a route configured with internal redirect policy that includes 303 in redirectresponsecodes, and the upstream responds with HTTP 303, the redirect handling code attempts to drain a request body buffer that was never allocated. This results in a segmentation fault that crashes the entire Envoy process. When route configured with internalredirectpolicy including 303 in redirectresponsecodes and upstream must return HTTP 303 response, an unauthenticated attacker can exploit this to cause complete denial of service, terminating all active connections. This vulnerability is fixed in 1.35.13, 1.36.9, 1.37.5, and 1.38.3.

Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to 1.35.11, 1.36.7, 1.37.3, and 1.38.1, in cases where UDP DNS filter is configured with local resolution containing a name with the length of 255 octets or remote resolution for a name of 255 octets long can complete successfully, a query with such name will result in abnormal process termination. The abnormal process termination is triggered by an invalid runtime precondition that the query name is strictly less than 255 octets, contradicting DNS specification rfc1035#section-2.3.4 that the name can be 255 or less octets. This vulnerability is fixed in 1.35.11, 1.36.7, 1.37.3, and 1.38.1.

Envoy is an open source edge and service proxy designed for cloud-native applications. From 1.23.0 until 1.35.11, 1.36.7, 1.37.3, and 1.38.1, a vulnerability has been identified in Envoy's zstd decompressor implementation (ZstdDecompressorImpl). When zstd decompression is enabled, processing a specially crafted, highly compressed zstd payload can lead to massive memory allocation. An attacker can exploit this to cause severe memory exhaustion, potentially resulting in an Out-Of-Memory (OOM) kill and Denial of Service (DoS) for the Envoy proxy. This vulnerability is fixed in 1.35.11, 1.36.7, 1.37.3, and 1.38.1.

A denial-of-service vulnerability was found in Envoy's HTTP/2 implementation. The attack chains two techniques: an HPACK compression bomb that exploits header compression to amplify a single byte on the wire into a full header allocation on the server (repeated thousands of times per request), and a Slowloris-style hold using a zero-byte HTTP/2 flow-control window that prevents the server from ever freeing the allocated memory.

A remote attacker can exploit this in Envoy's default HTTP/2 configuration to consume and hold large amounts of server memory (up to 32GB in approximately 20 seconds), rendering the server inaccessible.

This vulnerability exists in each server's default HTTP/2 configuration and requires no authentication to exploit.

External Reference: https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb

A denial-of-service vulnerability was found in Envoy's HTTP/2 implementation. The attack chains two techniques: an HPACK compression bomb that exploits header compression to amplify a single byte on the wire into a full header allocation on the server (repeated thousands of times per request), and a Slowloris-style hold using a zero-byte HTTP/2 flow-control window that prevents the server from ever freeing the allocated memory.

A remote attacker can exploit this in Envoy's default HTTP/2 configuration to consume and hold large amounts of server memory (up to 32GB in approximately 20 seconds), rendering the server inaccessible.

This vulnerability exists in each server's default HTTP/2 configuration and requires no authentication to exploit.

External Reference: https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb

We’re publishing HTTP/2 Bomb, a remote denial-of-service exploit against most major web servers, including:

nginx

Apache httpd

Microsoft IIS

Envoy

Cloudflare Pingora

The vulnerable behavior exists in each server's default HTTP/2 configuration.

The attack was discovered by Codex, which chained two techniques known to humans for a decade: a compression bomb and a Slowloris-style hold. The bomb targets HPACK, HTTP/2's header compression scheme: one byte on the wire becomes one full header allocation on the server, repeated thousands of times per request. The hold is a zero-byte flow-control window that keeps the server from ever freeing any of it.

A curious search on Shodan revealed 880,000+ websites supporting HTTP/2 and running one of these servers, though many sit behind a CDN, which is much harder to bring down.

A home computer on a 100Mbps connection can render a vulnerable server inaccessible within seconds. Against Apache httpd and Envoy, a single client can consume and hold 32GB of server memory in roughly 20 seconds.

On 6/2/26 19:36, Alan Coopersmith wrote: https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb says: The fix commits above are public and disclose the vectors directly; any capable AI model can turn those diffs into a working exploit, which is exactly how we found that Microsoft IIS, Envoy, and Pingora are also vulnerable. We've notified their maintainers. Given how short the commit-to-exploit path now is, we're releasing this writeup to provide users with the mitigations below. Additional patches have since been released by envoy & h2o. Posts on twitter by @califio continue to discuss whether other packages are vulnerable or not.

https://github.com/envoyproxy/envoy/security/advisories/GHSA-22m2-hvr2-xqc8 says: HTTP/2 memory exhaustion via cookie header size bypass and HPACK amplification

phlax published GHSA-22m2-hvr2-xqc8 Jun 3, 2026

Package: github.com/envoyproxy/envoy Affected versions: <1.39 Patched versions: 1.35.11 1.36.7 1.37.3 1.38.1

Summary -------

A vulnerability in Envoy's HTTP/2 downstream request processing allows an unauthenticated remote client to trigger excessive memory consumption, potentially resulting in OOM termination of the Envoy process and denial of service.

The issue arises from the combination of two behaviors:

1. Cookie header bytes are not fully accounted for during request header size validation in Envoy. 2. HPACK header block limits in oghttp2/quiche are enforced on encoded bytes without a corresponding limit on total decoded header size.

Together, these behaviors allow a malicious client to cause large decoded header allocations while bypassing the intended request header size protections.

Affected Components -------------------

Envoy HTTP/2 downstream request processing Cookie header size accounting during header validation HPACK header block size enforcement in oghttp2/quiche

Details -------

During HTTP/2 request processing, cookie header fragments are buffered separately and merged only after request header size validation has completed. Because these buffered cookie bytes are not fully included in the effective header size check, oversized cookie data can bypass maxrequestheaderskb enforcement.

Separately, oghttp2/quiche enforces header block limits on encoded HPACK bytes rather than on the fully decoded header size. A malicious client can exploit this asymmetry by using dynamic table references to keep the encoded representation relatively small while causing the decoded cookie header value to become much larger in memory.

When these behaviors are combined, a client can force Envoy to retain large per-stream allocations. Under sustained concurrency, this can rapidly increase process memory usage and lead to OOM termination.

Flow-control stalling can further increase the effectiveness of the attack by prolonging stream lifetime and delaying reclamation of per-stream memory.

Impact ------

An unauthenticated remote attacker can cause denial of service by exhausting memory in the Envoy process.

In testing against envoyproxy/envoy-google-vrp-dev:latest (v1.36.0-dev), the Envoy edge process was OOM-killed under a 3 GiB memory limit within a few seconds using a limited number of HTTP/2 connections and streams.

Additional testing showed that the attack remained effective with significantly fewer connections and streams than initially required, indicating that exploitation can be efficient even under tighter attacker-side resource constraints.

A secondary operational effect observed during testing was that oversized decoded cookies forwarded upstream could exceed the upstream service's own header limits, potentially causing upstream HTTP/2 connection resets and transient request failures.

Attack Vector -------------

A malicious downstream HTTP/2 client sends specially crafted cookie headers that combine:

incomplete cookie-size accounting during request validation; and HPACK decoded-size amplification via small encoded representations.

The impact can be amplified further by using HTTP/2 flow-control behavior to extend stream lifetime and delay memory reclamation.

Patches -------

A complete fix requires addressing both contributing issues:

include buffered cookie bytes in request header size accounting before request acceptance; and enforce limits on decoded header size, not only on encoded HPACK block size.

Fixing only one side may reduce exploitability but does not fully address the underlying issue.

Workarounds -----------

No complete workaround is known short of applying a fix.

Possible temporary mitigations include:

disabling downstream HTTP/2 where operationally feasible; enforcing stricter request header and cookie limits before traffic reaches Envoy; and monitoring Envoy memory usage for abnormal growth under HTTP/2 traffic.

Detection ---------

Potential indicators of exploitation include:

rapid or sustained abnormal memory growth in the Envoy process; OOM termination, including exit status 137 in containerized environments; and unusual HTTP/2 traffic patterns involving repeated indexed cookie references.

Credits ------- Credit: Ryoga Yamashita.

Severity: High, 7.5 / 10 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H CVE ID: CVE-2026-47774 https://github.com/h2o/h2o/security/advisories/GHSA-qcrr-wrhc-pgq9 says: HTTP/2 state amplification

kazuho published GHSA-qcrr-wrhc-pgq9 Jun 3, 2026

Package: h2o Affected versions: commits up to 8dc37cb Patched versions: 9265bdd and above

Impact ------

Recently, an attack against HTTP/2 servers was published that combines state amplification caused by HPACK decompression with Slowloris-style stream stalling: https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb.

H2O reduces HPACK state amplification by representing HTTP header names and values internally as references where possible. However, in light of this attack, additional limits may be needed, depending on the configuration, to bound decoded header state and prevent amplified state from being retained by stalled HTTP/2 streams.

Patches ------- Mitigations were added in #3597 and landed on master as 9265bdd: https://github.com/h2o/h2o/pull/3597 https://github.com/h2o/h2o/commit/9265bdd9a996ed992681055e3996baf3e09d2063

References ---------- https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb

Severity: High, 7.5 / 10 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H CVE ID: No known CVE -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

https://blog.calif.io/p/codex-discovered-a-hidden-http2-bomb says: We’re publishing HTTP/2 Bomb, a remote denial-of-service exploit against most major web servers, including:

- nginx - Apache httpd - Microsoft IIS - Envoy - Cloudflare Pingora

The vulnerable behavior exists in each server's default HTTP/2 configuration. The blog tells the story of how it was found and provides technical details and PoCs.

It also says: Credits

Quang Luong for discovering the exploit. He'll be presenting his techniques at the upcoming Real World AI Security conference at Stanford in June.

Jun Rong and Duc Phan for confirming the attack on other web servers. and: Disclosure

We disclosed the issue to nginx in April. They responded by importing the maxheaders directive from freenginx, shipping it in 1.29.8 the next day: https://github.com/nginx/nginx/commit/365694160a85229a7cb006738de9260d49ff5fa2 At this point, we consider the attack public.

We disclosed to Apache on May 27, and Stefan Eissing fixed it on the same day by making cookie headers count against LimitRequestFields: https://github.com/apache/httpd/commit/47d3100b252dc6668a9e46ae885242be9eeca9cd The issue was assigned CVE-2026-49975.

The fix commits above are public and disclose the vectors directly; any capable AI model can turn those diffs into a working exploit, which is exactly how we found that Microsoft IIS, Envoy, and Pingora are also vulnerable. We've notified their maintainers. Given how short the commit-to-exploit path now is, we're releasing this writeup to provide users with the mitigations below.

Mitigations

nginx: Upgrade to 1.29.8+, which adds the maxheaders directive with a default of 1000. If you can't upgrade, disable HTTP/2 with http2 off;.

Apache httpd: The fix is in modhttp2 v2.0.41, available from the standalone modhttp2 releases and in httpd trunk but not yet in a 2.4.x release. If you can't upgrade, set Protocols http/1.1 to disable HTTP/2. Lowering LimitRequestFieldSize shrinks the per-stream blast radius (it caps the merged cookie, and so the crumb count), but it's only a partial mitigation, since an attacker can still multiply the effect across streams and connections. Lowering LimitRequestFields does nothing here: the duplicate cookie crumbs never count against it.

Microsoft IIS, Envoy, Cloudflare Pingora: No patch available at the time of writing. Disable HTTP/2 if you can, or front the server with something that enforces a hard cap on header count per request.

Generally: "Maximum decoded header size" and "maximum header count" are two different limits, and a server needs both. Any HTTP/2 termination point should cap the number of header fields per request, including cookie crumbs, independent of their total size, and should bound the lifetime of a stalled stream regardless of WINDOWUPDATE activity. And if you can't do any of that today: cap per-worker memory (cgroups, ulimit -v, container limits) tight enough that a bombed worker gets OOM-killed and respawned before it drags the box into swap. A worker process rarely needs gigabytes; letting the kernel kill one early is a better failure mode than letting the attacker hold the whole machine at 95%.

Takeaways

RFC 7541 has an entire section on this threat. §7.3 Memory Consumption opens with "an attacker can try to cause an endpoint to exhaust its memory," then explains that HPACK bounds the dynamic table via SETTINGSHEADERTABLESIZE and considers the matter handled. But when five independent implementations all read that section and still ship the same class of bug, the defect is in the spec.

The deeper miss is that the spec frames memory risk purely as an amplification ratio, and ratio is only half the equation. A 70:1 amplifier is harmless if the memory is freed when the request completes. It becomes an attack because HTTP/2 lets the client hold the connection open almost for free, pinning every allocated byte for as long as they like.

The other thing worth noting is how this exploit was found. Both halves have been public for a decade. What Codex did was read the codebases, recognize that the two compose, and build the combined attack. That combination is obvious once you see it, and yet as far as we can tell no human had put it together against these servers.

A weakness has been identified in Envoy up to 1.33.0. Affected is the function params.add of the file source/extensions/filters/http/headermutation/headermutation.cc of the component Query Parameter Handler. This manipulation causes injection. Remote exploitation of the attack is possible. Patch name: f8f4f1e02fdc64ecd4acf2d903208dd7285ad3a4. It is suggested to install a patch to address this issue.

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

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)

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. Envoy versions earlier than 1.36.2, 1.35.6, 1.34.10, and 1.33.12 contain a use-after-free vulnerability in the Lua filter. When a Lua script executing in the response phase rewrites a response body so that its size exceeds the configured perconnectionbufferlimitbytes (default 1MB), Envoy generates a local reply whose headers override the original response headers, leaving dangling references and causing a crash. This results in denial of service. Updating to versions 1.36.2, 1.35.6, 1.34.10, or 1.33.12 fixes the issue. Increasing perconnectionbufferlimitbytes (and for HTTP/2 the initialstreamwindowsize) or increasing perrequestbufferlimitbytes / requestbodybufferlimit can reduce the likelihood of triggering the condition but does not correct the underlying memory safety flaw.

Envoy is a cloud-native, open source edge and service proxy. Prior to 1.36.1, 1.35.5, 1.34.9, and 1.33.10, large requests and responses can potentially trigger TCP connection pool crashes due to flow control management in Envoy. It will happen when the connection is closing but upstream data is still coming, resulting in a buffer watermark callback nullptr reference. The vulnerability impacts TCP proxy and HTTP 1 & 2 mixed use cases based on ALPN. This vulnerability is fixed in 1.36.1, 1.35.5, 1.34.9, and 1.33.10.

Envoy is an open source L7 proxy and communication bus designed for large modern service oriented architectures. In versions below 1.32.10 and 1.33.0 through 1.33.6, 1.34.0 through 1.34.4 and 1.35.0, insufficient Session Expiration in the Envoy OAuth2 filter leads to failed logout operations. When configured with Secure- or Host- prefixed cookie names, the filter fails to append the required Secure attribute to the Set-Cookie header during deletion. Modern browsers ignore this invalid request, causing the session cookie to persist. This allows a user to remain logged in after they believe they have logged out, creating a session hijacking risk on shared computers. The current implementation iterates through the configured cookie names to generate deletion headers but does not check for these prefixes. This failure to properly construct the deletion header means the user's session cookies are never removed by the browser, leaving the session active and allowing the next user of the same browser to gain unauthorized access to the original user's account and data. This is fixed in versions 1.32.10, 1.33.7, 1.34.5 and 1.35.1.

Summary

A use-after-free (UAF) vulnerability in Envoy's DNS cache causes abnormal process termination. Envoy may reallocate memory when processing a pending DNS resolution, causing list iterator to reference freed memory.

Details

The vulnerability exists in Envoy's Dynamic Forward Proxy implementation starting from version v1.34.0. The issue occurs when a completion callback for a DNS resolution triggers new DNS resolutions or removes existing pending resolutions. This condition may occur in the following configuration:

1. Dynamic Forwarding Filter is enabled. 2. envoy.reloadablefeatures.dfpclusterresolveshosts runtime flag is enabled. 3. The Host header is modified between the Dynamic Forwarding Filter and Router filters.

Impact

Denial of service due to abnormal process termination.

Attack vector(s) Request to Envoy configured as indicated above.

Patches Users should upgrade to v1.35.1 or v1.34.5.

Workaround Set the envoy.reloadablefeatures.dfpclusterresolveshosts runtime flag to false.

Detection Abnormal process termination with the Envoy::Event::DispatcherImpl::runPostCallbacks() frame in the call stack.

Credits Rohit Agrawal (agrawroh) (rohit.agrawal@databricks.com)

Envoy is a cloud-native edge/middle/service proxy. Prior to versions 1.34.1, 1.33.3, 1.32.6, and 1.31.8, Envoy's URI template matcher incorrectly excludes the character from a set of valid characters in the URI path. As a result URI path containing the character will not match a URI template expressions. This can result in bypass of RBAC rules when configured using the uritemplate permissions. This vulnerability is fixed in Envoy versions v1.34.1, v1.33.3, v1.32.6, v1.31.8. As a workaround, configure additional RBAC permissions using urlpath with saferegex expression.

Summary Envoy's extproc HTTP filter is at risk of crashing if a local reply is sent to the external server due to the filter's life time issue. A known situation is the fail of a websocket handshake will trigger a local reply leading to the crash of Envoy.

PoC If both websocket and extproc are enabled, a failed handshake will trigger a local reply, thus extproc will crash.

Mitigation 1. Disable websocket traffic 2. Change the websocket response from backend to always return 101 Switch protocol based on RFC. 3. Apply the patch and the extproc filter will not send the local reply that is generated by Envoy to the extproc server for processing. 4. Apply the patch that the router will cancel the upstream requests when sending a local reply.

Impact Denial of service

Reporter Vasilios Syrakis Fernando Cainelli

Impact In all Envoy Gateway versions prior to 1.2.7 and 1.3.1 a default Envoy Proxy access log configuration is used. This format is vulnerable to log injection attacks.

If the attacker uses a specially crafted user-agent which performs json injection, then he could add and overwrite fields to the access log.

Examples of attacks include:

- Using following string as user agent : HELLO-WORLD", "evil-ip": "1.1.1.1", "x-forwarded-for": "1.1.1.1 would lead to setting of new access log properties and overwrite of existing properties. Existing properties such as the value of the X-Forwarded-For header may have importance for security analysis of access logs, and their overwrite can be used to hide malicious activity.

- Using the following string as user-agent : " which renders an invalid json document. The invalid document may fail to be processed by observability solutions, which would allow attacker to hide malicious activity.

Patches 1.3.1, 1.2.7

Fix Using JSON format as the default format for access logs. The logged document will contain the same key and values as before. Only the order of properties is different inside the logged document.

Workaround One can overwrite the old text based default format with JSON formatter by setting the following property: "EnvoyProxy.spec.telemetry.accessLog" to

settings: - format: type: JSON json: starttime: '%STARTTIME%' method: '%REQ(:METHOD)%' x-envoy-origin-path: '%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%' protocol: '%PROTOCOL%' responsecode: '%RESPONSECODE%' responseflags: '%RESPONSEFLAGS%' responsecodedetails: '%RESPONSECODEDETAILS%' connectionterminationdetails: '%CONNECTIONTERMINATIONDETAILS%' upstreamtransportfailurereason: '%UPSTREAMTRANSPORTFAILUREREASON%' bytesreceived: '%BYTESRECEIVED%' bytessent: '%BYTESSENT%' duration: '%DURATION%' x-envoy-upstream-service-time: '%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%' x-forwarded-for: '%REQ(X-FORWARDED-FOR)%' user-agent: '%REQ(USER-AGENT)%' x-request-id: '%REQ(X-REQUEST-ID)%' :authority: '%REQ(:AUTHORITY)%' upstreamhost: '%UPSTREAMHOST%' upstreamcluster: '%UPSTREAMCLUSTER%' upstreamlocaladdress: '%UPSTREAMLOCALADDRESS%' downstreamlocaladdress: '%DOWNSTREAMLOCALADDRESS%' downstreamremoteaddress: '%DOWNSTREAMREMOTEADDRESS%' requestedservername: '%REQUESTEDSERVERNAME%' routename: '%ROUTENAME%' see API definition here

References Are there any links users can visit to find out more?

Impact A user with access to a Kubernetes cluster where Envoy Gateway is installed can use a path traversal attack to execute Envoy Admin interface commands on proxies managed by Envoy Gateway. The admin interface can be used to terminate the Envoy process and extract the Envoy configuration (possibly containing confidential data).

For example, the following command, if run from within the Kubernetes cluster, can be used to get the configuration dump of the proxy: curl --path-as-is http://<Proxy-Service-ClusterIP>:19001/stats/prometheus/../../configdump Patches 1.2.6

Workarounds The EnvoyProxy API can be used to apply a bootstrap config patch that restricts access strictly to the prometheus stats endpoint. Find below an example of such a bootstrap patch.

apiVersion: gateway.envoyproxy.io/v1alpha1 kind: EnvoyProxy metadata: name: custom-proxy-config namespace: default spec: bootstrap: type: JSONPatch jsonPatches: - op: "add" path: "/staticresources/listeners/0/filterchains/0/filters/0/typedconfig/normalizepath" value: true - op: "replace" path: "/staticresources/listeners/0/filterchains/0/filters/0/typedconfig/routeconfig/virtualhosts/0/routes/0/match" value: path: "/stats/prometheus" headers: - name: ":method" exactmatch: GET

References - Envoy Admin Interface: https://www.envoyproxy.io/docs/envoy/latest/operations/admin - Envoy Configuration Best Practices: https://www.envoyproxy.io/docs/envoy/latest/configuration/bestpractices/edge

Envoy is a cloud-native high-performance edge/middle/service proxy. In affected versions sendOverloadError is going to assume the active request exists when envoy.loadshedpoints.http1serverabortdispatch is configured. If activerequest is nullptr, only onMessageBeginImpl() is called. However, the onMessageBeginImpl will directly return ok status if the stream is already reset leading to the nullptr reference. The downstream reset can actually happen during the H/2 upstream reset. As a result envoy may crash. This issue has been addressed in releases 1.32.3, 1.31.5, 1.30.9, and 1.29.12. Users are advised to upgrade. Users unable to upgrade may disable http1serverabortdispatch load shed point and/or use a high threshold.

Envoy is a cloud-native high-performance edge/middle/service proxy. In affected versions envoy does not properly handle http 1.1 non-101 1xx responses. This can lead to downstream failures in networked devices. This issue has been addressed in versions 1.31.5 and 1.32.3. Users are advised to upgrade. There are no known workarounds for this issue.

Envoy is a cloud-native high-performance edge/middle/service proxy. In affected versions sendOverloadError is going to assume the active request exists when envoy.loadshedpoints.http1serverabortdispatch is configured. If activerequest is nullptr, only onMessageBeginImpl() is called. However, the onMessageBeginImpl will directly return ok status if the stream is already reset leading to the nullptr reference. The downstream reset can actually happen during the H/2 upstream reset. As a result envoy may crash. This issue has been addressed in releases 1.32.3, 1.31.5, 1.30.9, and 1.29.12. Users are advised to upgrade. Users unable to upgrade may disable http1serverabortdispatch load shed point and/or use a high threshold.